1、什么是iteration和release？
iteration和release是兩個不同的概念，但在敏捷實踐活動中，我們往往認識的比較模糊，一個Iteration就是一次release，其實不然。那么，具體有什么區別和聯系呢？
Iteration（迭代）：在固定的周期內，經過需求分析、設計、實現、測試等活動，完成計劃的的業務需求，迭代結束提供一個可工作的產品。計劃的業務需求，可能是一個完整的User Story，也可能是一個Story中的若干task。
Release(發布)：經過一個或若干個iteration后，完成計劃中的所有User Story，經過測試后才release，最終真正交付給客戶使用。
在我們的實踐活動中，一個User Story所需的工作量超過我們的有效資源，無法安排在一個iteration內。我們就會想當然的會去延長迭代周期，增加有效資源以適應所需工作量。殊不知，這更象是形式上的迭代開發，無異于瀑布式項目開發過程。
2、建立固定的迭代周期，保持穩定的開發節奏
Scurm方法也非常強調穩定的迭代節奏，一個穩定的迭代節奏就如同項目的的心跳。Simon Baker描述說："就像心臟有規律地跳動來保持身體運行，固定的迭代長度提供了一個恒量，有助于建立開發和交付的節奏。根據我的經驗，節奏是幫助取得不變的步幅的重要因素"（2004）。對于敏捷開發的團隊而言，穩定的迭代節奏可以讓產品保持更穩定的交付。
3、如何保持穩定的開發節奏？
當一個迭代期內可提供的有效資源無法實現一個User Story時，我們如何按排呢？ 在 談迭代周期控制的困惑 中已談到，這里不在細述。
4、如何選擇適合自己團隊的迭代周期？
一般需要考慮以下因素：
1）、整個項目周期長度（完成計劃的商業需求所需時間）
較短的迭代周期將會有以下一些好處：更頻繁的向客戶展示/交付可用的軟件；更頻繁的度量開發進度；更頻繁的取得反饋并改進；一般大的項目最好有多次(3次或以上)獲取反饋、修正的機會，根據項目周期調整迭代周期長度。
2）、不確定性的多少
不確定性有多種形式，客戶到底想要的是什么？小組的工作效率，時間？技術門檻等都不存在不確定性，不確定性越多，迭代就應該越短。
3）、獲得反饋的難易程度
指小組獲取反饋數量、頻度和及時性，視所處的環境不同，選擇合適的迭代長度；
4）、優先級要以多久保持不變
開發小組承諾在一次迭代中完成一組特定的功能，重要的是不要改變他們的目標方向，優先級不會被改變的時間長度是選擇迭代長度時需要考慮的因素。
5）、迭代的系統開銷
每次迭代的成本（時間），如迭代中進行的完整回歸測試。最佳迭代周期的目標之一就是減少或近似消除每次迭代的系統開銷。如每次回歸時間成本很高，那決定周期長度時更傾向于長一些。
6）、團隊成員的緊迫感
Niels Malotaux指出："只要項目的結束日期還在遙遠的將來，我們就不會感到任何壓力，并從容不迫的工作。當結束日期逼近時，我們才會開始更努力的工作"。意思指項目開始大家比較放松，而越臨近結束，工作越忙壓力越大。因此，選擇一個合適的迭代周期長度，讓團隊成員在整個迭代過程中感受到的壓力更平均，不是給團隊更多的壓力，而是壓力總量平均分布在迭代過程中。
每個團隊根據所在環境和條件確定一個合適的迭代長度，一般建議2~4周。在我們的實踐中，以2周一次迭代的頻率，保持相對穩定的開發和交付的節奏。
5、參考資料:
《敏捷估計與規劃》 Mike Cohn
posted on 2011-01-31 14:26
josson 閱讀(3418)
評論(0) 編輯 收藏 所屬分類:
項目管理