你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

建立迭代和发布计划

敏捷和其他迭代方法基于迭代和发布的概念。本文概述了规划期间迭代和发布的分配。这些分配提升了时间线可见性，使云策略团队成员之间的对话更加轻松。这些分配还以云采用团队可以在实现过程中管理的方式协调技术任务。

建立迭代

在技术实现迭代方法中，需要围绕重复的时间块规划技术工作。迭代通常为一周到六周的时间块。共识表明，对于大多数云采用团队，平均迭代持续时间为两周。但是，迭代持续时间的选择取决于技术工作的类型、管理开销和团队的偏好。

要开始根据时间线协调工作，建议定义一组持续 6 到 12 个月的迭代。

要使工作与迭代和发布保持一致，需要了解速度。速度是可在任何给定迭代中完成的工作量。在规划早期阶段，速度是估计值。经过多次迭代，速度成为团队可以自信地做出承诺的一个非常有价值的指标。

可以用故事点等抽象术语来度量速度。还可以用更具体的术语（如小时）来度量它。对于大多数迭代框架，建议使用抽象度量，以避免精度和感知方面的挑战。本文中的示例表示每个冲刺 (sprint) 的速度（以小时为单位）。这种表示形式使该主题更容易被普遍理解。

示例：一个五人云采用团队已承诺进行为期两周的冲刺 (sprint)。鉴于当前义务（如会议和支持其他流程），每个团队成员每周可以持续为采用工作贡献 20 小时。对于此团队，初始速度估计值是每个冲刺 (sprint) 100 小时。

最初，通过基于优先积压工作 (backlog) 评估技术任务来计划迭代。云采用团队会估计完成各种任务所需的工作量。然后，将这些任务分配给第一个可用的迭代。

在迭代规划期间，云采用团队会验证并优化估计值。在使所有可用速度与特定任务保持一致之前，他们会一直这样做。此过程会针对每个优先工作负载持续进行，直到所有工作都与预测的迭代保持一致。

在此过程中，团队会验证分配给下一个冲刺 (sprint) 的任务。团队根据团队关于每个任务的对话更新其估计值。然后，团队将每个估计的任务添加到下一个冲刺 (sprint)，直到达到可用速度。最后，团队估计其他任务，并将它们添加到下一个迭代。团队会执行这些步骤，直到该迭代的速度也耗尽。

上述过程将继续进行，直到所有任务都分配给迭代。

示例：让我们基于前面的示例进行构建。假设每次工作负载迁移都需要 40 个任务。此外，假设你估计每个任务平均需要一小时。每次工作负载迁移的合并估计时间为大约 40 小时。如果这些估计值对于全部 10 个优先工作负载保持一致，则这些工作负载需要 400 小时。

上一示例中定义的速度表明，迁移前 10 个工作负载需要四次迭代，即两个月的日历时间。第一个迭代包含 100 个任务，可迁移两个工作负载。在下一个迭代中，类似的包含 100 个任务的集合可迁移三个工作负载。

警告

前面的任务数和估计值仅用作示例。技术任务很少那么一致。不应将此示例视为反映了迁移工作负载所需的时间量。

在云采用中，发布定义为可产生足够业务价值的可交付成果的集合，以对业务流程中断风险作出解释。

将任何与工作负载相关的更改发布到生产环境都会导致业务流程发生一些更改。理想情况下，这些更改是无缝的，业务可以看到更改的价值，且不会造成明显的服务中断。但是，任何更改都存在业务中断的风险，不应掉以轻心。

为确保更改的潜在回报是合理的，云策略团队应参与发布规划。任务与冲刺 (sprint) 保持一致后，团队就可以确定每个工作负载何时准备好进行生产发布的粗略时间线。云策略团队将审查每次发布的时间安排。然后，团队将确定风险与业务价值之间的拐点。

示例：继续前面的示例，云策略团队已审查迭代计划。通过审查确定了两个发布点。在第二个迭代期间，共有 5 个工作负载将准备好进行迁移。这 5 个工作负载将提供重要的业务价值，并触发第一次发布。下一次发布将在两次迭代后进行，届时接下来的五个工作负载已准备好发布。

对于在 Azure DevOps 中管理云采用计划的客户，通过为每个任务和用户情景分配迭代路径来反映前面的流程。我们还建议使用特定发布来标记每个工作负载。该标记和分配为自动填充时间线报告提供了依据。

估计时间线以正确传达预期。