需求評審五個次元架構分析及其帶來的啟示-3-典型需求評審

典型情境是指軟體開發的常見情境，本文選擇如下來進行分析：

1. 傳統瀑布模型開發下的需求評審

2. 使用IEEE Std. 1028的需求評審

3. 靈活開發下的需求評審

傳統瀑布模型下的需求評審

對傳統瀑布模型現有需求評審的分析

傳統瀑布模型在需求階段末期安排有關鍵的需求裡程碑評審，其特征參見2.8節情況1。在業界實際操作中，往往出現如下情況：

1，召集包括上司在内的各方代表，曆經1～2小時會議，評審30頁以上需求規格說明書，走過場式各方簽字通過評審；

2，各方對需求規格書有各種各樣意見，曆經3～n次評審會，眼看工期已經有明顯拖延，後續開發已經跟進，甚至開發快完成了，總算獲得通過；

3，經過多方運籌協調，前後費時4周多，召集各方到某度假村，曆經三天讨論修改評審，總算通過評審。

以上情況就展現了前文所言的“官僚繁瑣、繁文缛節”，其弊端明顯。在[26]文同樣也識别到：需求評審往往流于形式。

受CMM/CMMI要求和啟發，為了讓需求階段最後的裡程碑評審能夠順利通過，需求同級評審得到了使用[12][13]。常見有如下情況：

1，在需求完稿時，計劃一次同級評審會議，關注于技術方面，形成同級評審發現和記錄。這對勝利通過裡程碑評審有很大幫助，但往往是更為了應付CMM/CMMI的評估；

2，分階段安排多次會議或非即時的需求同級評審，關注技術方面，記錄評審發現并解決。這是CMM/CMMI比較推薦的做法，能大大緩解瀑布型需求階段裡程碑評審的弊端。

綜合以上分析，為便于整體了解，得下表。

表8 瀑布模型下需求評審情況

标準評審	需求評審架構分析說明
需求裡程碑評審	有預審的會議形式，裡程碑，技術和管理方面，非同級需求文檔評審
需求完稿同級評審	有預審的會議形式，完稿，技術方面，同級需求文檔評審
分段需求同級評審	有預審的會議形式，分段，技術方面，同級需求文檔評審

新需求評審架構對傳統瀑布模型的啟示

啟示1：值得開展定期的雙人即時評審，每次時間約15～30分鐘，适合位置坐在一起的團隊同伴。好處：盡早交流，彼此學習。

啟示2：值得把技術方面評審與管理方面評審分開，先進行各種類型的技術方面評審，然後召開裡程碑管理方面評審。好處：技術方面評審問題解決後，需求階段裡程碑評審着重于管理方面，比如需求規模、進度、工作量等等，更加關注項目整體成功，也能大大節約會議時間。

使用IEEE Std. 1028的需求評審

對照到需求評審，IEEE Std. 1028中的管理評審、技術評審、審查和走查可以适用于需求評審，而其中的審計不屬于本文所讨論的需求評審範疇。

管理評審

IEEE Std. 1028說明管理評審（Management Reviews)用于監測進展情況，判斷計劃和進度表的狀态，或評估為了達成合适目标的管理方法的有效性；管理評審支援關于糾正措施、資源配置設定變更或者項目範圍變更的決策；管理評審識别與計劃的一緻性和差異，或者識别管理流程的完善度和不足度。在需求管理評審的實踐中，最焦點問題是需求範圍和規模是否與計劃相比對。有些組織在需求之前制定了計劃，那麼需求實際的結果是否需要重新計劃；有些組織把項目整體計劃的制定安排在需求之後，那麼需要判斷前期進展如何，對後面制定計劃有什麼影響。

管理評審有詳盡的規範，從角色、會前、會中、會後、到輸入和輸出等等。它成為IEEE Std.1028首先闡述的評審類型絕非徒有虛名，雖然它有沉重繁瑣的嫌疑，但對于謹慎多幹系人場合，仍然是關鍵裡程碑評審的首選甚至是必須的評審類型。在本五維需求評審架構中，管理評審在絕大多數情況下屬于有預審的會議形式裡程碑性質的管理方面非同級需求文檔評審，它提供了管理方面評審的最系統性的“極點”。

