將敏捷式調整為大型小組

大 詞和 敏捷 式通常不會在同一個句子中使用。 大型組織贏得了緩慢移動的聲譽。 不過，這正在改變。 許多大型軟體組織已成功轉型為 Agile。 他們正學習如何使用或不使用 SAFe、 LeSS 或 Nexus 等熱門架構來調整敏捷式原則。

在 Microsoft，其中一個這類組織會使用 Agile 來建置 Azure DevOps 品牌下隨附的產品和服務。 此群組有 35 個功能小組，每三周發行至生產環境。

Azure DevOps 中的每個小組都會從頭到尾擁有功能。 他們擁有客戶關係。 他們管理自己的產品待辦專案。 他們會撰寫程式碼並簽入生產分支。 每三周部署一次生產分支，發行就會公開。 小組接著會監視系統健康情況並修正即時網站問題。

根據敏捷式原則，自主小組更具生產力。 敏捷式組織希望其小組能夠控制其日常執行。 但是，沒有對齊的自主性將導致混亂。 數十個獨立工作的小組不會產生統一、高品質的產品。 一致性可讓小組達到其目的，並確保他們符合組織目標。 如果沒有對齊，即使是表現最好的團隊也會失敗。

若要調整 Agile，您必須啟用小組的自主權，同時確保與組織保持一致。

若要管理對齊與自主之間的微妙平衡，DevOps 領導者必須定義分類法、定義規劃程式，以及使用功能聊天。

定義分類法

敏捷式小組及其所屬的較大型敏捷組織需要明確定義的待辦專案才能成功。 如果組織目標不清楚，團隊將難以成功。

為了設定清楚的目標，並說明每個小組對其貢獻的方式，組織必須定義分類法。 明確定義的分類法會為組織建立命名法。

常見的分類法是 史詩 、特徵 、 故事 和 工作 。

Epic

Epics 描述組織成功的重要舉措。 Epics 可能需要數個小組和數個短期衝刺才能完成，但並非沒有結束。 Epic 有一個明確的目標。 一旦達到，史詩就關閉了。 進行中的 Epic 數目應該可管理，以便讓組織保持專注。 Epic 會細分成特徵。

功能

功能定義實現 Epic 目標所需的新功能。 功能是發行單位;它們代表發行給客戶的內容。 已發佈的版本資訊可以根據最近完成的功能清單來建置。 功能可以採用多個短期衝刺來完成，但應該調整大小，以確保對客戶的價值流程一致。 功能細分成故事。

劇本

劇本會定義小組必須提供的累加值，才能建立功能。 小組會將功能細分成累加片段。 單一已完成的故事可能無法為客戶提供有意義的價值。 不過，已完成的故事代表生產品質的軟體。 故事是團隊的工作單位。 小組會定義完成功能所需的故事。 劇本可以選擇性地細分成工作。

工作

工作會定義完成本文所需的工作。

方案

這個分類法不是一刀切的系統。 許多組織都引進了高於 Epic 的層級，稱為 「計畫 」。

每個層級的名稱都可以針對您的組織量身打造。 然而，上述定義的名稱（史詩、特徵、故事）在業界廣泛使用。

自主性線

一旦設定分類法，組織就必須劃出一 條自主權線。 自主性線是層級擁有權從管理傳遞至小組的點。 管理不會干擾小組所擁有的層級。

下列範例顯示下列特徵所繪製的自主權線。 管理擁有 Epic 和功能，可提供對齊方式。 Teams 擁有故事和工作，並擁有執行方式的自主權。

在此範例中，管理不會告訴小組如何分解劇本、規劃短期衝刺或執行工作。

不過，小組必須確保其執行符合管理的目標。 雖然小組擁有其待辦案例，但他們必須將其待辦專案與指派給他們的功能保持一致。

規劃

若要調整敏捷式規劃，小組需要每個分類層級的計畫。 不過，請務必反覆運算和更新方案。 此程式稱為滾動波規劃。

此計畫會提供固定時段的方向，並定期進行預期的校正。 例如，每六個月可以校正 18 個月計畫。

以下是分類法每個層級的規劃方法範例：Epic、功能、故事、工作。

視覺

願景 是透過史詩來表達，並設定組織的長期方向。 Epics 定義組織在未來 18 個月內想要完成的內容。 管理部門擁有計劃，並每六個月校正一次。

