1、進度管理：需求迭代與項目風險控制.2期，其中的案例全部個文章由舜亞科技的Jimmy發表在程序員引自本公司的項目。介紹：柯自聰 /eamoi 舜亞科技軟件工程師，專注于 Web 應用程序開發，關注0A、門戶、電子政務、電子商務領域、RIA,著有Ajax開發精要-概念、案 例與框架一書以及Ajax開發簡略、Liferay Portal二次開發指南等開源 文檔。全文：軟件項目是需求驅動的典型代表，項目從立項、開發、測試到交付，需求 的變化迭代是很正常的事情，這點對于大型項目尤其明顯。需求迭代如果控制不好，很容易增大項目的風險，導致項目的失敗。與國內的很多軟件公司相 似，所參與的項目也存在需求迭代的問

2、題。本文從需求迭代入手，結合項目實 際，探討需求迭代與項目風險控制的關系，希望項目需求有序迭代。需求迭代，不可避免的輪回軟件項目的啟動源于市場和客戶的需求，通過對市場的需求調查以及典型 目標客戶的需求訪問抽象出需求規格說明書，進而才開始原型系統的設計，經 過對原型系統的評估之后啟動真實系統的設計和開發。在原型系統設計階段，由于各種各樣的因素，比如客戶沒有將實際需求表 達清楚，或者需求分析人員對業務的理解有偏差，據此設計出來的原型系統可 能與市場、客戶的真實需求不是很匹配，那么隨著原型系統構建的深入，必然 觸發需求的迭代。在真實系統的設計和開發過程中，隨著對系統的理解的深入，客戶也可能 對需求進

3、行深化、擴展或者變更，研發工程師對需求的消化，這也會觸發需求 的迭代。即使真實系統交付使用，隨著業務的發展，客戶的需求可能發生變化；而且客戶在使用系統的過程中，必然會對系統提出進一步改進的要求，修改原有功能的操作方式，增加新的功能，這些也會要求需求的進rH步迭代。在這一系列的迭代過程中，如果沒有很好的控制迭代的過程，評估迭代的 成本，有效管理迭代的需求，那么很容易形成需求迭代無窮無盡的假象，項目 團隊窮于應付每一次需求迭代，項目開發高度緊張，發布日期遙遙無期，這樣 必然給項目帶來很高的風險。Diapers 項目是一個面向北美市場的電子商務站點，已經運行三年。近客戶 決定對 Diapers 項目

4、進行升級改造。項目經理或者需求分析工程師負責溝通客 戶，分析抽象客戶的真實需求，并撰寫需求說明書；軟件工程師根據需求說明 書擬定技術方案，并著手進行編碼；測試工程師根據需求說明書和測試用例對 項目進行測試；項目經理引導客戶確認項目的終功能呈現，并在必要的時候啟 動需求迭代過程。由于 Diapers 是來自北美的外包項目，雙方的溝通存在時間差，項目團隊也 沒有條件與客戶面對面的溝通。在整個項目的升級改造過程中，由于業務理解 的偏差以及溝通不暢，需求經過了多次迭代；需求每迭代一次，團隊成員都需 要面對一堆冗長的需求說明書。由于 Diapers 已經是正式運營的站點，客戶來自 市場的壓力同時也轉嫁到

5、項目團隊身上，項目發布的壓力一直困擾著團隊成 員。從 Diapers 項目的進展來看，需求的迭代似乎就是無窮無盡的輪回。主動觸發需求迭代，給予足夠的消化時間導致 Diapers 項目的現狀的主要原因是被動的進行需求迭代，迭代被動的由 客戶的反饋觸發。每次需求迭代都可能打亂團隊的開發計劃，影響項目的發布，給團隊帶來更大的發布壓力。因此，必須想方設法掌握需求迭代的主動 權。針對每次需求迭代給予充分的消化時間是一種有效的方式。從 Diapers 項目 的情況來看，上一次需求還沒有消化處理完畢，新的需求迭代又要開始了。項 目發布迭代的速度根本就跟不上需求迭代的速度，新的需求一直步步進逼。在 這種情況下

6、，測試工程師壓根兒就沒有時間對項目進行全面的足夠的測試。找到問題的本質， Diapers 項目團隊開始調整發布節奏，加大人力資源投 入，加快消化需求的速度；針對溝通不足的問題，項目經理集中精力與客戶溝 通，在雙方時間交叉的部分盡量把有疑問的需求溝通清楚；發布節奏調整后， 客戶就有時間與項目團隊同步開展測試工作， bug 也能夠在時間處理。調整后， 項目團隊有足夠的時間來消化每次迭代的需求，也有足夠的時間對項目進行測 試。盡早發布原型系統是主動觸發需求迭代的另一種有效方式。原型系統通常 快速構建，著重在界面的呈現和功能的模擬，通過虛擬數據模擬真實系統的運 行情況。其能夠在很大程度上模擬未來真實系

7、統的呈現，在短時間內將抽象的 客戶需求表現出來，作為和客戶進行溝通的有效媒介。相對于一堆抽象的文 檔，使用原型系統，客戶更容易盡早發現真實系統與他們的需求之間的差距， 減少未來需求迭代的次數。因此，在需求抽象過程中，應該通過原型系統作為雙方溝通的橋梁和媒 介，雙方應該先就原型系統的呈現展開討論。另外，原型系統的發布時間也是 比較重要的，在項目啟動后應該盡早發布原型系統。Claim項目則是一個商業意外險理賠平臺，為北美客戶提供商業意外險的在線申報、理賠服務。在項目啟動的初期，項目團隊在理解抽象需求的基礎上，時間發布了原型系統，使用虛擬數據模擬真實系統的界面呈現。這個項目比較 有利的是，客戶自己聘

