您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

建立迭代和发布计划Establish iterations and release plans

敏捷和其他迭代方法基于迭代和发布的概念。Agile and other iterative methodologies are built on the concepts of iterations and releases. 本文概述了在规划过程中的迭代和发布的分配。This article outlines the assignment of iterations and releases during planning. 这些分配用于在云策略团队的成员之间更轻松地进行会话。Those assignments drive timeline visibility to make conversations easier among members of the cloud strategy team. 分配还以云采用团队在实现期间可以管理的方式协调技术任务。The assignments also align technical tasks in a way that the cloud adoption team can manage during implementation.

建立迭代Establish iterations

在技术实现的迭代方法中,你计划围绕定期时间段的技术工作。In an iterative approach to technical implementation, you plan technical efforts around recurring time blocks. 迭代通常是一周到六周的时间块。Iterations tend to be one-week to six-week time blocks. 共识表明,两周是大多数云采纳团队的平均迭代持续时间。Consensus suggests that two weeks is the average iteration duration for most cloud adoption teams. 但迭代持续时间的选择取决于技术工作的类型、管理开销和团队首选项。But the choice of iteration duration depends on the type of technical effort, the administrative overhead, and the team's preference.

若要开始将工作调整到时间线,建议定义过去6到12个月的一组迭代。To begin aligning efforts to a timeline, we suggest that you define a set of iterations that last 6 to 12 months.

了解速度Understand velocity

将工作与迭代和发布进行协调需要了解速度。Aligning efforts to iterations and releases requires an understanding of velocity. 速度是可以在任何给定迭代中完成的工作量。Velocity is the amount of work that can be completed in any given iteration. 在早期规划期间,速度是一个估计值。During early planning, velocity is an estimate. 经过多次迭代后,速度会成为团队可以自信地做出的承诺的极具价值的指标。After several iterations, velocity becomes a highly valuable indicator of the commitments that the team can make confidently.

您可以在抽象术语(如情景点)中测量速度。You can measure velocity in abstract terms like story points. 还可以用更有形的术语来度量它,如小时。You can also measure it in more tangible terms like hours. 对于大多数迭代的框架,我们建议使用抽象度量来避免在精确和认知方面所面临的挑战。For most iterative frameworks, we recommend using abstract measurements to avoid challenges in precision and perception. 本文中的示例表示每个冲刺(sprint)的速度。Examples in this article represent velocity in hours per sprint. 这种表示形式使主题更广泛地被理解。This representation makes the topic more universally understood.

示例: 五位云采用团队承诺了两周冲刺(sprint)。Example: A five-person cloud adoption team has committed to two-week sprints. 考虑到会议和对其他过程的支持之类的当前义务,每个团队成员每周可持续提供20小时的时间,以采纳工作量。Given current obligations like meetings and support of other processes, each team member can consistently contribute 20 hours per week to the adoption effort. 对于此团队,初始速度估计值为每个冲刺(sprint)100小时。For this team, the initial velocity estimate is 100 hours per sprint.

迭代计划Iteration planning

最初,通过基于优先排序的积压工作(backlog)评估技术任务来计划迭代。Initially, you plan iterations by evaluating the technical tasks based on the prioritized backlog. 云采用团队估计完成各种任务所需的工作量。Cloud adoption teams estimate the effort required to complete various tasks. 然后,将这些任务分配给第一个可用的迭代。Those tasks are then assigned to the first available iteration.

在迭代计划期间,云采用团队验证并优化估计。During iteration planning, the cloud adoption teams validate and refine estimates. 它们将执行此操作,直到它们将所有可用的速度与特定任务对齐。They do so until they have aligned all available velocity to specific tasks. 此过程将继续针对每个优先工作负载,直到所有操作都符合预测的迭代。This process continues for each prioritized workload until all efforts align to a forecasted iteration.

在此过程中,团队验证分配给下一个冲刺(sprint)的任务。In this process, the team validates the tasks assigned to the next sprint. 团队根据每个任务的团队会话更新其估计值。The team updates its estimates based on the team's conversation about each task. 然后,团队会将每个估计的任务添加到下一个冲刺(sprint),直到达到可用速度。The team then adds each estimated task to the next sprint until the available velocity is met. 最后,团队估计其他任务并将其添加到下一次迭代。Finally, the team estimates additional tasks and adds them to the next iteration. 团队执行这些步骤,直到该迭代的速度也已经用完。The team performs these steps until the velocity of that iteration is also exhausted.

