一. 敏捷转型之初，Scrum团队可能会想基于发布来规划迭代周期
在前几天与某个团队进行交流时，ScrumMaster说想在未来几周内规划一个为其一周的小迭代以开发和交付一个小规模的需求。我建议仍然采用为期2周的迭代，可以在迭代内规划一个发布版本来完成这个需求的开发和发布。
这是一个非常典型的现象：在刚开始实施Scrum时，许多Scrum团队可能会想要根据发布版本来调整迭代周期。当迭代时间盒已到达而发布内容还差少许未能全部完成时，Scrum团队可能会想要把迭代延长几天——以便在本迭代内完成所有发布内容的开发和测试；而当发布版本工作量偏少、无需一个标准迭代周期就能完成时，Scrum团队又会想要把迭代周期缩短——以便本迭代能刚好完成这个小版本的开发和测试工作。二. 敏捷倡导“按节奏开发、按需发布”
敏捷方法论中倡导“按节奏开发、按需发布”——这里的“节奏”就是指固定的迭代周期。也就是说；开发应该是有规律的，应该按照固定的周期来进行迭代开发，每个迭代都应该完成一批需求的开发和测试工作；发布是业务上的事情，应该根据业务需要来规划发布版本和发布时间点，发布工作既可以在迭代结束时进行，也可以在迭代过程中进行。
三. 为何要采用固定的迭代周期
那为何要采用固定的迭代周期呢？或者说，固定的迭代周期能带来什么好处呢？一般来说，固定迭代周期能够带来以下几点好处：
1 固定迭代节奏能大大简化内外部的协作管理
由于迭代周期是固定的，所以需求梳理、迭代计划、迭代评审、迭代回顾等关键事件在时间上都变得有规律。这样一来，团队内外部干系人就可以提前在自己的工作日历上计划这些事件。反之，如果迭代周期是变动的，就必须临时预约内外部干系人来参与这些事件，这就使得内外部协作变得更加复杂。
而对于需要多个团队协作完成的解决方案，如果能够以相同的迭代节奏来统一各团队的开发工作，无疑能大大简化跨团队的依赖管理和解决方案的集成管理。
所以固定迭代周期，能够大大简化内外部的协作管理。
2 固定迭代节奏使得大版本的规划和跟踪变得更加容易
当迭代周期固定且团队相对稳定时，每个迭代能够完成开发和测试的需求量也是相对稳定的，Scrum团队可以度量每个迭代交付的需求量——即“迭代速率”。迭代速率会在一定范围内波动，我们可以统计其平均值。
当我们需要发布一个里程碑版本时，我们可以基于平均迭代速率来规划大概需要花费几个迭代能完成这个发布版本。例如，假定某史诗故事的故事点数是480，而团队的平均迭代速率是100，那么我们就可以规划5个迭代来完成这个史诗故事的开发和交付。
在版本开发中，我们还可以基于迭代来绘制版本燃尽图（如图1所示），以量化跟踪版本的开发进度、平滑工作强度和尽早暴露进度风险。
3 固定迭代节奏有助于团队的产品和过程的持续改进
在迭代节奏固定的情况下，团队可以例行地收集外部反馈意见，并以此来改进自己的产品，以及例行总结本迭代的经验教训，并应用于下一迭代。
在迭代节奏固定的情况下，团队可以度量迭代产能、质量和进度数据，并且以这些数据来牵引团队的改进方向和验证改进效果。
四. 您有何经验
您团队的迭代周期是固定不变的吗？当迭代时间盒已到达而发布内容还差少许没有完成时，您会延长迭代时间吗？如果您的解决方案由多个开发团队协同完成，这些开发团队的迭代节奏是一致的吗？
欢迎在评论区留下您的观点。
本文作者
李洁（Jerry Li）
CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