8、請了需求分析人員，能夠程度的理解業務需求，正確的 表述客戶的需求，并繪制詳細的原型界面；這點在雙方的溝通和系統開發過程 中發揮了比較顯著的作用。由于 Claim 項目的需求迭代節奏一直在項目團隊的可 接受范圍，所以項目一直有條不紊的推進，雖然需求也經過了多次迭代，但終 歸還在可控的范圍內。評估每一次迭代的成本和風險能夠預見到的是，需求的每次迭代都會不同程度的對項目產生影響，對此 需要評估由此所帶來的成本。不只是項目經理和需求分析工程師，軟件工程師 和測試工程師也應該參與這個過程，評估此次迭代是否會影響現有的技術架 構，哪些功能點可能受到影響，哪些系統模塊需要修改，測試用例是否應該重 新編寫，團

9、隊需要為此次迭代額外付出多少時間成本，是否會造成項目的延期 等等。評估之后，如果需求迭代對項目的進度可能造成比較明顯的影響，項目經 理應該和客戶有效溝通，告知需求迭代的成本，尤其是時間成本。另外，需求的每次迭代也必然給項目帶來一定的風險，包括技術風險和發 布風險。迭代后的需求可能影響原有的技術方案，尤其是核心業務邏輯的變 更。團隊要重新對技術方案進行梳理，檢查該技術方案是否仍然可以達到既定 的目的。需求迭代之后，軟件工程師需要一定的時間調整開發進度，測試工程 師也需要根據新的需求對系統重新測試，這必然影響項目的發布周期；作為項 目經理，應該預見到這一點。GS項目是某公司重點研發的一個以政府機關

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

11、會協同項目經理進行評估, 判斷消化所有需求并測試所需要投入的工作量，以及由此所可能帶來的時間成 本和技術風險，團隊成員已經徹底擺脫了害怕需求迭代的心態。明確項目發布的需求邊界軟件不是十全十美的，需求的迭代是永無止境的。需求的迭代周期是不定 的，與其在終版本中包括所有的需求，不妨在這期間發布若干個小版本，明確 每個小版本的需求邊界。這好比長跑途中的若干個里程碑，每跨過一個里程碑 就意味著向重點又前進了一步。每個小版本都包含有限的功能需求，測試工程師可以針對這些功能需求同 步展開測試工作，提早觸發 Bug，盡量爭取測試時間。客戶也可以從這些小版本 中提前看到真實系統的雛形；隨著版本的逐步升級，項目

12、距離發布日期也越來 越近，和需求的差距也越來越小。工欲善其事，必先利其器。我們可以利用一些現成的工具來管理需求邊界 和跟蹤Bug,比如JIRA JIRA是集項目計劃、任務分配、需求管理、錯誤跟蹤于一體的商業軟件，其提供了問題跟蹤管理、問題跟進情況的分析報告、項目類 別管理、組件 /模塊負責人、項目 email 地址等功能。許多著名的開源項目都采 用了 JIRA。通過JIRA可以整合客戶、項目經理、開發人員、測試人員，使各種角色 各司其職，團隊內部信息能夠很快得到交流和反饋，潛在的問題提前暴露，促 進項目的可控。JIRA以工作流的思想融合了項目管理、任務管理和缺陷管理等思維，允許設定項目的模塊和

13、版本，并為每個需求設置預期日期，將任務的處理指定到 人。JIRA允許為每個項目設置優先級，比如Blocker、Critical、Major、Min or、Trivial，標識每個任務的重要程度。如果任務定義了優先級，那么在每個人的桌面上，任務會自動排列。這點 對于多任務的項目尤其重要。預見到需求迭代的被動性后，Diapers項目團隊在Diapers項目上全面啟動了 JIRA進行項目管理，將需求分解細化后進入 JIRA排定任務的優先級并指定 到人，確定每次小版本發布的需求編號，不定期的發布小版本。結合SVN等版 本控制工具， Diapers 項目團隊能夠將功能需求迭代的粒度控制到小，項目逐步 推

14、進，客戶對項目的進度有充分的了解，項目經理也能夠準確把握項目的進 度，團隊中充滿了樂觀的情緒。安撫團隊成員的情緒工程師對于冗長的需求說明書有天生的恐懼感，開發周期拉得太長，似乎 需求迭代無窮無盡。如果需求的迭代周期不在可控范圍之內，項目的發布邊界模糊不清，項目發布的日期自然也遙遙無期。由此帶來的結果是團隊每天緊趕 慢趕的跟蹤需求迭代，消化處理新的需求，工作氣氛也是高度緊張。每一次需求迭代，都會進一步增加這種緊張情緒。項目經理應該把握項目的進展情況以及客戶的真實需求，也要知悉客戶的 需求底線，更要在必要的時候安撫團隊成員的情緒。當原始需求次被抽象出來的時候，團隊的要務是快速構建原型系統作為和 客戶溝通的主要媒介和依據，項目經理應該引導團隊把握這一點。之后的每一次需求迭代，項目經理要將需求分解細化，控制需求的粒度， 并且確定優先級，消除團隊成員的焦急情緒，按照先后順序逐步的處理每一個 粒度的需求，以發布每階段的小版本為階段性的目標。在這個過