技術評審

技術評審的目的是由合格人員組成的團隊來評價一個軟體産物，以判斷是否适合其預期用途，并識别對比于規範和标準的差異。它為管理層提供證明該項目技術狀态的證據，也可能提供替代方案建議，可能需要一個以上的會議。

同管理評審一樣，技術評審有詳盡的規範。技術評審是最廣為人知的一個評審類型，早在1996年出版的《實用軟體工程》（第2版）[9]對此也有詳細的闡述。在實踐中技術評審常常擔當裡程碑評審的重任，而至于管理評審，其關注内容成為技術評審的一小部分，而不再有專門的管理評審。在本五維需求評審架構中，技術評審在絕大多數情況下屬于有預審的會議形式裡程碑性質的技術方面非同級需求文檔評審，它提供了技術方面評審的最系統性的“極點”。

啟示3：了解管理評審和技術評審在五維需求評審架構中的位置，在實際工作中靈活應用這兩項評審，更加有把握的對其進行适應性的剪裁，使其發揮更高效率，盡量規避為人诟病的沉重繁瑣的弊端。

審查

審查對應的英文是Inspection，其目的是檢測和識别軟體産品的異常情況。審查是一個系統性的同級檢查。審查定義了5個角色，分别是審查上司者、記錄員、閱讀者、作者、審查員。任何審查組成員（包括以上5個角色）的上級都不能參加審查活動。審查應當得到計劃并記錄在恰當的項目計劃文檔中，審查開始前需要确認被審查産物是完整的并且符合格式要求，審查後需要記錄評審産物的規模、會中會前時間、返工時間等等。

點評：審查在IEEE Std. 1028得到了嚴格定義，給出了詳盡的規範指導。在本五維需求評審架構中，審查屬于有預審的會議形式完稿技術方面同級評審，同樣是同級評審最系統性的“極點”。 審查要求完整産物，并不能盡早發現問題。

啟示4：值得探索和使用更輕量更高效更及時的需求同級評審。

走查

系統性的走查目的是為了評估一個軟體産品。走查可能也會有讓教育訓練軟體産品閱聽人的目的。走查的作用還有交流技術、交流不同風格變化。 走查不僅可以發現異常，也可以指出不足之處（例如，軟體産品的效率和可讀性問題，設計或代碼的子產品化問題，或無法驗證的規格）。參與走查有4個角色，分别是走查組長、記錄者、作者、走查成員，走查至少需要2人。任何走查組成員的行政上級都不能參加走查。走查的最主要活動是作者或走查組長詳細的展現所評審産物的每個部分，走查組識别并提出發現的異常和問題。走查的标準最少輸出物總計有9項。走查不要求産物已經全部完成，可以按需高頻開展。

在本五維需求評審架構中，走查屬于有預審的雙人即時或者會議形式、技術方面的定期或高頻的同級需求文檔評審。雙人走查是标準允許的最少人數。雙人走查與會議形式走查其實存在較大的差異：雙人走查可以使用一台普通顯示器，利用普通能夠坐下兩人的工作位置即可，這樣就能夠高頻按需開展，會議形式往往需要會議室，而會議室在多數組織是稀缺資源，如果所有項目團隊都開展需求和代碼會議走查，那麼每二周一次的會議室預訂都未必能夠保證，是以難以按需開展。代碼走查是常聽到的詞彙，但是需求走查在中文世界很少提到，而在靈活軟體開發中已經顯示了其有效性。

啟示5：值得探索和使用雙人高頻按需的需求走查或者簡化的需求走查。

IEEE評審小計

綜合以上分析，為便于整體了解，得下表。

表9 IEEE标準需求評審情況

标準評審	需求評審架構分析說明
管理評審	有預審的會議形式，裡程碑，管理方面，非同級需求文檔評審
技術評審	有預審的會議形式，裡程碑，技術方面，非同級需求文檔評審
審查	有預審的會議形式，完稿，技術方面，同級需求文檔評審
走查	有預審的雙人或者會議，定期或者高頻，技術方面，同級需求文檔評審

