（PS：案例部分，節選自公衆號Agile2046)
很多敏捷團隊一開始不知道迭代週期設定多長合適。一般來說，迭代週期在1周到1個月以內的週期，而且一旦選定，迭代的長度在整個開發過程中保持一致。新的迭代週期在上一個迭代完成之後立即開始。那麼到底多長合適呢？
初始設定方法
-
首先，應該選擇以周爲單位，即：1周，2周，3周，4周，而不是以天爲單位，e.g. 7天，12天，22天等。道理很簡單，以周爲單位方便管理和溝通。以天爲單位，大家還得打開日曆數天數。這種事務性管理的成本越低越好。
-
其次，對於每個獨立交付產品的團隊，自己定義迭代的長度，不要整個公司或部門一刀切；對於一個項目有多個團隊協同交付產品的情況，大家保持一個Sprint長度，方便跨團隊計劃和交付節奏對齊。此外，這樣的大項目交付的情況裏，每個團隊有共同的語言，不至於你說的迭代1是我團隊的迭代2。
-
再次，選擇兩週長度的迭代啓動，進行了1個迭代後, 團隊在回顧中討論，迭代長度是否合理，是否需要短一些，或者長一些。現在大部分團隊的迭代長度都是兩週。爲什麼要選定兩週的長度開始呢？下表列出了不同長度的d可達的對比：
Sprint不同長度的對比
從上圖可以看出，不同的迭代長度，沒有絕對的好或壞。兩週可達的長度，各個維度處於居中的程度，因此，不必太過於糾結，可以從兩週的長度開始，當團隊發現一些問題的時候再調整。對於大部分團隊，一個迭代運轉後，沒有發現需要調整過。
調整迭代實操方：（以案例爲主線進行分析）
案例1
某公司剛開展敏捷轉型的時候，給每個團隊一刀切定爲兩週。很快在一些團隊遇到問題。
一個做互聯網產品的團隊，每次迭代進行到中間的時候，經常出現更加緊急業務需求，而把原來規劃的需求擠掉。團隊跟產品負責人溝通，拒絕迭代中間調整需求，導致團隊與產品負責人關係變得緊張。
這個時候，團隊應該與產品負責人分析，這種情況發生的原因是什麼。是由於產品負責人的工作沒有做好，在迭代啓動前沒有準備好需求，到了迭代執行期間才臨時發現需求？還是因爲業務變化頻繁，兩週的迭代偏長，產品負責人無法提前兩週預見需求？如果是業務變化確實比迭代頻繁，可以考慮縮短迭代週期。但是，要確定這種頻繁的業務變化是常態。如果只是臨時出現的情況，不需要調整迭代的長度。
另一個做To B移動端App的團隊也發現了問題。他們的移動端發佈週期是三週一次，導致他們的迭代週期與發佈週期錯位。每次迭代結束的時候，產品不具備條件發佈；而發佈的時候，正式下一個迭代的中期。團隊與產品負責人商議，是否需要讓發佈週期更頻繁，而產品負責人認爲，對於他們的客戶，三週的發佈週期完全滿足客戶的期望，過於頻繁反而增加客戶的更新成本。因此，團隊決定，調整迭代的週期爲三週，迭代的結束的時候正式發佈的時候。
此外，迭代的長度也取決於團隊的工程能力基礎。對於那些沒有任何自動化集成、自動化測試、自動化部署的“三無”團隊，從瀑布轉爲兩週的迭代週期，往往會發現迭代時間結束的時候，產品不具備可交付狀態，測試人員加班到後半夜吐血。在這樣的情況下，迭代週期是否需要調整呢？
有兩個選擇：
-
延長迭代週期至3周-4周的長度，在每個迭代計劃的時候，將工程能力提升任務納入Backlog, 確保每個迭代在交付特性的同時也對工程能力有投資。但是要記住，過了一段時間在工程能力有所提升之後，團隊再次回顧迭代週期是否可以縮短。
-
迭代週期不變，調整DoD(完成的定義)，修改爲在目前的迭代週期長度下，產品可以達到的程度。要小心的是，採取這個選擇必然造成下個迭代在補上個迭代遺留的功課。因此，這是一種妥協。
案例2：
某大型SaaS互聯網軟件產品由多個團隊協作交付。在兩週的迭代週期內，整個產品只能完成特性驗證和基本回歸驗證，如果做全面的迴歸驗證需要再花一週的時間。團隊決定修改DoD完成的定義爲:
a. 特性驗證通過
b.系統級基本回歸驗證通過。
但是達到了這個DoD條件還不能發版。團隊將系統級全迴歸驗證放到了下一個迭代，在驗證通過後發版，因此發版週期錯後迭代一週時間。團隊將如何縮短驗證週期作爲改進專項規劃。需要注意的是，很多時候，貌似看起來測試周期長是測試的問題，究其根本原因是架構和代碼的問題。團隊每個迭代做一部分改進工作，直至一個迭代內可以達到發版條件。
由此可見，不管如何抉擇，比迭代週期的初始設定更重要的，是團隊在遇見問題後思考如何改進，並切實將改進任務納入到每個迭代中去實施，逐步提升敏捷成熟度，達到迭代結束時產品具備可交付的狀態。
不是一定要迭代到永遠
迭代不是永遠要有的。隨着團隊的敏捷成熟度的提升，當團隊能夠每天按需發佈，甚至每天可以多次發佈，即達到流式開發、持續交付的程度，那時候就可以拋棄迭代週期的約束，而迭代週期只作爲團隊計劃的節奏，不再作爲交付的節奏。
迭代週期常常是在敏捷項目已經進行了一段時間之後，纔會固定下來。這是一個探索的過程。
當你感到迭代週期太短，在一個迭代週期內根本無法完成計劃好的任務，那可能是由於對項目團隊的開發速度估計有誤，而迭代週期內的任務量又太大所造成的。
當一個迭代結束後，給用戶演示的時候，發現軟件功能已經背離了用戶的需求，那可能是因爲迭代週期太長，沒能及時地得到用戶的反饋。
所以，當項目進行了幾個迭代之後，項目團隊才能把握自己開發的速度，設計出適合項目的迭代週期。
總之，迭代週期的長短，不應該是一個固定的值，它應該根據實際需要而定。確定這個週期，不要遺忘了時間盒的作用：控制開發節奏，並且及時獲得反饋。只要能夠實現這個目標，迭代週期是長還是短也就不是那麼重要了。
最後歡迎各位來體驗和試用一下 ONES，一款非常好用的迭代管理工具，可以幫助題主做更精確地項目進度管理，管理需求和相關任務規劃至迭代。
