案例剖析：你团队的迭代周期该如何设定？

（PS：案例部分，节选自公众号Agile2046)

很多敏捷团队一开始不知道迭代周期设定多长合适。一般来说，迭代周期在1周到1个月以内的周期，而且一旦选定，迭代的长度在整个开发过程中保持一致。新的迭代周期在上一个迭代完成之后立即开始。那么到底多长合适呢？

初始设定方法

• 首先，应该选择以周为单位，即：1周，2周，3周，4周，而不是以天为单位，e.g. 7天，12天，22天等。道理很简单，以周为单位方便管理和沟通。以天为单位，大家还得打开日历数天数。这种事务性管理的成本越低越好。

• 其次，对于每个独立交付产品的团队，自己定义迭代的长度，不要整个公司或部门一刀切；对于一个项目有多个团队协同交付产品的情况，大家保持一个Sprint长度，方便跨团队计划和交付节奏对齐。此外，这样的大项目交付的情况里，每个团队有共同的语言，不至于你说的迭代1是我团队的迭代2。

• 再次，选择两周长度的迭代启动，进行了1个迭代后, 团队在回顾中讨论，迭代长度是否合理，是否需要短一些，或者长一些。现在大部分团队的迭代长度都是两周。为什么要选定两周的长度开始呢？下表列出了不同长度的d可达的对比：

Sprint不同长度的对比

从上图可以看出，不同的迭代长度，没有绝对的好或坏。两周可达的长度，各个维度处于居中的程度，因此，不必太过于纠结，可以从两周的长度开始，当团队发现一些问题的时候再调整。对于大部分团队，一个迭代运转后，没有发现需要调整过。

调整迭代实操方：（以案例为主线进行分析）

案例1

某公司刚开展敏捷转型的时候，给每个团队一刀切定为两周。很快在一些团队遇到问题。

一个做互联网产品的团队，每次迭代进行到中间的时候，经常出现更加紧急业务需求，而把原来规划的需求挤掉。团队跟产品负责人沟通，拒绝迭代中间调整需求，导致团队与产品负责人关系变得紧张。

这个时候，团队应该与产品负责人分析，这种情况发生的原因是什么。是由于产品负责人的工作没有做好，在迭代启动前没有准备好需求，到了迭代执行期间才临时发现需求？还是因为业务变化频繁，两周的迭代偏长，产品负责人无法提前两周预见需求？如果是业务变化确实比迭代频繁，可以考虑缩短迭代周期。但是，要确定这种频繁的业务变化是常态。如果只是临时出现的情况，不需要调整迭代的长度。

另一个做To B移动端App的团队也发现了问题。他们的移动端发布周期是三周一次，导致他们的迭代周期与发布周期错位。每次迭代结束的时候，产品不具备条件发布；而发布的时候，正式下一个迭代的中期。团队与产品负责人商议，是否需要让发布周期更频繁，而产品负责人认为，对于他们的客户，三周的发布周期完全满足客户的期望，过于频繁反而增加客户的更新成本。因此，团队决定，调整迭代的周期为三周，迭代的结束的时候正式发布的时候。

此外，迭代的长度也取决于团队的工程能力基础。对于那些没有任何自动化集成、自动化测试、自动化部署的“三无”团队，从瀑布转为两周的迭代周期，往往会发现迭代时间结束的时候，产品不具备可交付状态，测试人员加班到后半夜吐血。在这样的情况下，迭代周期是否需要调整呢？

有两个选择：

1. 延长迭代周期至3周-4周的长度，在每个迭代计划的时候，将工程能力提升任务纳入Backlog, 确保每个迭代在交付特性的同时也对工程能力有投资。但是要记住，过了一段时间在工程能力有所提升之后，团队再次回顾迭代周期是否可以缩短。

2. 迭代周期不变，调整DoD(完成的定义)，修改为在目前的迭代周期长度下，产品可以达到的程度。要小心的是，采取这个选择必然造成下个迭代在补上个迭代遗留的功课。因此，这是一种妥协。

案例2：

某大型SaaS互联网软件产品由多个团队协作交付。在两周的迭代周期内，整个产品只能完成特性验证和基本回归验证，如果做全面的回归验证需要再花一周的时间。团队决定修改DoD完成的定义为:

a. 特性验证通过

b.系统级基本回归验证通过。

但是达到了这个DoD条件还不能发版。团队将系统级全回归验证放到了下一个迭代，在验证通过后发版，因此发版周期错后迭代一周时间。团队将如何缩短验证周期作为改进专项规划。需要注意的是，很多时候，貌似看起来测试周期长是测试的问题，究其根本原因是架构和代码的问题。团队每个迭代做一部分改进工作，直至一个迭代内可以达到发版条件。

由此可见，不管如何抉择，比迭代周期的初始设定更重要的，是团队在遇见问题后思考如何改进，并切实将改进任务纳入到每个迭代中去实施，逐步提升敏捷成熟度，达到迭代结束时产品具备可交付的状态。

不是一定要迭代到永远

迭代不是永远要有的。随着团队的敏捷成熟度的提升，当团队能够每天按需发布，甚至每天可以多次发布，即达到流式开发、持续交付的程度，那时候就可以抛弃迭代周期的约束，而迭代周期只作为团队计划的节奏，不再作为交付的节奏。

 

迭代周期常常是在敏捷项目已经进行了一段时间之后，才会固定下来。这是一个探索的过程。

当你感到迭代周期太短，在一个迭代周期内根本无法完成计划好的任务，那可能是由于对项目团队的开发速度估计有误，而迭代周期内的任务量又太大所造成的。

当一个迭代结束后，给用户演示的时候，发现软件功能已经背离了用户的需求，那可能是因为迭代周期太长，没能及时地得到用户的反馈。

所以，当项目进行了几个迭代之后，项目团队才能把握自己开发的速度，设计出适合项目的迭代周期。

总之，迭代周期的长短，不应该是一个固定的值，它应该根据实际需要而定。确定这个周期，不要遗忘了时间盒的作用：控制开发节奏，并且及时获得反馈。只要能够实现这个目标，迭代周期是长还是短也就不是那么重要了。

最后欢迎各位来体验和试用一下 ONES，一款非常好用的迭代管理工具，可以帮助题主做更精确地项目进度管理，管理需求和相关任务规划至迭代。