选择迭代长度时考虑的因素

大部分敏捷开发过程和采用敏捷开发过程的小组都把迭代长度设置为2~4周。有些小组使用更长一些的迭代，但是2~4周是大多数开发小组普遍接受的标准。并不存在一个神奇的迭代长度，可以适用于任何环境中的所有小组。小组在开发一个项目时的合适迭代长度在同一个小组开发另一个项目时也许并不合适。

 

您在选择迭代长度的时候，应该受下列因素的指引：

•     正在处理的发布的时间长度

•     不确定性的多少

•     获得反馈的难以程度

•     优先级可以保持多久不变

•     不用外部反馈自行工作的意愿的强弱

•     迭代的系统开销

•     紧迫感的产生有多快

 

这些因素之间不存在预先定义的相对重要性。每一个因素的重要性完全取决于项目的相关背景。

 

发布的总时间长度

短时间的项目从短迭代中受益。项目迭代的长度决定了：

• 能够多频繁地向客户和用户展示软件（以潜在可以交付的形式）。确实，当然也可以把软件在迭代中期的形式展示给这些观众，但是软件通常只有到了迭代结束的时候才具有潜在可以交付的质量。

• 能够多频繁地度量开发进度。在一次迭代进行中，也可能获得对小组进度率的感觉，但是只有在迭代结束的时候我们才能真正地度量到底完成得了多少工作。

• 产品所有者和开发小组能够多频繁地修正自己的路线。因为只有在迭代之间才会对优先级和计划进行调整。

假设开发小组正工作于一次3个月以后就要进行的发布中，如果采用1个月的迭代长度，他们用来收集迭代结束时的反馈、度量进度和调整开发路线的机会就只有2次。大多数情况下，这个次数都是不够的。

我的一般经验方法是任何项目都至少需要4~5次这样的机会才能从中受益。这意味着如果项目的总时间是4个月以上，也许就可以考虑按月迭代，或者是采用4周的迭代长度。但是，如果总发布时间短于这个时间，项目就需要相应更短的迭代。

 

不确定性的多少

不确定性会以多种形式出现。在客户或用户到底想要什么、小组的速度会是多少等方面，以及项目的技术方面都常常会存在不确定性。不确定性越多，无论是哪种类型的，迭代就应该越短。当要完成的工作或要构建的产品方面存在大量不确定性的时候，短迭代可以为开发小组提供更频繁的机会来根据速度度量自己的进度，也提供了更多的机会来收集项目利益相关者、客户和用户的反馈。

 

获得反馈的难易程度

选择迭代长度时应该让给整个小组获得反馈的数量、频度和及时性都最大化。依赖于所处环境的不同，这可能意味着较长的迭代，也可能是较短的迭代。在某些公司中，很容易在迭代过程中获得内部的利益相关者和客户的反馈，但是要让同样的这些人参与预先安排的迭代结束时的回顾会议却非常困难。其他一些公司的情况可能恰好相反：平时很难获得反馈，但是利益相关者、用户和其他人都愿意参加预先安排的、正式的回顾会议（尤其是提供了食物的时候）。

选择迭代长度，让来自于公司内外的反馈所具有的价值最大化。

 

优先级可以保持多久不变

一旦开发小组承诺在一次迭代中完成一组特定的功能，重要的是不要改变他们的目标方向。因此，产品所有者不在迭代过程中改变优先级，并帮助小组免受其他试图改变优先级的人的影响就很重要。所以，优先级不会被改变的时间长度是选择迭代长度时需要考虑的因素。

关键的一个考虑是需要多长时间才能把一个好想法转变成可用的软件。考虑下面这种情况。开发小组采用4周的迭代长度。如果我们假设新想法在迭代过程中任何时间出现的可能性都一样，就可以说在迭代的正中间出现了一个新想法。这个新想法会被优先分配到2周以后开始的下一次迭代。还要再花4周（一次完整的迭代），这个新想法才会以潜在可交付的、可用的软件形式出现。

 

不用外部反馈自行工作的意愿

即使是一个善意的、很易于沟通的小组，在一次迭代结束的时候，也有可能在把迭代的结果展示给公司中更广泛的人员和外部用户时，发现它毫无价值。发生这种情况的原因可能是由于开发人员错误理解了产品所有者的意思（而且在迭代过程中交流得也不够频繁），也可能是由于产品所有者错误理解了市场或用户的需要。只要我们从中学到一些东西，也就不完全是损失。不过，小组接受外部反馈的频度越低，就越可能误入歧途，造成的损失也就会越大。

 

迭代的系统开销

每次迭代都有成本。例如，对每次迭代都必须进行完整的回归测试。如果它的成本很高（主要是指时间上），小组可能会倾向于长一些的、4周一次的迭代。很自然的，成功的敏捷开发小组的目标之一就是减少（或者近似消除）与每次迭代联系在一起的系统开销。但是尤其在小组的早期几次迭代中，这一成本非常显著，而且会影响到对最佳迭代长度的决策。

 

紧迫感的产生有多快

我的同行NielsMalotaux指出“只要项目的结束日期还在遥远的将来，我们就不会感到任何压力，并从容不迫地工作。当结束日期的压力变得切实可见的时候，我们才会开始更努力地工作。”即使是使用4周的迭代长度，结束日期也从来不会是在遥远的将来。但是他已经足够远了，很多小组可以明显地感觉到他们在第一周的压力没有在第四周，也就是迭代的最后的压力大。

要解决这个问题，当然就是选择一个迭代长度，让小组感受到的压力更平均。重点并不是给小组更多的压力（“今天你们就要交付！”），而是把他们正常感受到的压力的总量更为均匀地分布到一个适当长度的迭代中。

欢迎订阅【ShineScrum】，扫描下方二维码，即可参与敏捷互动。