迭代长度

http://space.itpub.net/13633641/viewspace-312630

很多教材上都有关于这个问题的解答。迭代长度通常建议为 2-6 周，这是一个经验数值。到底选择几周为一次迭代，这个问题其实不太难，因为你只有 1、2、3、4、5、6 这 6 个数字需要选择。

我们太极敏捷派的建议是这样的:

如何确定迭代长度，有这样几个关键点需要权衡。

第一，我们希望每次迭代开发，可以获得实质性的进展，完成足够的开发任务，所以对于普通项目 1 周的迭代长度就显得有点短，做不了几天的开发就要 close，不合算。

第二，迭代任务 (包括模块集成、系统测试、评审等等) 的完成，应该比较顺畅 (streamlined) 、从容或者适度紧张，没有非常紧迫、仓促的感觉。如果在某次迭代开发中，需要砍掉很多完成不了的任务，感到进度很紧张，那么很可能说明迭代的长度设置太短了，在下一轮的开发中应该增加迭代的长度。

第三，总体上我们希望迭代越短越好，它有个下限，短于这个下限就可能得不偿失。那么，迭代时间为什么不能过长？它的上限是多少呢？迭代的主要目的是为了及时获得各方面反馈，确认已开发的内容是正确和可靠的，从而减少风险，保证开发能够始终稳步地前进。显然迭代过长，很长时间不对已开发的系统部分进行验证、反馈，随之而累积的各种风险就可能增加。如果超过一个半月 (6 周) 以上，还都拿不出一些可以执行、验证和 demo 的软件程序，那么这样的项目开发显然不能说是高效的。

从 2 到 6 周，建议选择偶数 2、4、6 周作为迭代长度，排除奇数 3、5 周。执行周计划周总结和月计划月总结是国内很多企业比较普遍的做法，显然设置迭代长度为半个月、一个月或一个半月，就能与之相合拍，更自然和便于管理。设想，当您做月度总结的时候，只完成了 1 又 1/3 的迭代，会是什么感觉？

迭代长度通常还与整个项目的工期 (或复杂度、规模) 有关。如果项目的工期在 1 年以上，那么 1 个月或 1.5 个月的迭代长度就是比较合适的。假设 2 周就要完成一次迭代，持续干上一年，大家会不会感到太累、太频繁？如果整个项目工期小于 3 个月，那么 2 周迭代甚至 1 周迭代，就是非常合适的。对于进度这么紧的项目，可能每周都是非常宝贵的。

通常，张恂会向客户推荐采取 2 周或 4 周作为迭代长度的首选，3 周、5 周和 6 周作为备选，往往大项目、比较复杂的项目才会采用 6 周，6 周以上基本不考虑。2 周通常适合各方面很成熟的开发团队。如果一个传统瀑布团队，要尝试着转向迭代开发方式，从 4 周的迭代开始学习、积累经验，然后逐步缩短迭代长度，是比较稳妥的。

建议一个团队在熟练使用 2 周迭代半年之后，再尝试 1 周迭代。

不同的项目开发阶段，可以采用不同的迭代长度。根据 UP 的建议，我们通常可以把一个项目分为起始、细化、构造和移交四个阶段。项目前期的起始、细化阶段，很多内容不明确，需要做很多探索性的工作，一般迭代的长度可以适度拉长，比方 2-4 周；而在构造、移交阶段，架构已经明确和稳固，主要追求开发实现的速度，所以迭代长度可以适当缩短，比方 1-2 周。

最后，最重要的是，在敏捷开发中，迭代的长度完全是可调的。如果开始的迭代长度设置太短，或太长，没关系，我们都可以在随后的迭代中根据项目反馈进行调整，这就叫自适应 (adaptive) 。