前面的过程将继续,直到将所有任务分配给迭代。The preceding process continues until all tasks are assigned to an iteration.

示例: 让我们来构建前面的示例。Example: Let's build on the previous example. 假设每个工作负荷迁移都需要40任务。Assume each workload migration requires 40 tasks. 还假设你估计每个任务平均占用一小时。Also assume you estimate each task to take an average of one hour. 每个工作负荷迁移约40小时。The combined estimation is approximately 40 hours per workload migration. 如果这些估计值对于所有10个优先级工作负荷保持一致,则这些工作负荷将需要400小时。If these estimates remain consistent for all 10 of the prioritized workloads, those workloads will take 400 hours.

上一示例中定义的速度表明,前10个工作负荷的迁移需要四个月的日历时间。The velocity defined in the previous example suggests that the migration of the first 10 workloads will take four iterations, which is two months of calendar time. 第一次迭代将包含100个任务,这些任务导致两个工作负荷的迁移。The first iteration will consist of 100 tasks that result in the migration of two workloads. 在下一次迭代中,类似的100任务集合将导致三个工作负荷的迁移。In the next iteration, a similar collection of 100 tasks will result in the migration of three workloads.

警告

前面的任务和估计数被严格用作示例。The preceding numbers of tasks and estimates are strictly used as an example. 技术任务的工作很少。Technical tasks are seldom that consistent. 你不应看到此示例来反映迁移工作负载所需的时间量。You shouldn't see this example as a reflection of the amount of time required to migrate a workload.

版本规划Release planning

在采用云的情况下,版本定义为可交付结果的集合,这些交付项可生成足够的业务价值来证明业务流程中断的风险。Within cloud adoption, a release is defined as a collection of deliverables that produce enough business value to justify the risk of disruption to business processes.

将任何与工作负荷相关的更改发布到生产环境会对业务流程进行一些更改。Releasing any workload-related changes into a production environment creates some changes to business processes. 理想情况下,这些更改是无缝的,企业会发现更改的价值,而不会对服务造成严重中断。Ideally, these changes are seamless, and the business sees the value of the changes with no significant disruptions to service. 但在发生任何更改时,业务中断的风险也不会发生变化。But the risk of business disruption is present with any change and shouldn't be taken lightly.

若要确保更改的潜在回报,云策略团队应参与发布规划。To ensure a change is justified by its potential return, the cloud strategy team should participate in release planning. 将任务与冲刺(sprint)对齐后,团队可以确定每个工作负荷可用于生产版本的大致时间线。Once tasks are aligned to sprints, the team can determine a rough timeline of when each workload will be ready for production release. 云策略团队将审查每个版本的时间。The cloud strategy team would review the timing of each release. 然后,团队会确定风险与业务价值之间的转折点点。The team would then identify the inflection point between risk and business value.

示例: 继续前面的示例,云策略团队已评审迭代计划。Example: Continuing the previous example, the cloud strategy team has reviewed the iteration plan. 审查标识了两个发布点。The review identified two release points. 在第二次迭代期间,总共有五个工作负荷可供迁移。During the second iteration, a total of five workloads will be ready for migration. 这五个工作负荷将提供重要的商业价值,并将触发第一个版本。Those five workloads will provide significant business value and will trigger the first release. 在接下来的五个工作负荷准备好进行发布时,下一版本将会出现两次迭代。The next release will come two iterations later, when the next five workloads are ready for release.

分配迭代路径和标记Assign iteration paths and tags

对于在 Azure DevOps 中管理云采用计划的客户,可以通过将迭代路径分配给每个任务和用户情景来反映以前的进程。For customers who manage cloud adoption plans in Azure DevOps, the previous processes are reflected by assigning an iteration path to each task and user story. 我们还建议使用特定版本标记每个工作负荷。We also recommend tagging each workload with a specific release. 标记和分配源自动填充时间线报表。That tagging and assignment feed the automatic population of timeline reports.

后续步骤Next steps

估计正确传达预期的时间线Estimate timelines to properly communicate expectations.