需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指軟件開發(fā)的常見情境，本文選擇如下來進(jìn)行分析：
1. 傳統(tǒng)瀑布模型開發(fā)下的需求評審
2. 使用IEEE Std. 1028的需求評審
3. 敏捷開發(fā)下的需求評審
傳統(tǒng)瀑布模型下的需求評審
對傳統(tǒng)瀑布模型現(xiàn)有需求評審的分析
傳統(tǒng)瀑布模型在需求階段末期安排有關(guān)鍵的需求里程碑評審，其特征參見2.8節(jié)情況1。在業(yè)界實(shí)際操作中，往往出現(xiàn)如下情況：
1，召集包括領(lǐng)導(dǎo)在內(nèi)的各方代表，歷經(jīng)1～2小時會議，評審30頁以上需求規(guī)格說明書，走過場式各方簽字通過評審；
2，各方對需求規(guī)格書有各種各樣意見，歷經(jīng)3～n次評審會，眼看工期已經(jīng)有明顯拖延，后續(xù)開發(fā)已經(jīng)跟進(jìn)，甚至開發(fā)快完成了，總算獲得通過；
3，經(jīng)過多方運(yùn)籌協(xié)調(diào)，前后費(fèi)時4周多，召集各方到某度假村，歷經(jīng)三天討論修改評審，總算通過評審。
以上情況就體現(xiàn)了前文所言的“官僚繁瑣、繁文縟節(jié)”，其弊端明顯。在[26]文同樣也識別到：需求評審?fù)饔谛问健?
受CMM/CMMI要求和啟發(fā)，為了讓需求階段最后的里程碑評審能夠順利通過，需求同級評審得到了使用[12][13]。常見有如下情況：
1，在需求完稿時，計(jì)劃一次同級評審會議，關(guān)注于技術(shù)方面，形成同級評審發(fā)現(xiàn)和記錄。這對勝利通過里程碑評審有很大幫助，但往往是更為了應(yīng)付CMM/CMMI的評估；
2，分階段安排多次會議或非即時的需求同級評審，關(guān)注技術(shù)方面，記錄評審發(fā)現(xiàn)并解決。這是CMM/CMMI比較推薦的做法，能大大緩解瀑布型需求階段里程碑評審的弊端。
綜合以上分析，為便于整體理解，得下表。
表8 瀑布模型下需求評審情況
| 需求里程碑評審 | 有預(yù)審的會議形式，里程碑，技術(shù)和管理方面，非同級需求文檔評審 |
| 需求完稿同級評審 | 有預(yù)審的會議形式，完稿，技術(shù)方面，同級需求文檔評審 |
| 分段需求同級評審 | 有預(yù)審的會議形式，分段，技術(shù)方面，同級需求文檔評審 |
新需求評審框架對傳統(tǒng)瀑布模型的啟示
啟示1：值得開展定期的雙人即時評審，每次時間約15～30分鐘，適合位置坐在一起的團(tuán)隊(duì)同伴。好處：盡早交流，彼此學(xué)習(xí)。
啟示2：值得把技術(shù)方面評審與管理方面評審分開，先進(jìn)行各種類型的技術(shù)方面評審，然后召開里程碑管理方面評審。好處：技術(shù)方面評審問題解決后，需求階段里程碑評審著重于管理方面，比如需求規(guī)模、進(jìn)度、工作量等等，更加關(guān)注項(xiàng)目整體成功，也能大大節(jié)約會議時間。
使用IEEE Std. 1028的需求評審
對照到需求評審，IEEE Std. 1028中的管理評審、技術(shù)評審、審查和走查可以適用于需求評審，而其中的審計(jì)不屬于本文所討論的需求評審范疇。
管理評審
IEEE Std. 1028說明管理評審（Management Reviews)用于監(jiān)測進(jìn)展情況，判斷計(jì)劃和進(jìn)度表的狀態(tài)，或評估為了達(dá)成合適目標(biāo)的管理方法的有效性；管理評審支持關(guān)于糾正措施、資源分配變更或者項(xiàng)目范圍變更的決策；管理評審識別與計(jì)劃的一致性和差異，或者識別管理流程的完善度和不足度。在需求管理評審的實(shí)踐中，最焦點(diǎn)問題是需求范圍和規(guī)模是否與計(jì)劃相匹配。有些組織在需求之前制定了計(jì)劃，那么需求實(shí)際的結(jié)果是否需要重新計(jì)劃；有些組織把項(xiàng)目整體計(jì)劃的制定安排在需求之后，那么需要判斷前期進(jìn)展如何，對后面制定計(jì)劃有什么影響。
管理評審有詳盡的規(guī)范，從角色、會前、會中、會后、到輸入和輸出等等。它成為IEEE Std.1028首先闡述的評審類型絕非徒有虛名，雖然它有沉重繁瑣的嫌疑，但對于謹(jǐn)慎多干系人場合，仍然是關(guān)鍵里程碑評審的首選甚至是必須的評審類型。在本五維需求評審框架中，管理評審在絕大多數(shù)情況下屬于有預(yù)審的會議形式里程碑性質(zhì)的管理方面非同級需求文檔評審，它提供了管理方面評審的最系統(tǒng)性的“極點(diǎn)”。
技術(shù)評審
技術(shù)評審的目的是由合格人員組成的團(tuán)隊(duì)來評價一個軟件產(chǎn)物，以判斷是否適合其預(yù)期用途，并識別對比于規(guī)范和標(biāo)準(zhǔn)的差異。它為管理層提供證實(shí)該項(xiàng)目技術(shù)狀態(tài)的證據(jù)，也可能提供替代方案建議，可能需要一個以上的會議。
同管理評審一樣，技術(shù)評審有詳盡的規(guī)范。技術(shù)評審是最廣為人知的一個評審類型，早在1996年出版的《實(shí)用軟件工程》（第2版）[9]對此也有詳細(xì)的闡述。在實(shí)踐中技術(shù)評審常常擔(dān)當(dāng)里程碑評審的重任，而至于管理評審，其關(guān)注內(nèi)容成為技術(shù)評審的一小部分，而不再有專門的管理評審。在本五維需求評審框架中，技術(shù)評審在絕大多數(shù)情況下屬于有預(yù)審的會議形式里程碑性質(zhì)的技術(shù)方面非同級需求文檔評審，它提供了技術(shù)方面評審的最系統(tǒng)性的“極點(diǎn)”。
啟示3：理解管理評審和技術(shù)評審在五維需求評審框架中的位置，在實(shí)際工作中靈活應(yīng)用這兩項(xiàng)評審，更加有把握的對其進(jìn)行適應(yīng)性的剪裁，使其發(fā)揮更高效率，盡量規(guī)避為人詬病的沉重繁瑣的弊端。
審查
審查對應(yīng)的英文是Inspection，其目的是檢測和識別軟件產(chǎn)品的異常情況。審查是一個系統(tǒng)性的同級檢查。審查定義了5個角色，分別是審查領(lǐng)導(dǎo)者、記錄員、閱讀者、作者、審查員。任何審查組成員（包括以上5個角色）的上級都不能參加審查活動。審查應(yīng)當(dāng)?shù)玫接?jì)劃并記錄在恰當(dāng)?shù)捻?xiàng)目計(jì)劃文檔中，審查開始前需要確認(rèn)被審查產(chǎn)物是完整的并且符合格式要求，審查后需要記錄評審產(chǎn)物的規(guī)模、會中會前時間、返工時間等等。
點(diǎn)評：審查在IEEE Std. 1028得到了嚴(yán)格定義，給出了詳盡的規(guī)范指導(dǎo)。在本五維需求評審框架中，審查屬于有預(yù)審的會議形式完稿技術(shù)方面同級評審，同樣是同級評審最系統(tǒng)性的“極點(diǎn)”。 審查要求完整產(chǎn)物，并不能盡早發(fā)現(xiàn)問題。
啟示4：值得探索和使用更輕量更高效更及時的需求同級評審。
走查
系統(tǒng)性的走查目的是為了評估一個軟件產(chǎn)品。走查可能也會有讓培訓(xùn)軟件產(chǎn)品受眾的目的。走查的作用還有交流技術(shù)、交流不同風(fēng)格變化。 走查不僅可以發(fā)現(xiàn)異常，也可以指出不足之處（例如，軟件產(chǎn)品的效率和可讀性問題，設(shè)計(jì)或代碼的模塊化問題，或無法驗(yàn)證的規(guī)格）。參與走查有4個角色，分別是走查組長、記錄者、作者、走查成員，走查至少需要2人。任何走查組成員的行政上級都不能參加走查。走查的最主要活動是作者或走查組長詳細(xì)的展現(xiàn)所評審產(chǎn)物的每個部分，走查組識別并提出發(fā)現(xiàn)的異常和問題。走查的標(biāo)準(zhǔn)最少輸出物總計(jì)有9項(xiàng)。走查不要求產(chǎn)物已經(jīng)全部完成，可以按需高頻開展。
在本五維需求評審框架中，走查屬于有預(yù)審的雙人即時或者會議形式、技術(shù)方面的定期或高頻的同級需求文檔評審。雙人走查是標(biāo)準(zhǔn)允許的最少人數(shù)。雙人走查與會議形式走查其實(shí)存在較大的差異：雙人走查可以使用一臺普通顯示器，利用普通能夠坐下兩人的工作位置即可，這樣就能夠高頻按需開展，會議形式往往需要會議室，而會議室在多數(shù)組織是稀缺資源，如果所有項(xiàng)目團(tuán)隊(duì)都開展需求和代碼會議走查，那么每二周一次的會議室預(yù)訂都未必能夠保證，所以難以按需開展。代碼走查是常聽到的詞匯，但是需求走查在中文世界很少提到，而在敏捷軟件開發(fā)中已經(jīng)顯示了其有效性。
啟示5：值得探索和使用雙人高頻按需的需求走查或者簡化的需求走查。
IEEE評審小計(jì)
綜合以上分析，為便于整體理解，得下表。
表9 IEEE標(biāo)準(zhǔn)需求評審情況
| 管理評審 | 有預(yù)審的會議形式，里程碑，管理方面，非同級需求文檔評審 |
| 技術(shù)評審 | 有預(yù)審的會議形式，里程碑，技術(shù)方面，非同級需求文檔評審 |
| 審查 | 有預(yù)審的會議形式，完稿，技術(shù)方面，同級需求文檔評審 |
| 走查 | 有預(yù)審的雙人或者會議，定期或者高頻，技術(shù)方面，同級需求文檔評審 |
敏捷開發(fā)下的需求評審
首先要說明，在敏捷開發(fā)語境中，幾乎不使用“評審”這詞，常用“驗(yàn)證”、“驗(yàn)收”、“反饋”等。本文將基于文檔閱讀或者觀察軟件運(yùn)行的時效性人工檢查工作定義為評審，符合此定義的敏捷實(shí)踐也被視為評審。下文將選取敏捷中典型的需求評審對應(yīng)實(shí)踐來分析。由于Scrum是目前采納最多的敏捷流派，選擇了多個來自于Scrum的實(shí)踐來分析，也兼顧了其它敏捷流派。
產(chǎn)品待辦列表的優(yōu)化
Scrum中，產(chǎn)品負(fù)責(zé)人（英文：Product Owner，縮寫PO)是管理產(chǎn)品待辦列表的唯一責(zé)任人[28]。雖然理論上產(chǎn)品負(fù)責(zé)人可以一個人單獨(dú)創(chuàng)建維護(hù)產(chǎn)品待辦列表的全部內(nèi)容，但多數(shù)情況下產(chǎn)品負(fù)責(zé)人是吸收他人貢獻(xiàn)的，產(chǎn)品負(fù)責(zé)人然后進(jìn)行整理排序調(diào)整優(yōu)化等等[21]。Scrum中的產(chǎn)品待辦列表優(yōu)化（Scrum Guide 2011版中其英文名是Grooming，Scrum Guide2013版中其英文名是refinement）指的是為列表項(xiàng)補(bǔ)充細(xì)節(jié)、估算和排序。這是一個持續(xù)不斷的過程，產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)協(xié)作討論產(chǎn)品待辦列表項(xiàng)的細(xì)節(jié)，并對列表項(xiàng)進(jìn)行評審和修改。對照到本五維需求評審框架，這是定期會議的、技術(shù)方面的同級需求文檔評審。因?yàn)檫@個過程中就算產(chǎn)品負(fù)責(zé)人是團(tuán)隊(duì)的行政上級，也是評審對象的主要作者，而不是評審者。
一般的，產(chǎn)品待辦列表細(xì)化的結(jié)果用于未來的迭代（Scrum中稱為沖刺），其起到的作用相當(dāng)于瀑布模型中需求階段的技術(shù)方面評審，但耐人尋味的是Scrum Guide說“細(xì)化的工作通常占用開發(fā)團(tuán)隊(duì)不超過10%的時間。然而，產(chǎn)品負(fù)責(zé)人可以根據(jù)自己的判斷隨時更新產(chǎn)品待辦列表。”，而對于只有1～2次需求評審的傳統(tǒng)瀑布模型而言，需求討論評審會議所占比例恐怕不超過5%。
Scrum計(jì)劃會議第一部分
Scrum中的計(jì)劃會議第一部分的問題是：接下來的沖刺（等同于迭代）交付的增量中要包含什么內(nèi)容?開發(fā)團(tuán)隊(duì)預(yù)計(jì)這個沖刺中要開發(fā)的功能。產(chǎn)品負(fù)責(zé)人講解沖刺的目標(biāo)以及達(dá)成該目標(biāo)所需要完成的產(chǎn)品待辦列表項(xiàng)。整個Scrum 團(tuán)隊(duì)為了更好地了解沖刺的工作進(jìn)行討論。對照到新需求評審框架，這是定期會議側(cè)重于管理方面的同級需求文檔評審，與上述產(chǎn)品待辦列表細(xì)化同樣是同級評審。
負(fù)責(zé)需求的產(chǎn)品負(fù)責(zé)人與團(tuán)隊(duì)一起交流，聽取處理各種各樣意見建議，在管理評審中反而是被評審的對象，這確實(shí)是對傳統(tǒng)做法的大突破，而Scrum的流行也說明了這新做法的有效性。對比到瀑布模型，Scrum中的計(jì)劃會議第一部分起到的作用相當(dāng)于瀑布模型中需求階段的里程碑管理方面評審。值得注意的是，Scrum建議1個月的迭代情況下，計(jì)劃會議第一部分約需要4小時，占比約2.3%，整個計(jì)劃會議需要8小時。
Scrum每日站會和燃盡圖繪制
每日 Scrum 站會是以 15 分鐘為限的事件，開發(fā)團(tuán)隊(duì)成員在這里分享各自的工作情況，并為接下來的 24小時制定計(jì)劃。這需要檢視上個每日站會以來的工作和預(yù)測下個每日站會之前所能完成的工作[28]。一般的，Scrum團(tuán)隊(duì)每天繪制沖刺燃盡圖，在沖刺中每日繪制本沖刺未來剩余的工作量，而此工作量是根據(jù)用戶故事或者用例來預(yù)測估計(jì)的，用戶故事和用例都是需求表達(dá)的形式。所以這也相當(dāng)于需求管理評審，具體對應(yīng)到新五維需求評審框架，這是會議形式高頻管理方面同級需求文檔評審。
敏捷開發(fā)過程中需求的澄清和確認(rèn)
在敏捷開發(fā)環(huán)境下，由于不要求在開始時就有一份完整詳細(xì)的需求說明，所以在開發(fā)過程中就需要諸如現(xiàn)場客戶或客戶代表來澄清和確認(rèn)需求。這是各敏捷流派共有的實(shí)踐。敏捷方法鼓勵面對面的交流，所以開發(fā)過程中對需求的澄清和確認(rèn)往往采用桌查，這其實(shí)也是一種需求評審的形態(tài)，對照到新需求評審框架，這是雙人結(jié)對即時高頻技術(shù)方面同級評審，而且不再僅僅基于需求文檔，還可以基于軟件運(yùn)行來判斷需求是否得到滿足，雖然也許不能完全運(yùn)行，但能夠部分運(yùn)行，能夠展現(xiàn)界面或接口。在Scrum中，產(chǎn)品負(fù)責(zé)人承擔(dān)響應(yīng)此類評審（澄清解釋并按需要修改補(bǔ)充）的責(zé)任，這個過程中，就算產(chǎn)品負(fù)責(zé)人是團(tuán)隊(duì)成員的行政上級，也是按同級的身份參與。
這同樣是最高效率的需求評審類型之一，最高效特征有交流反饋快，顆粒度小，針對性強(qiáng)，甚至可結(jié)合半成品或者成品來核對。
啟示6：需求分析人員和開發(fā)人員值得在開發(fā)過程中，結(jié)合半成品或者成品進(jìn)行需求桌查，能夠更早更快的避免需求理解偏差帶來的缺陷。
迭代展示
迭代展示是各敏捷流派共有的實(shí)踐，常見的做法是在迭代末期向各方干系人展示迭代的成果，甚至直接交付給用戶試用或使用。Scrum對此環(huán)節(jié)有清晰的定義，即是其沖刺（等同于迭代）評審會議：沖刺評審會議在沖刺結(jié)束時舉行，用以檢視所交付的產(chǎn)品增量并按需調(diào)整產(chǎn)品待辦列表；在沖刺評審會議中，Scrum 團(tuán)隊(duì)和相關(guān)干系人討論沖刺中完成的工作；然后，根據(jù)完成情況和沖刺期間產(chǎn)品待辦列表的變化，與參會人員討論接下來可能要做的事情來優(yōu)化價值[28]。值得說明的是對于典型一個月的沖刺，其沖刺評審會議的時間箱是4小時。沖刺評審會議可以算作為需求評審和給客戶展示演化的原型[21]。對照到新五維需求評審框架，這是無預(yù)審的會議形式、定期的、側(cè)重于管理方面也兼顧技術(shù)方面、基于軟件運(yùn)行的非同級評審。
這樣的評審也是最高效率的需求評審類型之一，其高效特征有需求以直觀運(yùn)行方式展現(xiàn)，客戶或者客戶代表參加，當(dāng)場收集反饋，當(dāng)場根據(jù)反饋來計(jì)劃未來。
啟示7：讓客戶或者客戶代表定期結(jié)合軟件運(yùn)行來進(jìn)行評審，更加直觀更能發(fā)現(xiàn)改進(jìn)，可以讓客戶更加滿意。
敏捷需求評審小結(jié)
綜合以上分析，為便于整體理解，得下表。
表10 敏捷開發(fā)下常見需求評審相關(guān)實(shí)踐情況
| Scrum中產(chǎn)品待辦列表細(xì)化 | 無預(yù)審的會議，定期，技術(shù)方面，同級需求文檔評審 |
| Scrum中計(jì)劃會議第一部分 | 無預(yù)審的會議，定期的里程碑，管理方面，同級需求文檔評審 |
| Scrum每日站會和燃盡圖繪制 | 無預(yù)審的會議，每日高頻，管理方面，同級需求文檔評審 |
| 敏捷開發(fā)中需求澄清和細(xì)化 | 雙人，按需高頻，技術(shù)，同級評審，基于軟件運(yùn)行 |
| 迭代展示 | 無預(yù)審的會議，定期，技術(shù)方面和管理方面兩者都有，非同級評審，基于軟件運(yùn)行 |
可以看到，敏捷軟件開發(fā)常見的需求評審竟然沒有采納任何一種標(biāo)準(zhǔn)評審，頂多可以說對審查和走查有所借鑒。
啟示8：為了更高效且更高質(zhì)量的開發(fā)軟件，敢于突破原有需求評審標(biāo)準(zhǔn)和權(quán)威指南，敢于尋求更高效率的需求評審方式方法。
啟示9：根據(jù)啟示8，結(jié)合此新五維需求評審框架，結(jié)對定期需求文檔或軟件運(yùn)行管理評審是值得推薦的新評審方式。具體是指管理者每幾天或每周或每雙周與開發(fā)人員結(jié)對來評審需求相應(yīng)的狀態(tài)、進(jìn)度、困難和風(fēng)險，具體形式可以采用師徒制、主程序員制[29]、一對一會議等等。
啟示10：根據(jù)啟示8，結(jié)合此新五維需求評審框架，非即時按需高頻需求文檔技術(shù)方面同級評審也是值得推薦的新評審方式。結(jié)合需求條目化管理工具，可以實(shí)現(xiàn)逐個需求的同級評審。下文第4章有更詳盡分析。
啟示11：根據(jù)啟示8，突破此五維需求評審框架，值得尋求其它更高效更人性化的需求評審方式，比如將游戲做法、積分升級等等引入到評審中。
新需求評審框架對敏捷方法的啟示
啟示12：Scrum對于管理評審的應(yīng)用是關(guān)注于當(dāng)前和下個迭代，缺失對整體更長過程的關(guān)注。雖然已經(jīng)有在Scrum中補(bǔ)充了發(fā)布計(jì)劃和發(fā)布燃盡圖，但并沒有明確定義如何評審或校驗(yàn)，因此值得開展關(guān)注整體產(chǎn)品更長時間范圍發(fā)展的定期管理評審會議。
總結(jié)
以上是生活随笔為你收集整理的需求评审五个维度框架分析及其带来的启示-3-典型需求评审的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 需求评审五个维度框架分析及其带来的启示-
- 下一篇： 需求评审五个维度框架分析及其带来的启示-