敏捷项目基于在固定时间段内交付软件和其他项目产出的方法，这个过程称之为迭代。特别地，软件是以一系列等长周期的迭代形式来交付的。其他非软件形式交付品的交付也可以从迭代方法中受益。实践敏捷开发的必要条件是每个迭代应该交付可测量的，具体的结果——最好还要有明确相关的商业价值。在某些情况下，这只是简单意味着一个分阶段的实现，然而尝试在每个迭代末期增量式地交付可测试，可运行的产品是更值得推荐的做法，这样我们就能从相关的早期反馈和测试中受益。迭代式交付基于精益制造的原则，该原则在Mary Poppendieck所写的文章中有相关描述——并且这也可以应用于非软件项目中。

迭代是一个固定的时间段，长度为一至三周，在这期间，开发团队将交付一定数目的User Story。一个迭代包括计划，启动和回顾三个部分，分别由迭代计划会议、迭代启动会议、迭代回顾会议提供。

我们把发布周期分解为一系列的迭代，有时也把它们称作Time Boxes。迭代是ThoughtWorks公司敏捷核心实践之一。

谁应该参与？
每个迭代都应该有整个团队和全部的敏捷角色参与。值得注意的是，在任何时刻都有多项工作在并行进行，整个团队需要一起参加迭代启动会议和迭代回顾会议。开发者团队实现当前迭代的功能，与此同时业务分析团队细化下一个迭代的User Story，测试团队协助定义下一个迭代的User Story验收标准，并且针对上一迭代的结果进行测试。整个工作流程请参考下图：
图缺

什么时候进行迭代？
在一个发布周期中会进行多个迭代。

将工作分解为更小的迭代可以提供以下好处：
??在每个迭代末期关于项目进度的可测量数据为客户提供了早期反馈及在Planning Game（我们的迭代计划会议）中对User Story重新排定优先级的能力
??交付速度可以测量
??可运行的软件使得用户能够很好地观察项目进度
??使客户可以逐步地对User Story进行验收

有没有什么先决条件？
工作必须能够分解成一些在一个迭代中能够完成的用户故事。

在以前的实践中是如何进行的？
迭代式开发在敏捷开发中是一个常见的实践和基础的原则。在迭代解剖图中可以看到关于在ThoughtWorks中迭代是如何进行的图示说明。

常见误区：

迭代长度：通常，迭代的长度应该在可实践的基础上尽可能短，如果User Story的大小可以使得普通开发者在一个迭代中至少能够完成两个，将会很有帮助。为了说明这一点，我们设想，如果你的User Story需要花费平均十个工作日来完成，而你的迭代长度只有两周，那么在迭代结束之后就很有可能一个完整的User Story都没有完成。

需求扰动（Requirement Churn）：固定一个迭代的需求是很有好处的。这可以使得团队能够更集中于将全部工作完成。如果有正在开发中的User Story发生了变化，除非它无关紧要，否则最好是将这个User Story移出这个迭代，重新分析它，然后在下一个迭代中再处理它。因为程序员可以继续下一个需求明确的User Story，而不用去等待，这可以帮助开发者节省时间。

额外的Story：上文的一个推论是，为一个迭代准备的User Story数目比你预期团队能够完成的数目稍多一些是很有好处的。这样如果一个Story被移出迭代进行分析时，你仍然有其他准备好的事情给开发者去继续工作。准备多种大小的Story也很有好处，因为这样你可以给完成较早的开发者分配额外的小Story。虽然你应该使用以前迭代的经验来计划迭代的预期产出，但是多准备一些额外的User Story有可能让你增加团队产出。

好的方面：每个迭代可以分别进行计划和回顾，从而可以更好地适应优先级的变化。在一个迭代周期中编写的所有代码都将进行设计，测试和最终得到接受，因而如果要求的话，理论上代码是可以在迭代的末期发布的。每个迭代都应该举行迭代计划会议，迭代启动会议以及迭代回顾会议。

极佳的方面：除此之外，每个迭代将会发布一个贯穿所有功能的“纵向切片”。例如，在一个在线银行的情景中，第一个迭代可能只是开发statements，第二个迭代可能只是开发从前端到持久层的付款功能。每个迭代不应该超过两周。