迭代的结构

迭代组合

尽管敏捷方法在名称、工作单元甚至迭代时长上有所不同，但各方至少对迭代的形态达成了共识。每个迭代由三个部分组成：

• 启动（Kickoff）：每个迭代以启动开始。在此阶段，团队确定哪些工作项将纳入本次迭代。所选工作项的数量应基于团队实际可完成的范围——既不过多也不过少。团队将承诺完成这些工作项。

• 执行（Work）：迭代的核心内容是实现已确认的工作项。这包括分析、设计、构建、测试以及工作项的验收。每天，团队都会通过每日站会回顾进展。

• 评估（Evaluation）：每个迭代结束时，团队与相关利益相关方共同进行评估。已完成的工作项会被审查，通常还会进行演示。同时，团队的方法也会被审视：质量是否达标？进度是否足够快？能否进一步提升效率？针对改进措施将在下一个迭代中实施，并在下一次评估中自然再次检验。

为什么采用迭代？

以迭代方式工作是一种强大的工具。许多瀑布模型的弊端在敏捷模式下得到了有效缓解。其主要优势简要如下：

• 降低风险：当然，我们承认敏捷项目同样存在与瀑布模型类似的潜在风险。例如，选定的软件架构可能存在局限性，用户界面可能不符合预期，性能表现可能不尽如人意，软件可能无法在生产环境中运行，与其他系统、服务或中间件的集成也可能复杂困难。

敏捷与瀑布的关键区别在于：所有计划中的工作项都在一个迭代内完成，因此风险能够更早被发现——不是等到项目末期，而是在最初的几个迭代中。越早识别风险，其带来的负面影响就越小。

• 应对变化：每个迭代开始时，优先选择当前最重要的工作项。如果在迭代过程中发现新的工作项，或已有工作项发生变化，只需将其加入待办事项列表。若后续确认其重要性，便可将其排入下一迭代的优先级。

而在瀑布项目中，这类变更需通过提交变更请求来处理，往往积压累积，最终才得以交付。在敏捷模式下，若发现某项工作并不重要，可在投入过多时间前直接放弃。

• 协作角色：在每个迭代中，选定的工作项被完整实现。分析、设计、编码、测试和验收等环节快速衔接，理想情况下可在同一天内完成。与瀑布模型中各角色分阶段参与不同，敏捷模式下所有角色同步协作。各方能充分共享知识与经验。

以一项工作项的设计为例：在敏捷项目中，常通过跨职能研讨会完成，参与者包括领域专家、开发人员和测试人员，理想情况下还包含终端用户的输入。这种多学科协作的研讨会能在问题发生前就避免错误，显著提升工作项的质量与交付速度。

• 时间盒机制：工作项的实现周期无法精确到最小单位进行规划。有时实现速度低于预期，偶有技术难题出现。然而，让迭代持续到所有工作项全部完成是不合理的。因此，迭代采用固定时长的时间盒机制。未完成的工作项将在时间盒结束后重新回到待办列表。时间盒机制有效防止了无休止的延期。

• 数据揭示进展：单个工作项的完成状态清晰明确——要么已完成，要么未完成，判断标准非常直观。在整个项目过程中，随时可以统计已完成的工作项数量（通常以点数衡量）。这种精准的进度信息使团队能够在出现延迟时及时、迅速地做出调整。