|
当使用Scrum敏捷方法时，软件开发周期由一个个迭代组成，那么每个迭代的长度如何设置才合理呢？ 首先，设置一个迭代的长度要满足以下原则： 最长不超过30天。因为一旦迭代的长度超出30天（或者一个月）时，会使得相关负责人失去对项目的专注，会使得每次迭代的复杂度大幅增加，而且也无法满足Scrum提倡的短时间会议要求。 最短要超出一周。如果一次迭代的长度短于一周时，项目组可能无法将需求转化成可用的功能。 在一个项目内保持每次迭代长度一致。因为这样可以使得软件开发团队保持固定开发速率，形成自己的节奏。这会使开发人员始终保持最佳状态。如果迭代长度发生变化，就会打乱开发人员的开发节奏，从而降低效率。 周期较长的迭代长度通常用于变化较少的环境，而周期较短的迭代长度则更适用于具有机会性或挑战性的环境。
如果我们使用较短的迭代长度，可能是因为： 不稳定的市场环境。当产品针对的是变化频繁的市场或者需求不确定性很大而且还有竞争对手虎视眈眈时，使用较短的迭代长度可以拥有更大的灵活性，更快地适应需求变化。 不稳定的团队。较短的迭代长度能够让不熟悉的团队成员更清晰地了解团队的动态，从而更快速地融合，提高生产率。 不确定的技术方案。每当要使用新技术时，都需要尽早了解其使用方法和价值。用新技术先开发小的功能模块，使用较短的迭代长度，可以快速地评估新技术是否可用。 需要确定团队的速率。要制定一个较精准的迭代计划，需要确定一个开发团队的开发速率；使用较短的迭代长度，可以快速地确定团队的开发速率。 提供学习的经历。较短的迭代长度，可以使得团队可以做出尝试，然后总结失败的经验教训并做出改变，再继续尝试。换言之，较短周期的迭代为项目组提供了学习体验。 降低项目风险。短周期迭代允许团队尝试、犯错，但它能以较小的代价消除项目的不确定因素，方便更频繁地控制项目。
使用短周期的迭代可以解决上述问题，但它同时也有它的弊端。那就是短周期的迭代会带来更高的成本。比如为期2周的迭代长度与一个为期30天的迭代长度相比，你需要进行双倍的Sprint计划会议、回顾会议以及评审会议，而且项目组也会面临更大的压力。 所以，设置迭代长度也是个技术活，需要管理者根据项目的实际情况合理地设置。 这正是： 迭代长度不能长，太长管控失了样 迭代长度不能短，短了没有好增量 参考书目：30天软件开发——告别瀑布拥抱敏捷，作者：Ken Schwaber Jeff Surherland，出版社：人民邮电出版社 |
