需求條目化管理是指需求的主體分條目管理，比如對于用例、用戶故事、特征點的條目化列表管理，有些工具中條目稱為工作項(work item)。條目化管理的特征是1，狀態流轉實現工作流；2，條目屬性字段可定制。3.3節所分析的敏捷開發下的需求絕大多數是已經實現了條目化管理，產品待辦列表就是Scrum進行條目化管理的載體。而條目化需求管理并不是敏捷開發的專利，當前已經有不少組織在非敏捷環境下采用條目化需求管理。在需求條目化管理的情況下，按照新需求評審框架，可以識別到如下高效的評審方式。

逐條開展高頻非即時技術同級評審

逐條開展高頻非即時技術同級評審是指當需求條目到達指定狀態（如下圖1中的“已分析”）時，邀請相應評審者按工作流功能進行逐條評審，每條評審的結果是獨立記錄跟蹤的。雖然這是非即時評審，但在工具支持下，能夠方便的記錄評論和發現，相應人員能夠自動的收到電子郵件，甚至即時通訊消息，能夠像論壇一樣評論參與，各方針對指定條目展開線上討論，這樣就獲得了部分即時評審的好處。而且非即時評審時間安排更靈活，也更有深入思考的機會，也能留下全部的記錄。這點得到了[22]文的支持。
啟示13：在需求條目化管理工具幫助下，非即時需求評審可以高效的開展。

全程的需求跟蹤評審

全程的需求跟蹤評審是指在需求條目化管理下跟蹤需求條目的全部生命周期，進行全程關鍵點的評審。結合需求條目化管理工具的工作流功能，可以對需求條目全程跟蹤評審。典型的需求條目工作流如圖1所示。

圖1 需求條目狀態流轉示意圖

在這樣的全程跟蹤的情況下，對需求階段里程碑評審的依賴大大降低，甚至可以不再需要需求階段里程碑。因為每條需求都得到全程跟蹤，每個步驟相當于一次評審。而且隨著開發進展，有更多信息幫助進行正確的評審，多個角色參與此全程跟蹤，結合圖1，跟蹤過程見下表
表11 需求條目流程關鍵點的評審

狀態流轉關鍵點的評審

從草稿到已分析	需求分析人員內部評審（比如同級互查），通過后狀態流轉到“已分析”，顯然這是基于文檔的。
從已分析到已評審	由對產品需求負責的人員擔當，常見有產品經理、項目經理或者產品負責人，如果工具有并行審批功能，可讓多人參與此審批，這相當于需求里程碑評審的簽署。
從已評審到已設計	由開發人員跟蹤需求得到設計的覆蓋，這仍然是基于文檔的。
從已設計到已實現	由開發人員內部校驗需求是否被正確實現，這是基于軟件運行的評審。
從已實現到已核對	由需求分析人員來驗證實現是否符合當初的需求，這是基于軟件運行的評審。
從已核對到已測試	由測試人員根據測試來校對需求是否得到正確實現，這也是基于軟件運行的評審，這里與測試有所重疊，但這里是對需求本身的跟蹤，與測試對于測試用例的執行是不一樣的，當然可以根據需求對應測試用例的執行結果來跟蹤需求。

也即是說，通過條目化管理工具，可以將原來傳統瀑布下需求階段里程碑評審分解到每條需求的多個角色的多次評審，更加全面的保證需求得到實現。
對于需求變更的情況，條目化管理工具天然支持具體內容的需求變更，與需求評審天然的整合在一起。上述需求條目狀態流程圖中已經支持了需求變更，當發生需求變更時，狀態退回到草稿，然后是相同的流轉過程，變更得到嚴謹的歸一化管理，這是高效的特征，也滿足軟件需求變更管理的要求[6][26]。上述整體流程使得各方清晰的承擔責任，全過程可審計可回溯，能夠及時發現問題，并跟蹤直到解決。所以整體流程具備極佳的自適應能力，出現異常或者問題時，各方會迅速聯動解決。
根據以上分析，得到如下啟示。
啟示14：采用需求條目化工具來管理需求，多方全程跟蹤評審需求，從文檔閱讀評審到軟件運行評審，多種驗證和確認手段得到應用，確保需求得到正確實現，也能及時發現不一致，并且也能靈活的變更。

需求條目化管理下優化瀑布模型

結合以上所有啟示來優化瀑布模型，此優化瀑布模型的主要特征是：
1)采用需求條目化管理，采用如圖1的需求流程，全程跟蹤評審需求；
2)組建產品經理組（可以只有一位產品經理），由產品經理組對需求分批次甚至逐個進行需求評審，多采用離線和雙人即時互動方式，不再進行沉重的需求里程碑會議評審，由產品經理根據需要來組織會議討論評審。部分需求條目到達“已評審”狀態后，即可開展設計，全部需求條目到達或超過“已評審”，即是達成需求里程碑；
3)設計的顆粒度為組件與組件之間關系，如有必要，識別到少數核心類，但不要求識別所有類。也即是設計對于需求條目的覆蓋是粗粒度的，需求條目能夠被識別出的組件覆蓋到即可。部分需求條目到達“已設計”狀態后，即可開展編碼，所有需求條目到達或超過“已設計”即是達成設計里程碑；
4)開發人員進行編碼實現。所有需求條目到達或超過“已實現”即是達成實現里程碑。部分需求條目到達“已實現”狀態后，即可開展核對；
5)核對是由產品經理組執行，根據代碼實現的結果來判斷實現是否符合原需求條目。核對不算是測試，只判斷主要功能和界面是否符合需求。部分需求條目到達“已核對”狀態后，即可開展測試，所有需求條目到達或超過“已核對”即是達成核對里程碑；
6)測試是由測試人員執行。測試用例應當關聯到對應的需求條目，需求條目對應的全部測試用例測試通過后，該需求條目可跟蹤到“已測試”。當所有需求條目到達“已測試”，即時完成測試里程碑，可以進行后續交付上線等；
7)演示，試用，或者交付上線；
8)以上活動按需求條目分別迭代進行，由于需求條目化管理后的便利性，一個瀑布的時間長度可以像敏捷短迭代一樣在1周～8周，可以形象的稱為多級小瀑布。
啟示15：在需求條目化管理工具的支持下，值得探索和應用多級小瀑布生命周期模型，其兼有傳統瀑布模型和敏捷迭代開發的好處，又規避了傳統瀑布模型的弊端。
本多級小瀑布模型已經在筆者工作或者輔導過的幾家公司實施，取得了良好的效果。原先傳統瀑布模型中上下環節銜接問題在需求變更的情況下是巨大的困難。而在多級小瀑布模型下此問題得到了明顯的改善。上下游銜接以小顆粒度的需求條目為根據，下游能夠及時的針對性的督促上游，也能基于上游先期完成的部分條目盡早開展工作，不必等待上游里程碑結束后再開始；而上游同樣能以小顆粒度來跟蹤需求條目在后續的情況，及時盡早發現潛在不一致問題。各級上下游形成了高效的、互相監督、互相督促、閉環的自適應機制。

總結

以上是生活随笔為你收集整理的需求评审五个维度框架分析及其带来的启示-4-需求条目化管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。