靈活開發下的需求評審

首先要說明，在靈活開發語境中，幾乎不使用“評審”這詞，常用“驗證”、“驗收”、“回報”等。本文将基于文檔閱讀或者觀察軟體運作的時效性人工檢查工作定義為評審，符合此定義的靈活實踐也被視為評審。下文将選取靈活中典型的需求評審對應實踐來分析。由于Scrum是目前采納最多的靈活流派，選擇了多個來自于Scrum的實踐來分析，也兼顧了其它靈活流派。

産品待辦清單的優化

Scrum中，産品負責人（英文：Product Owner，縮寫PO)是管理産品待辦清單的唯一責任人[28]。雖然理論上産品負責人可以一個人單獨建立維護産品待辦清單的全部内容，但多數情況下産品負責人是吸收他人貢獻的，産品負責人然後進行整理排序調整優化等等[21]。Scrum中的産品待辦清單優化（Scrum Guide 2011版中其英文名是Grooming，Scrum Guide2013版中其英文名是refinement）指的是為清單項補充細節、估算和排序。這是一個持續不斷的過程，産品負責人和開發團隊協作讨論産品待辦清單項的細節，并對清單項進行評審和修改。對照到本五維需求評審架構，這是定期會議的、技術方面的同級需求文檔評審。因為這個過程中就算産品負責人是團隊的行政上級，也是評審對象的主要作者，而不是評審者。

一般的，産品待辦清單細化的結果用于未來的疊代（Scrum中稱為沖刺），其起到的作用相當于瀑布模型中需求階段的技術方面評審，但耐人尋味的是Scrum Guide說“細化的工作通常占用開發團隊不超過10%的時間。然而，産品負責人可以根據自己的判斷随時更新産品待辦清單。”，而對于隻有1～2次需求評審的傳統瀑布模型而言，需求讨論評審會議所占比例恐怕不超過5%。

Scrum計劃會議第一部分

Scrum中的計劃會議第一部分的問題是：接下來的沖刺（等同于疊代）傳遞的增量中要包含什麼内容?開發團隊預計這個沖刺中要開發的功能。産品負責人講解沖刺的目标以及達成該目标所需要完成的産品待辦清單項。整個Scrum 團隊為了更好地了解沖刺的工作進行讨論。對照到新需求評審架構，這是定期會議側重于管理方面的同級需求文檔評審，與上述産品待辦清單細化同樣是同級評審。

負責需求的産品負責人與團隊一起交流，聽取處理各種各樣意見建議，在管理評審中反而是被評審的對象，這确實是對傳統做法的大突破，而Scrum的流行也說明了這新做法的有效性。對比到瀑布模型，Scrum中的計劃會議第一部分起到的作用相當于瀑布模型中需求階段的裡程碑管理方面評審。值得注意的是，Scrum建議1個月的疊代情況下，計劃會議第一部分約需要4小時，占比約2.3%，整個計劃會議需要8小時。

Scrum每日站會和燃盡圖繪制

每日 Scrum 站會是以 15 分鐘為限的事件，開發團隊成員在這裡分享各自的工作情況，并為接下來的 24小時制定計劃。這需要檢視上個每日站會以來的工作和預測下個每日站會之前所能完成的工作[28]。一般的，Scrum團隊每天繪制沖刺燃盡圖，在沖刺中每日繪制本沖刺未來剩餘的工作量，而此工作量是根據使用者故事或者用例來預測估計的，使用者故事和用例都是需求表達的形式。是以這也相當于需求管理評審，具體對應到新五維需求評審架構，這是會議形式高頻管理方面同級需求文檔評審。

靈活開發過程中需求的澄清和确認

在靈活開發環境下，由于不要求在開始時就有一份完整詳細的需求說明，是以在開發過程中就需要諸如現場客戶或客戶代表來澄清和确認需求。這是各靈活流派共有的實踐。靈活方法鼓勵面對面的交流，是以開發過程中對需求的澄清和确認往往采用桌查，這其實也是一種需求評審的形态，對照到新需求評審架構，這是雙人結對即時高頻技術方面同級評審，而且不再僅僅基于需求文檔，還可以基于軟體運作來判斷需求是否得到滿足，雖然也許不能完全運作，但能夠部分運作，能夠展現界面或接口。在Scrum中，産品負責人承擔響應此類評審（澄清解釋并按需要修改補充）的責任，這個過程中，就算産品負責人是團隊成員的行政上級，也是按同級的身份參與。

