5 個敏捷擴展框架比較：您應該使用哪一個？
已發表: 2022-08-18想像一下：在項目開始時，您組建了一個致力於實現產品目標的單一、有效、跨職能的團隊。 為了提高績效，您需要確保團隊精通敏捷。 對產品的需求增長，需求增加並擴大積壓。 您和其他利益相關者意識到團隊需要擴展。 聽起來有點熟？
擴展允許多個團隊一起工作以保持他們的敏捷性。 如果要完成的工作超出了您的團隊在合理時間內所能處理的範圍，那麼是時候擴大規模了。 但是，為了做到這一點，您需要選擇正確的框架，並且有幾個可供選擇。 選擇不當，實施可能會失敗，從而破壞生產力並導致重大的財務影響。
最適合您的團隊的框架會有所不同，具體取決於可用資金、組織方法和產品複雜性等因素。
什麼時候應該擴展？
在考慮擴展之前，需要滿足許多關鍵標準：
你能只用一個團隊來管理開發嗎？
實施規模化的敏捷框架可能既複雜又耗時，所以如果不需要，就不要規模化。 當您的團隊的工作量超過其能力時，擴展是必要的。
你的團隊敏捷嗎？
也許最重要的標準是您的團隊對敏捷方法的熟練程度。 如果您的團隊沒有敏捷方面的經驗，那麼擴展會產生更多問題。
您的團隊的開發實踐需要改進嗎？
如果您的團隊的工程實踐效率不高，則擴展可能不會產生預期的結果。 正確實施 DevOps 和 CI/CD 管道等實踐對於跨團隊的一致性至關重要。 此外，如果沒有標準化的質量保證，可能很難測試新功能。
您的團隊是否提供集成增量？
擴展涉及集成多個團隊在同一個產品上進行協作，每個團隊都產生可以協同工作的功能。 下表詳細介紹了團隊和產品的四種可能配置。 請注意，只有一個需要縮放。
| 團隊數量 | 產品數量 | 設想 |
|---|---|---|
| 1 | 1 | 一個團隊管理單個產品的開發。 無需縮放。 |
| 1 | 超過 1 個 | 一個團隊處理多個產品，因此項目經理可以創建一個產品隊列並逐個開發它們，也可以建立多個團隊，每個團隊都在一個單獨的產品上工作。 無需縮放。 |
| 超過 1 個 | 超過 1 個 | 產品數量等於團隊數量。 無需縮放。 |
| 超過 1 個 | 1 | 多個團隊一起工作以提供大型產品解決方案——這是項目經理應該實施規模化敏捷框架的配置。 |
選擇擴展框架
有許多敏捷擴展框架可供選擇，但我們將重點介紹五個最廣泛使用的解決方案：Scaled Agile Framework (SAFe)、Nexus、Large-Scale Scrum (LeSS)、Scrum@Scale 和 Disciplined Agile (DA) . 我發現這些是最有效的框架，它們可以應用於一系列場景和組織。 以下部分將為您提供為您的獨特擴展環境做出最佳選擇所需的信息。
1. 規模化敏捷框架（SAFe）
SAFe 是最流行的敏捷擴展框架。 2021 年的一項調查發現，37% 的敏捷從業者使用它，主要是由於它的多種配置，所有這些配置都專注於價值流並具有明確定義的指南和程序。
由於 SAFe 用於交付需要 50 多人的複雜解決方案，因此它將團隊組織成敏捷發布火車 (ART)。 為了在 ART 中同步團隊，SAFe 使用程序增量迭代——類似於 Scrum 衝刺——每次迭代通常持續 8 到 12 週。 這種方法使產品經理能夠專注於總體目標並有效地監督複雜的產品路線圖，而不會引入過多的更改。
SAFe 基於 Scrum 框架，但有幾個關鍵區別： SAFe 的採用發生在企業級別而不是團隊級別； 雖然 Scrum 賦予產品所有者對優先級的唯一授權，但 SAFe 鼓勵採用更民主的方法。
SAFe 有四個實現級別：
基本安全
Essential SAFe 是 SAFe 的基礎，必須在繼續任何後續配置之前掌握。 它利用既定的 Scrum 角色，如 Scrum 主管、產品經理和產品負責人，還引入了一個新角色：發布培訓工程師。 此人充當僕人式領導者和 ART 教練，指導團隊調整目標。 ART 中可以有 5 到 12 個團隊，每個 ART 都能夠提供完整的解決方案。
大型解決方案
此配置位於 Essential SAFe 之上，並引入了一個名為“解決方案系列”的概念。 它用於構建需要協調多個 ART（可能有數百甚至數千人）在同一價值流上工作的大型複雜解決方案。 例如，如果您在 Microsoft 工作並擁有三個獨立的團隊來編寫 Excel、Word 和 PowerPoint，那麼他們都在為同一個價值流做出貢獻：Microsoft Office。
文件夾
投資組合由多個針對不同價值流的 ART 組成。 繼續微軟的例子：獨立的團隊開發公司的 Office、Skype 或 Xbox 產品。
完全安全
此配置結合了所有層——基本、大型解決方案和組合——以協調企業範圍的團隊管理。
| 如果您的組織： |
|---|
|
2. 連結
Nexus 框架也基於 Scrum，但比 SAFe 更輕量級，只需進行小的調整即可促進三到九個團隊之間的協作。 實施 Nexus 不需要任何額外的角色。 相反，每個團隊的一名代表加入一個中央集成團隊，將工作與單一目標保持一致。 與 Scrum 類似，所有團隊聚集在一起進行 sprint 計劃會議，其結果形成共享的產品 backlog。 為了檢查進度，每個團隊都會舉行類似於站立會議的每日會議，集成團隊也會開會報告團隊的進度。
在 sprint 期間，團隊參與細化會議以確定優先級和估計積壓工作。 由於積壓管理的複雜性隨著團隊數量的增加而增加，Nexus 要求進行細化會議。 團隊在每個 sprint 之後召開審查和回顧會議。
| 如果您的組織： |
|---|
|
3. 大規模 Scrum (LeSS)
LeSS 幾乎與 Nexus 相同，但有一些細微差別，例如命名約定和額外的、特定於團隊的 sprint 計劃會議。 它的第二個配置 LeSS Huge 的擴展能力也有所不同，它支持超過 8 個團隊的協作。
LeSS Huge 採用以客戶為中心的方法來組織開發。 為了有效地管理工作，它需要產品負責人將高級產品待辦事項拆分為更細化的項目的較小“區域待辦事項”，然後將它們進一步分類 - 進入需求區域。
這些需求區域由區域產品所有者 (APO) 管理。 APO 專注於與每個領域相關的領域，並與多個團隊合作為他們的領域提供解決方案。 存儲在 backlog 中的每個需求只屬於一個需求區域，每個區域僅由一個 APO 管理。 產品負責人和 APO 共同組成一個團隊，負責從產品範圍的角度確定優先級。
| 如果您的組織： |
|---|
|
4. Scrum@Scale
Scrum@Scale 是 Scrum 的擴展，可能是最容易學習和理解的框架。 它從一個團隊擴展到一組團隊。
該框架的核心組件是 Scrum of Scrums (SoS)。 每個團隊選擇一個人來代表他們參加 SoS 會議，這通常在每天的個人團隊站立會議之後舉行。 每天的 SoS 會議的目的是幫助團隊之間的協調和溝通，並促進輕鬆管理任何依賴關係或重疊。
該框架內的獨特角色包括 SoS 主管，本質上是 Scrum 主管的擴展版本，以及首席產品負責人，他與團隊產品負責人一起為 SoS 形成聯合積壓工作。
Scrum@Scale 不像其他框架那樣規範，允許組織按照自己的步調進行擴展。 如果團隊數量繼續增長並且 SoS 會議變得太大，組織可以將框架升級為 Scrum of Scrums (SoSoS)。
| 如果您的組織： |
|---|
|
5.紀律敏捷（DA）
DA 與其他框架的不同之處在於，它更像是一個工具箱，您可以從中選擇最合適的擴展策略，而不是一個必須遵守規則的僵化框架。 它是各種框架的上下文驅動的混合體，包括 Scrum 和看板，可以根據每個項目的需求進行定制，以“選擇是好的”原則為中心。 DA 的理念是，每個團隊和組織在規模、分佈和領域上都是獨一無二的，每個團隊成員也都是獨一無二的，擁有自己的技能和經驗。
它可以在軟件開發團隊級別或企業範圍內應用。 對於後者，DA 工具包確定了各種業務功能（例如財務、IT 運營和供應商管理）應該解決的問題，並提供了一系列選項。
DA 區分了三個項目階段——啟動、構建和過渡——每個階段都包含面向交付的過程目標。 因為這個框架專注於完整的交付生命週期，而不僅僅是構建，所以它引入了比其他框架更多的角色。 每個 DA 團隊的主要角色是利益相關者、團隊成員、團隊負責人、產品所有者和架構所有者。 還有五個支持角色，通常在臨時基礎上用於協助擴展：專家、領域專家、技術專家、獨立測試員和集成商。
DA 可以在其他框架之上使用以進一步擴展。
| 如果您的組織： |
|---|
|
謹慎選擇並緩慢擴展
擴展敏捷團隊並無縫集成他們的工作很困難，但通過選擇最佳框架可以變得更容易。 使用下面的流程圖作為指導您的決策過程的第一步。
我相信您會在此處介紹的內容中找到適合您組織的經驗、方法、預算和產品的擴展框架。 無論您選擇哪種框架，都不要急於求成——逐步擴展以最大限度地減少中斷並提前計劃變更。
您是否在任何擴展活動中使用過這些框架？ 在評論部分告訴我們您的經歷。