敏捷开发之稳定迭代周期

http://www.blogjava.net/josson/archive/2011/01/31/341341.html

**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次或以上)获取反馈、修正的机会，根据项目周期调整迭代周期长度。

  1. 、不确定性的多少

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

  1. 、获得反馈的难易程度

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

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

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

  1. 、迭代的系统开销

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

  1. 、团队成员的紧迫感

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

每个团队根据所在环境和条件确定一个合适的迭代长度，一般建议2~4周。在我们的实践中，以2周一次迭代的频率，保持相对稳定的开发和交付的节奏。