這同樣是最高效率的需求評審類型之一，最高效特征有交流回報快，顆粒度小，針對性強，甚至可結合半成品或者成品來核對。

啟示6：需求分析人員和開發人員值得在開發過程中，結合半成品或者成品進行需求桌查，能夠更早更快的避免需求了解偏差帶來的缺陷。

疊代展示

疊代展示是各靈活流派共有的實踐，常見的做法是在疊代末期向各方幹系人展示疊代的成果，甚至直接傳遞給使用者試用或使用。Scrum對此環節有清晰的定義，即是其沖刺（等同于疊代）評審會議：沖刺評審會議在沖刺結束時舉行，用以檢視所傳遞的産品增量并按需調整産品待辦清單；在沖刺評審會議中，Scrum 團隊和相關幹系人讨論沖刺中完成的工作；然後，根據完成情況和沖刺期間産品待辦清單的變化，與參會人員讨論接下來可能要做的事情來優化價值[28]。值得說明的是對于典型一個月的沖刺，其沖刺評審會議的時間箱是4小時。沖刺評審會議可以算作為需求評審和給客戶展示演化的原型[21]。對照到新五維需求評審架構，這是無預審的會議形式、定期的、側重于管理方面也兼顧技術方面、基于軟體運作的非同級評審。

這樣的評審也是最高效率的需求評審類型之一，其高效特征有需求以直覺運作方式展現，客戶或者客戶代表參加，當場收集回報，當場根據回報來計劃未來。

啟示7：讓客戶或者客戶代表定期結合軟體運作來進行評審，更加直覺更能發現改進，可以讓客戶更加滿意。

靈活需求評審小結

綜合以上分析，為便于整體了解，得下表。

表10 靈活開發下常見需求評審相關實踐情況

靈活中需求評審相關實踐	需求評審架構分析說明
Scrum中産品待辦清單細化	無預審的會議，定期，技術方面，同級需求文檔評審
Scrum中計劃會議第一部分	無預審的會議，定期的裡程碑，管理方面，同級需求文檔評審
Scrum每日站會和燃盡圖繪制	無預審的會議，每日高頻，管理方面，同級需求文檔評審
靈活開發中需求澄清和細化	雙人，按需高頻，技術，同級評審，基于軟體運作
疊代展示	無預審的會議，定期，技術方面和管理方面兩者都有，非同級評審，基于軟體運作

可以看到，靈活軟體開發常見的需求評審竟然沒有采納任何一種标準評審，頂多可以說對審查和走查有所借鑒。

啟示8：為了更高效且更高品質的開發軟體，敢于突破原有需求評審标準和權威指南，敢于尋求更高效率的需求評審方式方法。

啟示9：根據啟示8，結合此新五維需求評審架構，結對定期需求文檔或軟體運作管理評審是值得推薦的新評審方式。具體是指管理者每幾天或每周或每雙周與開發人員結對來評審需求相應的狀态、進度、困難和風險，具體形式可以采用師徒制、主程式員制[29]、一對一會議等等。

啟示10：根據啟示8，結合此新五維需求評審架構，非即時按需高頻需求文檔技術方面同級評審也是值得推薦的新評審方式。結合需求條目化管理工具，可以實作逐個需求的同級評審。下文第4章有更詳盡分析。

啟示11：根據啟示8，突破此五維需求評審架構，值得尋求其它更高效更人性化的需求評審方式，比如将遊戲做法、積分更新等等引入到評審中。

新需求評審架構對靈活方法的啟示

啟示12：Scrum對于管理評審的應用是關注于目前和下個疊代，缺失對整體更長過程的關注。雖然已經有在Scrum中補充了釋出計劃和釋出燃盡圖，但并沒有明确定義如何評審或校驗，是以值得開展關注整體産品更長時間範圍發展的定期管理評審會議。