建立反覆項目和發行方案

敏捷方法和其他反覆方法都是根據反覆項目和版本的概念建置的。本文概述在規劃期間反覆項目和版本的指派。這些指派可提高間軸可見性，讓雲端策略小組成員之間的交談更加容易。指派也會以雲端採用小組在實作期間所能管理的方式來調整技術工作。

建立反覆項目

在技術實作的反覆方法中，您會圍繞週期性時間區塊規劃技術工作。反覆項目往往會是一到六周的時間區塊。共識建議兩周是大部分雲端採用小組的平均反覆項目持續時間。但是反覆項目持續時間的選擇取決於技術工作的類型、系統管理負荷，以及小組的喜好設定。

若要開始將工作與時間軸保持一致，我們建議您定義一組持續 6 到 12 個月的反覆項目。

您必須了解速度，才能將工作與反覆項目和版本保持一致。速度是可在任何給定反覆項目中完成的工作量。在早期規劃期間，速度是估計值。在數個反覆項目之後，速度就會成為極具價值的指標，指出小組可以安心地做出的承諾。

您可以採用像是案例點的抽象字詞來測量速度。也可以採用像是時數的更具體字詞來測量速度。針對大部分的反覆架構，建議使用抽象測量，以避免精確度和認知方面的挑戰。本文中的範例代表每個短期衝刺的速度 (以小時為單位)。此表示法可讓主題更能為人所了解。

範例：五個人組成的雲端採用小組已承諾進行兩周的短期衝刺。鑑於目前的義務 (例如會議和其他流程的支援)，每個小組成員每週對採用工作會持續貢獻 20 小時的時間。針對此小組，每個短期衝刺的初始速度預估為 100 小時。

最初，您可以根據已設定優先順序的待辦項目來評估技術工作，以規劃反覆項目。雲端採用小組會評估完成各種工作所需的努力。然後，這些工作會指派給第一個可用的反覆項目。

在反覆項目規劃期間，雲端採用小組會驗證並精簡估計值。他們會這麼做，直到將所有可用的速度與特定工作保持一致為止。此流程會針對每個設定優先順序的工作負載繼續進行，直到所有的工作都符合預測的反覆項目為止。

在此流程中，小組會驗證指派給下一個短期衝刺的工作。小組會根據小組有關每項工作的對話來更新其估計值。然後，小組會將每個估計的工作新增至下一個短期衝刺，直到符合可用的速度為止。最後，小組會估計額外的工作，並將其新增至下一個反覆項目。小組會執行這些步驟，直到該反覆項目的速度也耗盡為止。

先前的流程會繼續進行，直到所有工作指派給反覆項目為止。

範例：讓我們根據上述範例進行建置。假設每個工作負載移轉都需要 40 個工作。也假設您估計每個工作的平均所需時間為一小時。合併的估計值是每個工作負載移轉大約 40 小時。如果這些估計值對於全部 10 個已設定優先順序的工作負載都保持一致，則這些工作負載將需要 400 小時。

上述範例中定義的速度，建議移轉前 10 個工作負載將需要四個反覆項目，這是兩個月的行事歷時間。第一個反覆項目將由導致兩個工作負載移轉的 100 個工作組成。在下一個反覆項目中，100 個工作的類似集合將導致三個工作負載移轉。

警告

上述的工作數和估計值會嚴格作為範例使用。技術工作很少是一致的。您不應該將此範例看成移轉工作負載所需時間量的反映。

在雲端採用內，版本會定義為交付項目的集合，其會產生足夠的商務價值，證明商務流程中斷的風險是合理的。

將任何工作負載相關的變更釋出至生產環境，可對商務流程建立一些變更。在理想情況下，這些變更是無縫的，且企業會看到變更的價值，而不會對服務造成重大中斷。但是，任何變更都有商務中斷的風險，不應掉以輕心。

若要確保變更的潛在報酬是合理的，雲端策略小組應參與發行規畫。一旦工作與短期衝刺保持一致，小組就可以確定每個工作負載何時為生產版本做好準備的粗略時間軸。雲端策略小組會檢閱每個版本的時間。然後，小組會識別風險與商務價值之間的轉折點。

範例：繼續先前的範例，雲端策略小組已檢閱反覆項目計劃。此檢閱已識別兩個發行點。在第二個反覆項目期間，總共有五個工作負載準備好移轉。這五個工作負載將提供重大的商務價值，並會觸發第一次發行。下一次發行將在兩個反覆項目之後進行，同時接下來的五個工作負載已準備好發行。

針對在 Azure DevOps 中管理雲端採用方案的客戶，會將反覆項目路徑指派給每個工作和使用者案例，來反映先前的流程。我們也建議您使用特定版本標記每個工作負載。該標記和指派摘要會自動填入時間軸報告。

估計時間軸，用來適當地傳達期望。