願景是在全能會議中提出的。 由於願景旨在雄心勃勃，而且在此期間可能會有很大的變化，預計將完成大約60%的願景。

季節

一個 賽季 是透過功能描述的，並設定未來六個月的策略。 功能可決定組織想要為其客戶點燃的內容。 管理擁有季節性計劃，並在全能會議上呈現願景和季節性計劃。 所有小組計劃都必須符合管理層的季節性計劃。 預計完成約 80% 的季節性計劃。

3-sprint 計劃

3 短期衝刺計劃會定義小組在接下來的三個短期衝刺中完成的故事和功能。 小組擁有計劃，並校正每個短期衝刺。 每個小組都會透過功能聊天呈現其管理計劃（請參閱下方）。 此計劃會指定小組的執行如何配合 6 個月的季節性計劃。 預計完成約90%的3短期衝刺計劃。

短期衝刺計劃

短期 衝刺計劃 會定義小組將在下一個短期衝刺中完成的故事和功能。 小組擁有短期衝刺計劃，並將其電子郵件傳送給整個組織，以取得完整的透明度。 該計劃包括小組在過去短期衝刺中完成的工作，以及他們下一個短期衝刺的重點。 預期會完成約95%的短期衝刺計劃。

自主性線

在此範例中，會繪製自主權線，以顯示小組有規劃自主權的位置。

如上所述，管理不會將擁有權延伸至自主權線之下。 管理會使用願景和賽季計劃提供指引，然後讓小組自主權來建立 3 個短期衝刺和短期衝刺計劃。

功能聊天：自主性符合對齊的位置

功能聊天是一個低儀式會議，其中每個團隊都向管理展示他們 3 短期衝刺計劃。 此會議可確保小組計劃符合組織目標。 這也有助於管理隨時瞭解小組正在做什麼。 雖然 3 短期衝刺計劃會校正每個短期衝刺，但功能聊天會視需要保留，通常是每一到三個短期衝刺。

功能聊天會議會為每個小組配置 15 分鐘。 透過12個功能小組，這些會議可以排程到持續約三個小時。 每個小組都會準備 3 張投影片組，其中包含下列投影片：

功能

第一張投影片概述小組在接下來的三個短期衝刺中將會亮起的功能。

債務

下一張投影片說明小組如何管理技術債務。 債務是不符合管理層質量標準的東西。 工程總監會設定品質橫條，所有團隊都一樣（對齊）。 範例品質橫條包括每個工程師的 Bug 數目、通過的單元測試百分比，以及效能目標。

問題和相依性

最後一張投影片上所列的問題和相依性包含任何會影響小組進度的問題，例如小組無法解決的問題，或與其他需要呈報的小組相依性。

每個小組都會將投影片直接呈現給管理。 小組會介紹其 3 短期衝刺計劃如何配合 6 個月的季節性計劃。 領導要求澄清問題，並建議方向的變化。 他們也可以要求後續會議來解決更深層次的問題。

如果小組的計劃無法符合管理的期望，管理可能會要求重新規劃。 在這個罕見的事件中，小組會重新規劃並排程第二個功能聊天來檢閱。

信任：黏附在一起保持一致性和自主性

大規模練習敏捷式時，信任是雙向街道：

• 管理必須信任團隊才能做正確的事。 如果管理不信任團隊，他們就不會給予小組自主性。

• 小組藉由持續提供高品質的程式代碼來贏得信任。 如果小組不值得信任，則管理不會賦予他們自主權。

管理必須為小組提供明確的計劃，才能與小組保持一致，然後信任其團隊執行。 Teams 必須將其計劃與組織保持一致，並以可靠的方式執行。

隨著組織想要將敏捷式調整為較大的案例，關鍵是讓小組自主權，同時確保他們符合組織目標。 關鍵建置組塊明確定義擁有權和信任文化。 一旦組織有了這個基礎，他們就會發現敏捷式可以很好地調整規模。

下一步

對於任何規模的小組來說，有許多方法可以立即開始了解優點。 請查看這些調整的一些做法。

瞭解 Azure DevOps 功能，以跨小組進行組合管理和可見度。

Microsoft 是世界上最大的敏捷式公司之一。 深入瞭解 Microsoft 如何調整 DevOps 規劃。