需求迭代與項目風險控制[3]

    能夠預見到的是，需求的每次迭代都會不同程度的對項目產生影響，對此需要評估由此所帶來的成本。不只是項目經理和需求分析工程師，軟件工程師和測試工程師也應該參與這個過程，評估此次迭代是否會影響現有的技術架構，哪些功能點可能受到影響，哪些系統模塊需要修改，測試用例是否應該重新編寫，團隊需要為此次迭代額外付出多少時間成本，是否會造成項目的延期等等。

    評估之后，如果需求迭代對項目的進度可能造成比較明顯的影響，項目經理應該和客戶有效溝通，告知需求迭代的成本，尤其是時間成本。

    另外，需求的每次迭代也必然給項目帶來一定的風險，包括技術風險和發布風險。迭代后的需求可能影響原有的技術方案，尤其是核心業務邏輯的變更。團隊要重新對技術方案進行梳理，檢查該技術方案是否仍然可以達到既定的目的。需求迭代之后，軟件工程師需要一定的時間調整開發進度，測試工程師也需要根據新的需求對系統重新測試，這必然影響項目的發布周期；作為項目經理，應該預見到這一點。

    GS項目是某公司重點研發的一個以政府機關行政審批業務為服務目標的產品，在其進行產品升級改造的同時，其競爭對手也在著手準備同類產品的新版本發布，市場的壓力要求產品盡快完成版本的升級。但是在新產品即將進入集成測試階段的時候，公司突然決定對產品的界面進行比較重大的調整。這一次調整導致代碼和測試的返工，使該產品的發布時間推遲了兩個月，錯過了銷售的黃金期，市場和客戶對于新產品的期待已經逐漸降低，結果產品的銷售量遠遠不如預期。如果公司之前對界面需求迭代有比較清晰的成本和風險評估，那么應該不會這么倉促的觸發迭代。

    Diapers項目團隊意識到Diapers項目的需求迭代的周期是比較短的，因此對于每次迭代的需求，軟件工程師和測試工程師都會協同項目經理進行評估，判斷消化所有需求并測試所需要投入的工作量，以及由此所可能帶來的時間成本和技術風險，團隊成員已經徹底擺脫了害怕需求迭代的心態。

    明確項目發布的需求邊界

    軟件不是十全十美的，需求的迭代是永無止境的。需求的迭代周期是不定的，與其在最終版本中包括所有的需求，不妨在這期間發布若干個小版本，明確每個小版本的需求邊界。這好比長跑途中的若干個里程碑，每跨過一個里程碑就意味著向重點又前進了一步。

    每個小版本都包含有限的功能需求，測試工程師可以針對這些功能需求同步展開測試工作，提早觸發Bug，盡量爭取測試時間?？蛻粢部梢詮倪@些小版本中提前看到真實系統的雛形；隨著版本的逐步升級，項目距離發布日期也越來越近，和需求的差距也越來越小。

原文轉自：http://www.anti-gravitydesign.com