big 和 Agile 這兩個詞不經常用在同一個句子中。 大型組織贏得了行動緩慢的聲譽。 然而，這種情況正在改變。 許多大型軟體組織正在成功地向敏捷轉型。 他們正在學習在有或沒有流行框架（例如 SAFe、 LeSS 或 Nexus）的情況下擴展敏捷原則。
在 Microsoft，其中一個組織會使用敏捷式來建置以 Azure DevOps 品牌提供的產品和服務。 該群組由 35 個功能團隊組成，每三週釋出至生產環境。
Azure DevOps 內的每個小組都擁有從頭到尾的功能。 他們擁有客戶關係。 他們管理自己的產品待辦事項。 他們將程式碼編寫並提交至生產分支。 每三週部署一次生產分支，並將版本公開。 然後，團隊監控系統運行狀況並修復實時站點問題。
根據敏捷原則，自主團隊的生產力更高。 敏捷組織希望他們的團隊能夠控制他們的日常執行。 但沒有一致的自主會導致混亂。 數十個獨立工作的團隊無法生產出統一的高品質產品。 一致性為團隊提供目標並確保他們實現組織目標。 如果沒有協調，即使是表現最好的團隊也會失敗。
若要擴展敏捷，您必須為團隊啟用自主權，同時確保與組織保持一致。
為了管理一致性和自主性之間的微妙平衡，DevOps 領導者需要定義分類法、定義規劃流程並使用功能聊天。
定義分類
敏捷團隊及其所屬的更大的敏捷組織需要明確定義的待辦事項才能成功。 如果組織目標不明確，團隊將難以成功。
為了設定明確的目標並說明每個團隊如何為這些目標做出貢獻，組織需要定義分類法。 明確定義的分類法為組織創建了命名法。
常見的分類法是 史詩、 功能、 故事和 任務。
以金字塔形式展示的常見分類法圖表。
史詩
史詩描述了對組織成功很重要的舉措。 史詩賽可能需要幾個團隊和幾個衝刺才能完成，但它們並非沒有盡頭。 史詩有一個明確的目標。 一旦達到，史詩就結束了。 進行中的長篇故事數量應該是可管理的，以便讓組織保持專注。 史詩被分解為特性。
Features
功能定義了實現史詩目標所需的新功能。 功能是發佈單元；它們代表發佈給客戶的項目。 已發佈的版本資訊可以根據最近完成的功能清單來建置。 功能可能需要多個短衝才能完成，但應適當拆分以確保為客戶提供一致的價值流。 功能被分解為故事。
故事
故事定義了團隊必須提供才能創建功能的增量價值。 該團隊將該功能分解為增量部分。 單一完成的故事可能無法為客戶提供有意義的價值。 然而，一個完整的故事代表生產品質的軟體。 故事是團隊的工作單元。 團隊會定義完成功能所需的內文。 故事可以選擇性地分解為任務。
任務
任務定義完成劇本所需的工作。
倡議
這種分類法並不是一個放之四海而皆準的系統。 許多組織引入了稱為 倡議的史詩之上的級別。
每個層級的名稱都可以根據您的組織量身打造。 然而，上面定義的名稱（史詩、特性、故事）在業界中被廣泛使用。
自治線
一旦設定了分類法，組織就需要劃定一條 自主權的界限。 自主權界線是管轄範疇的掌控權從管理層轉移到團隊的界點。 管理不會干擾團隊擁有的層級。
下列範例顯示功能下方繪製的自主權線。 管理部門掌握用來對齊的重大項目和特性。 團隊擁有故事和任務，並對執行方式擁有自主權。
在此範例中，管理層不會告訴小組如何分解劇本、規劃短期衝刺或執行工作。
然而，團隊必須確保其執行與管理層的目標保持一致。 雖然團隊擁有其待辦專案劇本，但他們必須將待辦專案與指派給他們的功能保持一致。
Planning
若要擴展敏捷式規劃，團隊需要針對分層架構的每個層級制定計劃。 但是，迭代和更新計劃很重要。 這個過程稱為滾動波規劃。
該計劃在固定時期內提供指導，並按預期定期進行校準。 例如，18 個月的計劃可以每六個月校準一次。
以下是分類法每個層級的規劃方法範例：史詩、功能、劇本、任務。
視覺
願景通過史詩表達，並設定組織的長期方向。 史詩定義了組織想要在未來 18 個月內完成的內容。 管理層擁有該計劃並每六個月對其進行一次校準。
該願景是在全體會議上提出的。 由於願景是雄心勃勃的，並且在這段時間內可能會發生很多變化，因此預計將實現大約 60% 的願景。
季
賽季通過其特徵進行描述，並設定未來六個月的策略。 功能決定了組織想要為其客戶點亮什麼。 管理層擁有季節性計劃，並在全體會議上提出願景和季節性計劃。 所有團隊計劃都必須與管理層的季節性計劃保持一致。 預計完成季節性計劃的約 80%。
3 個衝刺計劃
3 個衝刺計劃定義了團隊將在接下來的三個衝刺中完成的故事和功能。 團隊擁有該計劃並在每個衝刺中對其進行校準。 每個團隊都通過功能聊天向管理層展示他們的計劃（見下文）。 該計劃指定了團隊的執行如何與 6 個月的季節性計劃保持一致。 預計完成 3 次衝刺計劃的約 90%。
衝刺計劃
短期衝刺計劃會定義小組將在下一個短期衝刺中完成的故事和功能。 團隊擁有衝刺計劃，並將其透過電子郵件傳送給整個組織，以實現完全透明。 該計劃包括團隊在過去衝刺中完成的成就以及他們對下一個衝刺的關注。 預計完成衝刺計劃的大約 95%。
自主性界線
在此範例中，繪製自主權線以顯示團隊在何處具有規劃自主權。
如上所述，管理層不會將所有權擴展到自治線以下。 管理層使用願景和賽季計劃提供指導，然後賦予團隊創建 3 個衝刺計劃和衝刺計劃的自主權。
特色對話：當自主性邂逅一致性
特性會議是一個低儀式會議，每個團隊都會向管理層展示他們的三次衝刺計劃。 此會議可確保團隊計劃與組織目標保持一致。 它還可以幫助管理層隨時了解團隊正在做什麼。 雖然 3 個衝刺計劃在每個衝刺中進行校準，但功能聊天會根據需要舉行，通常每隔一到三個衝刺。
功能聊天會議會為每個團隊分配 15 分鐘。 有 12 個特色團隊參與的會議可以安排持續約三個小時。 每個團隊準備一個 3 張幻燈片，其中包含以下幻燈片：
Features
第一張投影片概述了團隊將在接下來的三個迭代中展示的功能。
債
下一張投影片描述了團隊如何管理技術債務。 債務是指任何不符合管理層質量標準的東西。 工程總監設定品質標準，所有團隊都相同（一致性）。 品質列範例包括每位工程師的錯誤數目、單元測試通過的百分比，以及效能目標。
問題和相依性
最後一張投影片中列出的問題和相依性包括影響團隊進度的任何因素，例如團隊無法解決的問題，或需要提交給其他團隊並進行升級處理的相依性。
每個團隊都直接向管理層展示他們的幻燈片。 該團隊展示了他們的 3 衝刺計劃如何與 6 個月的季節性計劃保持一致。 領導層提出澄清問題並建議改變方向。 他們還可以要求後續會議以解決更深層的問題。
如果團隊的計劃不符合管理層的期望，管理層可能會要求重新規劃。 在這種罕見情況下，團隊將重新規劃並安排第二次功能會談以進行審查。
信任：將一致性和自主性結合在一起的黏合劑
大規模實踐敏捷時，信任是一條雙向路：
管理層必須相信團隊會做正確的事情。 如果管理層不信任團隊，他們就不會給予團隊自主權。
團隊透過持續提供高品質的程式碼來贏得信任。 如果團隊不值得信任，管理層就不會給他們自主權。
管理層必須為團隊提供明確的計劃，以便與之保持一致，然後信任他們的團隊來執行。 團隊必須使他們的計劃與組織保持一致，並以值得信賴的方式執行。
當組織希望將敏捷擴展到更大的場景時，關鍵是賦予團隊自主權，同時確保他們與組織目標保持一致。 關鍵的組成部分是明確定義的所有權和信任文化。 一旦組織有了這個基礎，他們就會發現敏捷可以很好地擴展。
後續步驟
今天，任何規模的團隊都可以通過多種方式開始看到好處。 查看其中一些 可擴展的實踐。
了解 Azure DevOps 功能，支持組合管理並提升跨團隊的可見性。
Microsoft 是世界上最大的敏捷公司之一。 深入瞭解 Microsoft 如何調整 DevOps 規劃。