什么是iteration和release？

iteration和release是两个不同的概念，但在敏捷实践活动中，我们往往认识得比较模糊，一个iteration就是一次release，其实不然。那么，具体有什么区别和联系呢？

iteration（迭代）：在固定的周期内，经过需求分析、设计、实现、测试等活动，完成计划的业务需求，迭代结束提供一个可工作的产品。计划的业务需求，可能是一个完整的User Story，也可能是一个Story中的若干task。

release（发布）：经过一个或若干个iteration后，完成计划中的所有User Story，经过测试后才release，最终真正交付给客户使用。

在我们实践活动中，一个User Story所需的工作量超过我们的有效资源，无法安排在一个iteration内。我们就会想当然地会去延长迭代周期，增加有效资源以适应所需工作量。殊不知，这更像是形式上的迭代开发，无异于瀑布式项目开发过程。

建立固定的迭代周期，保持稳定的开发节奏

Scurm方法非常强调稳定的迭代节奏，一个稳定的迭代节奏就如同项目的的心跳。Simon Baker描述说：“就像心脏有规律地跳动来保持身体运行，固定的迭代长度提供了一个恒量，有助于建立开发和交付的节奏。根据我的经验，节奏是帮助取得不变的步幅的重要因素。”对于敏捷开发的团队而言，稳定的迭代节奏可以让产品保持更稳定的交付。

如何保持稳定的开发节奏？

当一个迭代期内可提供的有效资源无法实现一个User Story时，我们如何安排呢？

通常情况下，我们尽力保证迭代周期的稳定。核心就是固定Timebox和可提供的资源，让产品经理来决定需求的优先级，每迭代只接纳（ 开发/QA资源 ）可承受的需求。

如何选择适合自己团队的迭代周期？

一般需要考虑以下因素：

1、整个项目周期长度（完成计划的商业需求所需时间）

较短的迭代周期将会有以下一些好处：更频繁的向客户展示/交付可用的软件；更频繁的度量开发进度；更频繁的取得反馈并改进；一般大的项目最好有多次（3次或以上）获取反馈、修正的机会，根据项目周期调整迭代周期长度。

2、不确定性的多少

不确定性有多种形式，客户到底想要的是什么？小组的工作效率，时间？技术门槛等都不存在不确定性，不确定性越多，迭代就应该越短。

3、获得反馈的难易程度

指小组获取反馈数量、频度和及时性，视所处的环境不同，选择合适的迭代长度。

4、优先级要以多久保持不变

开发小组承诺在一次迭代中完成一组特定的功能，重要的是不要改变他们的目标方向，优先级、不会被改变的时间是选择迭代长度时需要考虑的。

5、迭代的系统开销

每次迭代的成本（时间），如迭代中进行的完整回归测试。最佳迭代周期的目标之一就是减少或近似消除每次迭代的系统开销。如每次回归时间成本很高，那决定周期长度时更倾向于长一些。

6、团队成员的紧迫感

Niels Malotaux指出：“只要项目的结束日期还在遥远的将来，我们就不会感到任何压力，并从容不迫的工作。当结束日期逼近时，我们才会开始更努力的工作”。意思指项目开始大家比较放松，而越临近结束，工作越忙压力越大。因此，选择一个合适的迭代周期长度，让团队成员在整个迭代过程中感受到的压力更平均，不是给团队更多的压力，而是压力总量平均分布在迭代过程中。

每个团队根据所在环境和条件确定一个合适的迭代长度，一般建议2~4周。在实践中，一般早期密集开发迭代较快（1周），中期功能补充迭代放缓（2周），后期维护更新迭代就固定稳定下来（3-4周）。

参考资料：《敏捷估计与规划》 Mike Cohn