需求迭代與項目風險控制

　　軟件項目是需求驅動的典型代表，項目從立項、開發、測試到交付，需求的變化迭代是很正常的事情，這點對于大型項目尤其明顯。需求迭代如果控制不好，很容易增大項目的風險，導致項目的失敗。與國內的很多軟件公司相似，筆者所參與的項目也存在需求迭代的問題。本文從需求迭代入手，結合項目實際，探討需求迭代與項目風險控制的關系，希望項目需求有序迭代。

　　需求迭代，不可避免的輪回

　　軟件項目的啟動源于市場和客戶的需求，通過對市場的需求調查以及典型目標客戶的需求訪問抽象出需求規格說明書，進而才開始原型系統的設計，經過對原型系統的評估之后啟動真實系統的設計和開發。

　　在原型系統設計階段，由于各種各樣的因素，比如客戶沒有將實際需求表達清楚，或者需求分析人員對業務的理解有偏差，據此設計出來的原型系統可能與市場、客戶的真實需求不是很匹配，那么隨著原型系統構建的深入，必然觸發需求的迭代。

　　在真實系統的設計和開發過程中，隨著對系統的理解的深入，客戶也可能對需求進行深化、擴展或者變更，研發工程師對需求的消化，這也會觸發需求的迭代。

　　即使真實系統交付使用，隨著業務的發展，客戶的需求可能發生變化；而且客戶在使用系統的過程中，必然會對系統提出進一步改進的要求，修改原有功能的操作方式，增加新的功能，這些也會要求需求的進一步迭代。

　　在這一系列的迭代過程中，如果沒有很好的控制迭代的過程，評估迭代的成本，有效管理迭代的需求，那么很容易形成需求迭代無窮無盡的假象，項目團隊窮于應付每一次需求迭代，項目開發高度緊張，發布日期遙遙無期，這樣必然給項目帶來很高的風險。

　　Diapers項目是一個面向北美市場的電子商務站點，已經運行三年。最近客戶決定對Diapers項目進行升級改造。項目經理或者需求分析工程師負責溝通客戶，分析抽象客戶的真實需求，并撰寫需求說明書；軟件工程師根據需求說明書擬定技術方案，并著手進行編碼；測試工程師根據需求說明書和測試用例對項目進行測試；項目經理引導客戶確認項目的最終功能呈現，并在必要的時候啟動需求迭代過程。

　　由于Diapers是來自北美的外包項目，雙方的溝通存在時間差，項目團隊也沒有條件與客戶面對面的溝通。在整個項目的升級改造過程中，由于業務理解的偏差以及溝通不暢，需求經過了多次迭代；需求每迭代一次，團隊成員都需要面對一堆冗長的需求說明書。由于Diapers已經是正式運營的站點，客戶來自市場的壓力同時也轉嫁到項目團隊身上，項目發布的壓力一直困擾著團隊成員。從Diapers項目的進展來看，需求的迭代似乎就是無窮無盡的輪回。

　　主動觸發需求迭代，給予足夠的消化時間

　　導致Diapers項目的現狀的主要原因是被動的進行需求迭代，迭代被動的由客戶的反饋觸發。每次需求迭代都可能打亂團隊的開發計劃，影響項目的發布，給團隊帶來更大的發布壓力。因此，必須想方設法掌握需求迭代的主動權。

　　針對每次需求迭代給予充分的消化時間是一種有效的方式。從Diapers項目的情況來看，上一次需求還沒有消化處理完畢，新的需求迭代又要開始了。項目發布迭代的速度根本就跟不上需求迭代的速度，新的需求一直步步進逼。在這種情況下，測試工程師壓根兒就沒有時間對項目進行全面的足夠的測試。

　　找到問題的本質，Diapers項目團隊開始調整發布節奏，加大人力資源投入，加快消化需求的速度；針對溝通不足的問題，項目經理集中精力與客戶溝通，在雙方時間交叉的部分盡量把有疑問的需求溝通清楚；發布節奏調整后，客戶就有時間與項目團隊同步開展測試工作，bug也能夠在第一時間處理。調整后，項目團隊有足夠的時間來消化每次迭代的需求，也有足夠的時間對項目進行測試。

　　盡早發布原型系統是主動觸發需求迭代的另一種有效方式。原型系統通?？焖贅嫿?，著重在界面的呈現和功能的模擬，通過虛擬數據模擬真實系統的運行情況。其能夠在很大程度上模擬未來真實系統的呈現，在短時間內將抽象的客戶需求表現出來，作為和客戶進行溝通的有效媒介。相對于一堆抽象的文檔，使用原型系統，客戶更容易盡早發現真實系統與他們的需求之間的差距，減少未來需求迭代的次數。

