迭代类型

什么是敏捷世界中的迭代？它和我们软件社区中从前一直在用的迭代方式有什么区别？ScrumDevelopment 用户组最近对 Jeff Sutherland 所定义的 A、B、C 三种 Sprint（Sprint 就是 Scrum 词汇中的迭代）进行了讨论，他们的想法也是整个敏捷社区应当关注的。

敏捷社区中的大多数人应该会同意下面这个对迭代的定义：

迭代是一个恒定的时间范围，开发团队在这个范围当中完整地构建系统的某个部分，用“完成（Done）状态”来定义其完整性。这样做允许团队通过从需求到尽可能接近部署中采纳概念的过程中学习领悟，并且使项目的进展真正达到透明化。

此外，迭代是连续进行的，一个迭代的结束就会紧接着下一个迭代的开始。迭代的这个定义和早先（前敏捷时代）若干种定义的主要区别就是“完成状态”——前敏捷时代的迭代会在多个时间周期内完成同一个功能的不同部分，而并不需要达到完成状态。

因此，基于这样一个根本性的理解，Jeff Sutherland 在《 Scrum 之未来：在复杂项目中并行安排 Sprint（Future of Scrum: Parallel Pipelining of Sprints in Complex Projects）》一文中给出了三种迭代的定义，我们在下面用图形描述这三种迭代：

在这里它们之间最主要的区别就是重叠。A 在迭代 /Sprint 之间留有“喘息期”，给了项目团队一个确认上一个迭代 /Sprint 的完成状态的机会，并且留出时间间隔，用来沟通需求，并且为下一个 Sprint 确认需求。

B 则和上面描述的迭代定义很像。Sprint 之间存在着一小部分重叠工作，因为项目负责人 / 客户要为下一个 Sprint/ 迭代准备需求，他们在下一个 Sprint/ 迭代的准备会议中给这些需求定案。

C 被用于计划管理，以便使多个相关产品的 Scrum 并发运行。这个图看起来更像在展示一个使用“多个Scrum 的Scrum（Scrum of Scrums）”的组织中的重叠。如果你认为这看起来有点令人摸不着头脑或者表义不清，那么你不是唯一一个这么想的人；在Jeff Sutherland 拜访过Serge Beaumont 的公司之后，后者就尝试过澄清它们的区别。

那么，对于Scrum 社区，以及更大范围的敏捷社区来说，这个概念为什么很重要呢？有些人，比如说 Ken Schwaber ，认为这样做会让我们注意力的焦点不再专注于真正重要的东西之上：

我一直在留意关于 N、A、B、C 类迭代类型和进阶 Scrum 的讨论帖子。尽管这些可能会代表组织在经历过 Scrum 的观察和适应所采用的工程、人事和产品的管理实践，但它们都不是 Scrum。我认为我们把 Scrum 所带来结果和 Scrum 本身错误的混淆在一起了。这些假定的扩展最具破坏性的，就是它们会将人们的注意力从 Scrum 的真正实践中转移开来……

其他人则会认为反思和理解敏捷开发中的一项基础实践是非常重要的。您又是怎么认为的呢？

查看英文原文： Iteration Types