理想的迭代长度

在敏捷实施中常常碰到这样的问题：理想的迭代长度应该是多少？有的团队可能选择一周，也有的可能选择两个月。选择恰当的迭代长度干系着敏捷实施的成败。几位敏捷学家分享了他们认为在决定迭代长度时应当考虑的一些因素。

Clinton Keith 认为，刚刚接触敏捷的团队需要选择短迭代，因为这可以帮助他们更快的学习成长。他说：

刚接触敏捷的团队常常想把迭代定的越长越好。我对这个很不感冒。因为他们总是把迭代做的像迷你瀑布项目一样。他们花几天时间做设计，几周编码，然后集成，在迭代末了的时候测试优化。有经验的团队会把这些工作每天都做一点，这样才更有成效。

Clinton 的看法是，在决定迭代长度的时候，需要考虑下面这些因素：

• 客户反馈——客户最短能在多长时间内给项目进展提供反馈
• 团队经验——如果团队在敏捷方面经验不多，那迭代就该尽可能的短，帮助团队快速学习。
• 回顾和计划的支出——一般回顾和计划要花一天时间，这个时间要考虑进去。
• 给迭代做计划的能力——如果迭代目标中不确定因素太多，那时间就该短一些。
• 平衡工作强度——迭代中应该有稳定的工作强度。

Vikrama Dhiman 的观点有些相似。他同时还提出，迭代长度也要依赖于产品负责人把功能拆分成小规模用户故事的能力。小的故事就更容易在短迭代中完工、测试。他还列举出了短迭代的一些优点：

• 短迭代可以干掉坏习惯，培养出好习惯。
• 短迭代对于产品管理组很困难，但他们可以更快做出变化，所以还是很值得考虑。
• 短迭代可以强制人们定期做快速评估。
• 短迭代可以让团队很快在实践中得到自己的生产率。

Mike Cohn 则给出了这些考虑因素：

• 有多少不确定性因素——不确定性越高，迭代长度就该越短，这样才能应对那些不确定的问题。
• 优先级能够在多长时间内保持不变——如果在一个迭代中，故事优先级都会变来变去，那就表示迭代长度应该缩短。
• 迭代的管理支出——如果每个迭代末尾都要做一系列的“手工”回归，那短迭代的成本就更高。
• 多长时间会产生紧迫感——如果迭代时间太长，团队就容易在迭代初期信心满满，到了后期又会赶工。所以在选择迭代长度的时候，一定要保证团队可以以稳定的步伐前进。

Mike 说，按照他的个人经验来看，两星期的迭代长度最合适。这样一来，计划和测试的成本在可控范围内，团队又能进入稳定的开发节奏。他以下面的建议作为文章结尾：

一旦得出了合适的迭代长度，就要坚持住。项目开发有了节奏，团队就会获益匪浅。任何正常的迭代长度都可以带来这种节奏。这不是说你不能去尝试其他长度，只是不要在没有很好理由的情况下就随便换来换去的。

查看英文原文： Ideal Iteration Length