，盡管這些變更可能會給項目計劃和項目進度帶來麻煩，但這種觀念上的轉變更能體現(xiàn)開發(fā)團隊和客戶之間合作的誠意。
客戶在迭代周期中的變更大致可以分為五種類型：添加新需求、刪除本次迭代周期內(nèi)的需求、刪除之前迭代周期內(nèi)的需求、更改本次迭代周期內(nèi)的需求、更改之前迭代周期內(nèi)的需求。這就是說，開發(fā)團隊需要實時高效地管理這些變更，并且將需求變更涉及到的迭代周期內(nèi)項目計劃和人員安排變更的影響最小化。
3、需求、測試用例、Bug管理脫節(jié)
我們希望在需求、測試用例和Bug之間建立一種動態(tài)的聯(lián)系，能夠實時地更新三者的狀態(tài)，并且實現(xiàn)三者之間狀態(tài)的動態(tài)聯(lián)動，從而減少開發(fā)團隊在管理和維護需求、測試用例和Bug時的工作量。
軟件開發(fā)中，需求和測試用例是緊密聯(lián)系的，通常來說，一條需求只有通過了所有針對該需求的測試之后才能說這條需求的實現(xiàn)真正實現(xiàn)了。需求的變更直接影響到與該需求相關的測試用例的更新，繼而影響到現(xiàn)有Bug的狀態(tài)的更新。然而現(xiàn)實情況卻是，大多數(shù)敏捷開發(fā)團隊都沒有實現(xiàn)需求、測試用例和Bug的一體化管理。測試的結果是產(chǎn)生Bug報告，如果針對某條需求的一個測試用例沒有通過測試，換句話說，也就是產(chǎn)生了一個Bug，這就說明該需求根本沒有完成。
4、缺乏有針對性的需求管理流程
為了彌補需求變更對項目進程帶來的影響，開發(fā)人員常常需要快速的進行功能修改和增加，而沒有遵循統(tǒng)一的流程控制，從而常常使得軟件開發(fā)的有序性被破壞，人為地增加了工作量。這就需要有更為高效和精簡的需求管理過程以及相應的工具支持。傳統(tǒng)的需求管理過程，尤其是其中的變更控制過程是針對那些組織機構清晰，只能定義明確的傳統(tǒng)軟件項目，其流程相對比較嚴謹和死板。