時(shí)間處理。調(diào)整后，項(xiàng)目團(tuán)隊(duì)有足夠的時(shí)間來消化每次迭代的需求，也有足夠的時(shí)間對(duì)項(xiàng)目進(jìn)行測(cè)試。
盡早發(fā)布原型系統(tǒng)是主動(dòng)觸發(fā)需求迭代的另一種有效方式。原型系統(tǒng)通?？焖贅?gòu)建，著重在界面的呈現(xiàn)和功能的模擬，通過虛擬數(shù)據(jù)模擬真實(shí)系統(tǒng)的運(yùn)行情況。其能夠在很大程度上模擬未來真實(shí)系統(tǒng)的呈現(xiàn)，在短時(shí)間內(nèi)將抽象的客戶需求表現(xiàn)出來，作為和客戶進(jìn)行溝通的有效媒介。相對(duì)于一堆抽象的文檔，使用原型系統(tǒng)，客戶更容易盡早發(fā)現(xiàn)真實(shí)系統(tǒng)與他們的需求之間的差距，減少未來需求迭代的次數(shù)。
因此，在需求抽象過程中，應(yīng)該通過原型系統(tǒng)作為雙方溝通的橋梁和媒介，雙方應(yīng)該先就原型系統(tǒng)的呈現(xiàn)展開討論。另外，原型系統(tǒng)的發(fā)布時(shí)間也是比較重要的，在項(xiàng)目啟動(dòng)后應(yīng)該盡早發(fā)布原型系統(tǒng)。
Claim項(xiàng)目則是一個(gè)商業(yè)意外險(xiǎn)理賠平臺(tái)，為北美客戶提供商業(yè)意外險(xiǎn)的在線申報(bào)、理賠服務(wù)。在項(xiàng)目啟動(dòng)的初期，項(xiàng)目團(tuán)隊(duì)在理解抽象需求的基礎(chǔ)上，第一時(shí)間發(fā)布了原型系統(tǒng)，使用虛擬數(shù)據(jù)模擬真實(shí)系統(tǒng)的界面呈現(xiàn)。這個(gè)項(xiàng)目比較有利的是，客戶自己聘請(qǐng)了需求分析人員，能夠最大程度的理解業(yè)務(wù)需求，正確的表述客戶的需求，并繪制詳細(xì)的原型界面；這點(diǎn)在雙方的溝通和系統(tǒng)開發(fā)過程中發(fā)揮了比較顯著的作用。由于Claim項(xiàng)目的需求迭代節(jié)奏一直在項(xiàng)目團(tuán)隊(duì)的可接受范圍，所以項(xiàng)目一直有條不紊的推進(jìn)，雖然需求也經(jīng)過了多次迭代，但終歸還在可控的范圍內(nèi)。
3、評(píng)估每一次迭代的成本和風(fēng)險(xiǎn)
能夠預(yù)見到的是，需求的每次迭代都會(huì)不同程度的對(duì)項(xiàng)目產(chǎn)生影響，對(duì)此需要評(píng)估由此所帶來的成本。不只是項(xiàng)目經(jīng)理和需求分析工程師，軟件工程師和測(cè)試工程師也應(yīng)該參與這個(gè)過程，評(píng)估此次迭代是否會(huì)影響現(xiàn)有的技術(shù)架構(gòu)，哪些功能點(diǎn)可能受到影響，哪些系統(tǒng)模塊需要修改，測(cè)試用例是否應(yīng)該重新編寫，團(tuán)隊(duì)需要為此次迭代額外付出多少時(shí)間成本，是否會(huì)造成項(xiàng)目的延期等等。
評(píng)估之后，如果需求迭代對(duì)項(xiàng)目的進(jìn)度可能造成比較明顯的影響，項(xiàng)目經(jīng)理應(yīng)該和客戶有效溝通，告知需求迭代的成本，尤其是時(shí)間成本。
另外，需求的每次迭代也必然給項(xiàng)目帶來一定的風(fēng)險(xiǎn)，包括技術(shù)風(fēng)險(xiǎn)和發(fā)布風(fēng)險(xiǎn)。迭代后的需求可能影響原有的技術(shù)方案，尤其是核心業(yè)務(wù)邏輯的變更。團(tuán)隊(duì)要重新對(duì)技術(shù)方案進(jìn)行梳理，檢查該技術(shù)方案是否仍然可以達(dá)到既定的目的。需求迭代之后，軟件工程師需要一定的時(shí)間調(diào)整開發(fā)進(jìn)度，測(cè)試工程師也需要根據(jù)新的需求對(duì)系統(tǒng)重新測(cè)試，這必然影響項(xiàng)目的發(fā)布周期；作為項(xiàng)目經(jīng)理，應(yīng)該預(yù)見到這一點(diǎn)。
GS項(xiàng)目是某公司重點(diǎn)研發(fā)的一個(gè)以政府機(jī)關(guān)行政審批業(yè)務(wù)為服務(wù)目標(biāo)的產(chǎn)品，在其進(jìn)行產(chǎn)品升級(jí)改造的同時(shí)，其競(jìng)爭(zhēng)對(duì)手也在著手準(zhǔn)備同類產(chǎn)品的新版本發(fā)布，市場(chǎng)的壓力要求產(chǎn)品盡快完成版本的升級(jí)。但是在新產(chǎn)品即將進(jìn)入集成測(cè)試階段的時(shí)候，公司突然決定對(duì)產(chǎn)品的界面進(jìn)行比較重大的調(diào)整。這一次調(diào)整導(dǎo)致代碼和測(cè)試的返工，使該產(chǎn)品的發(fā)布時(shí)間推遲了兩個(gè)月，錯(cuò)過了銷售的黃金期，市場(chǎng)和客戶對(duì)于新產(chǎn)品的期待已經(jīng)逐漸降低，結(jié)果產(chǎn)品的銷售量遠(yuǎn)遠(yuǎn)不如預(yù)期。如果公司之前對(duì)界面需求迭代有比較清晰的成本和風(fēng)險(xiǎn)評(píng)估，那么應(yīng)該不會(huì)這么倉促的觸發(fā)迭代。
Diapers項(xiàng)目團(tuán)隊(duì)意識(shí)到Diapers項(xiàng)目的需求迭代的周期是比較短的，因此對(duì)于每次迭代的需求，軟件工程師和測(cè)試工程師都會(huì)協(xié)同項(xiàng)目經(jīng)理進(jìn)行評(píng)估，判斷消化所有需求并測(cè)試所需要投入的工作量，以及由此所可能帶來的時(shí)間成本和技術(shù)風(fēng)險(xiǎn)，團(tuán)隊(duì)成員已經(jīng)徹底擺脫了害怕需求迭代的心態(tài)。
4、明確項(xiàng)目發(fā)布的需求邊界
軟件不是十全十美的，需求的迭代是永無止境的。需求的迭代周期是不定的，與其在最終版本中包括所有的需求，不妨在這