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 阅读(3380)
评论(0) 编辑 收藏 所属分类:
项目管理