成員的情緒。
工程師對于冗長的需求說明書有天生的恐懼感，開發(fā)周期拉得太長，似乎需求迭代無窮無盡。如果需求的迭代周期不在可控范圍之內(nèi)，項目的發(fā)布邊界模糊不清，項目發(fā)布的日期自然也遙遙無期。由此帶來的結(jié)果是團隊每天緊趕慢趕的跟蹤需求迭代，消化處理新的需求，工作氣氛也是高度緊張。每一次需求迭代，都會進一步增加這種緊張情緒。
當(dāng)原始需求第一次被抽象出來的時候，團隊的第一要務(wù)是快速構(gòu)建原型系統(tǒng)作為和客戶溝通的主要媒介和依據(jù)，項目經(jīng)理應(yīng)該引導(dǎo)團隊把握這一點。
之后的每一次需求迭代，項目經(jīng)理要將需求分解細(xì)化，控制需求的粒度，并且確定優(yōu)先級，消除團隊成員的焦急情緒，按照先后順序逐步的處理每一個粒度的需求，以發(fā)布每階段的小版本為階段性的目標(biāo)。在這個過程中，需求細(xì)化到最小粒度，還需要注意到每個需求之間的關(guān)聯(lián)關(guān)系，關(guān)聯(lián)的需求要優(yōu)先集中處理，是降低每個小版本之間的耦合度。
Diapers項目自從將需求細(xì)化成一個個任務(wù)并進入JIRA控制之后，軟件工程師每天的只需要按照順序處理JIRA上面的任務(wù)，并及時將代碼以最小粒度的形式通過SVN工具提交；測試人員根據(jù)發(fā)布邊界所指定的版本號從SVN下載最新代碼測試，確認(rèn)并關(guān)閉相應(yīng)的任務(wù)；項目經(jīng)理引導(dǎo)團隊成員遵循規(guī)范的需求迭代程序，有條不紊的處理需求，輕松應(yīng)對需求迭代。
5、明確項目發(fā)布的需求邊界
軟件不是十全十美的，需求的迭代是永無止境的。需求的迭代周期是不定的，與其在最終版本中包括所有的需求，不妨在這期間發(fā)布若干個小版本，明確每個小版本的需求邊界。這好比長跑途中的若干個里程碑，每跨過一個里程碑就意味著向重點又前進了一步。
每個小版本都包含有限的功能需求，測試工程師可以針對這些功能需求同步展開測試工作，提早觸發(fā)Bug，盡量爭取測試時間?？蛻粢部梢詮倪@些小版本中提前看到真實系統(tǒng)的雛形；隨著版本的逐步升級，項目距離發(fā)布日期也越來越近，和需求的差距也越來越小。
工欲善其事，必先利其器。我們可以利用一些現(xiàn)成的工具來管理需求邊界和跟蹤Bug，比如JIRA。JIRA是集項目計劃、任務(wù)分配、需求管理、錯誤跟蹤于一體的商業(yè)軟件，其提供了問題跟蹤管理、問題跟進情況的分析報告、項目類別管理、組件/模塊負(fù)責(zé)人、項目email地址等功能。許多著名的開源項目都采用了JIRA。
通過JIRA，可以整合客戶、項目經(jīng)理、開發(fā)人員、測試人員，使各種角色各司其職，團隊內(nèi)部信息能夠很快得到交流和反饋，潛在的問題提前暴露，促進項目的可控。
JIRA以工作流的思想融合了項目管理、任務(wù)管理和缺陷管理等思維，允許設(shè)定項目的模塊和版本，并為每個需求設(shè)置預(yù)期日期，將任務(wù)的處理指定到人。 JIRA允許為每個項目設(shè)置優(yōu)先級，比如Blocker、Critical、Major、Minor、Trivial，標(biāo)識每個任務(wù)的重要程度。如果任務(wù)定義了優(yōu)先級，那么在每個人的桌面上，任務(wù)會自動排列。這點對于多任務(wù)的項目尤其重要。
結(jié)合SVN等版本控制工具，Diapers項目團隊能夠?qū)⒐δ苄枨蟮牧６瓤刂频阶钚?，項目逐步推進，客戶對項目的進度有充分的了解，項目經(jīng)理也能夠準(zhǔn)確把握項目的進度，團隊中充滿了樂觀的情緒。預(yù)見到需求迭代的被動性后，Diapers項目團隊在Diapers項目上全面啟動了JIRA進行項目管理，將需求分解細(xì)化后進入JIRA，排定任務(wù)的優(yōu)先級并指定到人，確定每次小版本發(fā)布的需求編號，不定期的發(fā)布小版本。