建立反覆項目和發行方案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. 本文中的範例代表每個短期衝刺的速度(以小時為單位)。Examples in this article represent velocity in hours per sprint. 此標記法可讓主題更廣泛地理解。This representation makes the topic more universally understood.

範例: 有五個人的雲端採用小組致力於為期兩周的短期衝刺。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. 針對此小組,每個短期衝刺的初始速度預估為100小時。For this team, the initial velocity estimate is 100 hours per sprint.

反覆項目規劃Iteration planning

一開始,您可以根據排定優先順序的待辦專案來評估技術工作,以規劃反復專案。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.

在這個過程中,小組會驗證指派給下一個短期衝刺的工作。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. 然後,小組會將每個估計的工作新增至下一個短期衝刺,直到達到可用的速度為止。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. 當工作與短期衝刺一致之後,小組就可以決定每個工作負載準備進行生產版本的粗略時間軸。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.