　　因此，在需求抽象過程中，應該通過原型系統作為雙方溝通的橋梁和媒介，雙方應該先就原型系統的呈現展開討論。另外，原型系統的發布時間也是比較重要的，在項目啟動后應該盡早發布原型系統。

　　Claim項目則是一個商業意外險理賠平臺，為北美客戶提供商業意外險的在線申報、理賠服務。在項目啟動的初期，項目團隊在理解抽象需求的基礎上，第一時間發布了原型系統，使用虛擬數據模擬真實系統的界面呈現。這個項目比較有利的是，客戶自己聘請了需求分析人員，能夠最大程度的理解業務需求，正確的表述客戶的需求，并繪制詳細的原型界面；這點在雙方的溝通和系統開發過程中發揮了比較顯著的作用。由于Claim項目的需求迭代節奏一直在項目團隊的可接受范圍，所以項目一直有條不紊的推進，雖然需求也經過了多次迭代，但終歸還在可控的范圍內。

　　評估每一次迭代的成本和風險

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

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

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

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

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

　　明確項目發布的需求邊界

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

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

　　工欲善其事，必先利其器。我們可以利用一些現成的工具來管理需求邊界和跟蹤Bug，比如JIRA。JIRA是集項目計劃、任務分配、需求管理、錯誤跟蹤于一體的商業軟件，其提供了問題跟蹤管理、問題跟進情況的分析報告、項目類別管理、組件/模塊負責人、項目email地址等功能。許多著名的開源項目都采用了JIRA。

　　通過JIRA，可以整合客戶、項目經理、開發人員、測試人員，使各種角色各司其職，團隊內部信息能夠很快得到交流和反饋，潛在的問題提前暴露，促進項目的可控。

　　JIRA以工作流的思想融合了項目管理、任務管理和缺陷管理等思維，允許設定項目的模塊和版本，并為每個需求設置預期日期，將任務的處理指定到人。

　　JIRA允許為每個項目設置優先級，比如Blocker、Critical、Major、Minor、Trivial，標識每個任務的重要程度。

　　如果任務定義了優先級，那么在每個人的桌面上，任務會自動排列。這點對于多任務的項目尤其重要。

　　預見到需求迭代的被動性后，Diapers項目團隊在Diapers項目上全面啟動了JIRA進行項目管理，將需求分解細化后進入JIRA，排定任務的優先級并指定到人，確定每次小版本發布的需求編號，不定期的發布小版本。結合SVN等版本控制工具，Diapers項目團隊能夠將功能需求迭代的粒度控制到最小，項目逐步推進，客戶對項目的進度有充分的了解，項目經理也能夠準確把握項目的進度，團隊中充滿了樂觀的情緒。

　　安撫團隊成員的情緒

　　工程師對于冗長的需求說明書有天生的恐懼感，開發周期拉得太長，似乎需求迭代無窮無盡。如果需求的迭代周期不在可控范圍之內，項目的發布邊界模糊不清，項目發布的日期自然也遙遙無期。由此帶來的結果是團隊每天緊趕慢趕的跟蹤需求迭代，消化處理新的需求，工作氣氛也是高度緊張。每一次需求迭代，都會進一步增加這種緊張情緒。

　　項目經理應該把握項目的進展情況以及客戶的真實需求，也要知悉客戶的需求底線，更要在必要的時候安撫團隊成員的情緒。

　　當原始需求第一次被抽象出來的時候，團隊的第一要務是快速構建原型系統作為和客戶溝通的主要媒介和依據，項目經理應該引導團隊把握這一點。

　　之后的每一次需求迭代，項目經理要將需求分解細化，控制需求的粒度，并且確定優先級，消除團隊成員的焦急情緒，按照先后順序逐步的處理每一個粒度的需求，以發布每階段的小版本為階段性的目標。

　　在這個過程中，需求細化到最小粒度，還需要注意到每個需求之間的關聯關系，關聯的需求要優先集中處理，是降低每個小版本之間的耦合度。

　　Diapers項目自從將需求細化成一個個任務并進入JIRA控制之后，軟件工程師每天的只需要按照順序處理JIRA上面的任務，并及時將代碼以最小粒度的形式通過SVN工具提交；測試人員根據發布邊界所指定的版本號從SVN下載最新代碼測試，確認并關閉相應的任務；項目經理引導團隊成員遵循規范的需求迭代程序，有條不紊的處理需求，輕松應對需求迭代。

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