迭代的時間長度通常為2～6周，越短越好，尤其是在項目的早期階段。經常有人問及迭代的長度是否可以有所不同這個問題。根據我的經驗，在整個項目中採用固定長度的迭代最好。我見到過這樣的項目：項目經理以兩個4周迭代作為開始，而後把節拍切換成2周。有許多很好的原因支持這種做法。其中一個原因是可以減少新敏捷團隊2週一次迭代的壓力。一旦團隊對迭代-增量開發更為熟悉，那麼縮短迭代的週期就會更為有益。但我們不推薦按照所計劃的故事的密度來變更迭代長度（比如：2、3、4、2，然後5周），這樣做也是沒有必要的。有很多偉大的書可幫助你將需求（故事、用例和非功能性需求）指派成迭代，而不是相反而行。在索引卡片上記錄成文檔的故事對敏捷開發人員來說很常見，它們是制定迭代計劃時所用的技巧。
如果敏捷項目使用用例而不是故事，迭代計劃的制定過程還是相似的。用例表示一組從頭到尾的業務場景。場景中有一些較為常見、較為典型，其他的場景可能是待選的或例外的案例，很少執行到。用例的挑戰在於，有些用例又長又複雜，而另外一些則較為簡單。另外，用例之間存在依賴關係。如果仔細研究用例，不難注意到它們通常由許多冗餘的場景組成。所以，團隊必須把焦點放在各個場景之上而不是直接解決整個用例。通過使用這種方法，即使是場景之間的依賴關係也可以得到解決。以這種格式來標識場景並編寫這些場景的文檔，自然就與業務分析師通常執行的工作一致。這是使用用例來編寫需求文檔的正面。
雖然大致輪廓和高優先級的需求是由顧客來定的，但項目經理要和團隊其他成員一起推動迭代計劃的制定。於是，按照顧客的願望列表，需求之間的依賴關係就可以得到考慮，適合於即將到來的迭代的最好的可能計劃就可以得到組裝。
分享到:
閱讀更多 人人都是項目經理 的文章
