項目管理藍圖第 2 部分：Waterfall、DAD、SAFe、LeSS 和 Scrum@Scale 的綜合比較

概述

在項目管理藍圖的第 1 部分中，我們介紹了精益軟件開發、敏捷、Scrum 和看板軟件開發方法，以及它們如何追溯到精益製造。 這些方法通常部署在單個團隊級別。 然而，隨著項目和項目團隊變得越來越大，複雜性也在增加，並且需要新的方法來實現大規模敏捷。

在第 2 部分中，我們將首先深入探討項目經理如何使用瀑布方法，這是傳統公司最常見的軟件開發框架。 與此並列的是，我們將介紹最流行的試圖大規模整合敏捷原則的框架——有紀律的敏捷交付 (DAD)、規模化敏捷框架 (SAFe)、大規模 Scrum (LeSS) 和 Scrum@Scale。

瀑布

瀑布方法（也稱為軟件開發生命週期模型 (SDLC)）是一種更傳統的方法，其中軟件開發像瀑布一樣從一個階段級聯到下一個階段。 這些階段不重疊，並且具有從一個階段移動到下一階段的特定進入和退出標準。

原始瀑布模型的六個生命週期階段是：

1. 需求：在這個階段，項目的期望和目標被定義，需求被廣泛地分析和記錄，通常由業務分析師進行。 在退出此階段之前，對要求進行審查和批准。
2. 設計：在要求獲得批准後，開始設計和設計產品以滿足批准的要求。 物理架構、組件架構、數據庫設計、詳細組件、模塊設計和設計的其他方面由軟件架構師或設計師記錄。 然後在開始實施之前對其進行審查和批准。
3. 實施：設計被批准後，由軟件開發人員根據要求和設計對軟件進行實施或編碼。
4. 驗證：實施完成後，軟件由測試或 QA 團隊進行測試，以確保滿足要求和設計並達到預期的質量水平。 發現、記錄、分類缺陷，在許多情況下，還可以修復缺陷。
5. 發布和維護：測試和調試完成後，將產品發佈到客戶端並安裝。 通常，會進行一輪測試以確保安裝成功。 產品交付後，將進行持續的維護和支持，以確保產品繼續按設計工作。

瀑布的優勢

瀑布有一些優點，它適用於某些類型的項目，但也有一些嚴重的缺點。 Waterfall 最適合要求、技術得到充分理解並且不太可能發生任何重大變化的較短項目。

如果應用於正確的項目類型，瀑布模型的一些優點：

• 簡單性：瀑布很容易實現，因為預先確定了範圍，並且由於剛性階段以及從一個階段到下一個階段的清晰過渡。
• 可見性：利益相關者更容易衡量和看到進度，因為提前了解工作的全部範圍以及項目從一個階段過渡到下一個階段。
• 文檔：範圍、要求和計劃可以被徹底考慮並有據可查，這使得經驗不足的團隊更容易處理項目。
• 階段性工作：由於角色的剛性和階段之間的轉換，項目資源可能會在其主要階段未進行時用於其他項目。

瀑布的缺點

Waterfall 不適用於那些需求沒有被很好理解和/或可能發生變化和/或存在重大技術風險的較長項目。 在當今市場條件不斷變化且上市時間至關重要的時代，這適用於大多數軟件項目。

瀑布模型的缺點主要集中在它無法適應變化，包括：

• 單一範圍：它獎勵利益相關者在定義項目範圍時考慮一切，從而形成單一範圍。
• 遲到的客戶反饋：利益相關者，尤其是客戶很難想像項目的全部詳細範圍。 由於瀑布主要在項目的最後階段向客戶展示項目結果，因此不可避免地將客戶反饋納入項目中
• 需求變化：在較長的項目中，市場條件以及項目目標和需求在項目期間處於非常高的變化風險中。
• 最終創造的價值：瀑布式需要大量的前期工作，這意味著直到項目後期才產生價值。
• 階段相互依賴性：合併變更通常會導致需求和/或設計返工，這可能會影響項目的其他領域。 後期階段對早期階段的依賴會使項目中的小改動變得異常具有挑戰性。

有紀律的敏捷交付 (DAD)

有紀律的敏捷交付 (DAD) 由 IBM 的 Scott Ambler 和 Mark Lines 正式提出，並擴展了敏捷和 scrum 框架，認識到組織的非敏捷部分通常參與交付軟件項目的某些能力。 該框架明確地將 IT 運營、企業架構、投資組合管理、財務和採購等活動納入整個交付生命週期。 DAD 旨在以務實的方式提高整體業務敏捷性。

主要原理和組成部分

角色

DAD 的角色比 scrum 多得多，並且分為兩類團隊角色。 主要角色由經常參與該項目的人員擔任。 次要角色通常是臨時引入的，以幫助團隊解決擴展或其他問題。 DAD 具有這些額外的角色，因為它解決了整個解決方案交付生命週期，並且因為它識別了現實世界中所需的各種類型的臨時和支持角色

主要角色：

1. 利益相關者：依賴於您的團隊完成項目的人：客戶、最終用戶或內部同事。
2. 團隊成員：團隊中實際執行計劃工作的人員：開發人員、設計人員、測試人員等。
3. 團隊負責人：類似於 Scrum Master，團隊負責人通過消除障礙、促進團隊凝聚力和傳播敏捷價值觀來充當團隊的僕人式領導者。
4. 產品負責人：有時被稱為“客戶的聲音”。 產品負責人代表利益相關者並維護需要完成的工作的優先列表。
5. 架構所有者：負責大規模降低架構風險。 此角色通常由團隊中的高級開發人員擔任，因為它需要深厚的技術背景和紮實的業務領域知識。

次要角色：

1. 專家：臨時加入團隊以提供專業幫助的人。 例如，數據分析師可能會加入以在項目的早期階段提供研究能力。
2. 領域專家：稅務顧問、法律顧問和其他具有領域專業知識並幫助團隊應對相關挑戰的人。
3. 技術專家：數據庫管理員、安全專家構建大師等。這些人在生命週期的關鍵點幫助更通用的團隊成員。
4. 獨立測試人員：雖然測試人員通常是主要團隊的一部分，但在某些情況下，生命監管要求或非常複雜的系統，獨立測試人員並行工作以驗證交付工作。
5. 集成商：在規模上，不同的團隊正在處理整個系統的不同部分。 集成商幫助團隊將他們的部分與整個系統集成並管理依賴關係。

生命週期支持

DAD 促進了完整的交付生命週期，不僅包括敏捷/scrum 涵蓋的編程和發布部分，還包括定義和批准項目願景的初始階段以及發布後的支持和退休階段。 目前，DAD 支持 6 種不同的生命週期：

• 敏捷生命週期：基於 Scrum 的項目生命週期
• 精益生命週期：基於看板的項目生命週期
• 持續交付：敏捷生命週期
• 持續交付：精益生命週期
• 探索性（精益創業）生命週期
• 團隊團隊的程序生命週期

這些生命週期說明了不同的工作方式、公司敏捷性水平以及團隊可能會遇到的其他情況。重點是這些生命週期充當了建議。 DAD 提倡實用主義而不是純粹主義，因為每種情況都是獨特的，並且有紀律的敏捷從業者應該採用敏捷過程來滿足他們的需求。

過程目標

DAD 使用目標驅動的方法來創建和調整敏捷流程。 該方法的作者概述了大多數團隊在其生命週期中將面臨的 21 個最重要和最常見的過程。

所有這些流程都記錄了決策點，需要團隊決定如何構建該流程。 每個決策點都提供了可用於實施決策的建議技術或實踐。 您可以在下圖中看到一個示例。 “發展共同願景”的流程有 6 個需要做出的決定。 這些決定中的每一個都有 2 到 5 個建議的做法。 箭頭表示 DAD 作者已對列表進行排序，頂部的項目是最佳實踐，底部的項目是該列表中最差的實踐。 _ 加粗斜體 _文本表示新團隊的良好起點，他們剛剛開始使用 DAD。

DAD的縮放

有紀律的敏捷交付方法從兩個不同的角度擴展：

• 大規模的戰術敏捷性

• 大規模的戰略敏捷性

戰術敏捷性試圖通過過程目標的情境應用及其建議的實踐來解決單個團隊的縮放因素，例如規模、地理分佈、項目複雜性等。

戰略敏捷性試圖通過在整個組織中廣泛應用敏捷和精益戰略來解決擴展問題，方法是擴展框架以解決組織的不同領域：

• 有紀律的 DevOps：涵蓋使用 DevOps 為組織提供更有效的結果。

• 紀律嚴明的敏捷 IT (DAIT)：涵蓋如何將敏捷和精益策略應用於 IT 的各個方面。

• 紀律嚴明的敏捷企業：。 涵蓋如何在整個企業中應用精益和敏捷。

安全的

Scaled Agile Framework (SAFe) 是目前最流行，也是最複雜、最全面的規模化敏捷框架。 年度敏捷狀態報告中 29% 的受訪者聲稱他們在其組織中使用此框架。 反過來，市場上有許多 SAFe 項目經理。

SAFe 的起源是 Dean Leffingwell 於 2007 年出版的《擴展軟件敏捷性：大型企業的最佳實踐》一書。Leffingwell 現在是 SAFe 的首席方法學家，但許多其他人也為這個框架做出了貢獻。 目前，在 4.6 版中，該框架類似於具有版本控制、向後兼容性和各種組件的軟件產品。

主要原理和組成部分

SAFe 的主要目標是促進精益企業的創建和發展，因為它認識到許多不同類型的公司在某種程度上是需要在最短、可持續的時間內持續交付價值的軟件公司。

SAFe for Lean Enterprises 試圖通過提供經過驗證的原則、能力和最佳實踐的知識庫來創建精益企業。

SAFe 4.6 定義了精益企業的五項核心能力。 每項能力都是一組相關的知識、技能和行為，它們共同使組織能夠脫穎而出：

1. 精益敏捷領導：描述領導者如何通過學習、教學和實施 SAFe 的精益敏捷思維來推動和維持組織變革。

2. 團隊和技術敏捷性：描述創建高績效敏捷團隊所需的技能、原則和實踐。

3. DevOps 和按需發布：描述實施 DevOps 和持續交付管道如何為組織提供在任何必要的時間發布產品增量以滿足需求的能力。

4. 業務解決方案和精益系統工程：描述如何將精益敏捷原則和實踐應用於大型複雜軟件應用程序的規範、開發、部署和演進

5. 精益投資組合管理：通過將精益和系統思維方法應用於戰略和投資資金、敏捷的投資組合運營和治理，使戰略和執行保持一致。

除了包含整個流程的精益-敏捷領導力之外，每個核心能力都直接映射到 SAFe 流程圖中的各自級別。

精益敏捷領導能力

精益敏捷領導能力的主要目標是幫助將組織轉變為精益敏捷企業。 這是通過學習、實踐和教授 SAFe 的精益敏捷思維、價值觀、原則和實踐來完成的。

SAFe 的核心價值觀指導向精益企業的轉型。 在每一個機會中，領導者的行為都對提升他們起到了至關重要的作用。 核心價值觀是：

1. 對齊：傳達使命、投資組合戰略和解決方案願景。 進行相關簡報，並參與計劃增量（PI）計劃和積壓維護。

2. 透明度：可視化所有相關工作。

3. 內在質量：參與實踐以在整個生命週期中提供質量。 拒絕接受低質量的工作。 支持在維護和減少技術債務方面的投資。

4. 程序執行：作為企業主參與PI執行並建立業務價值。 確保範圍與需求和容量保持一致。 積極消除障礙和消極因素。

SAFe 核心價值觀通過採用精益敏捷思維和應用 SAFe 原則得到支持：

1. 採取經濟觀點

2. 應用系統思維

3. 假設可變性； 保留選項

4. 通過快速、集成的學習週期逐步構建

5. 基於對工作系統的客觀評估的里程碑

6. 可視化和限制 WIP、減少批次大小和管理隊列長度

7. 應用節奏，與跨域規劃同步

8. 釋放知識工作者的內在動力

9. 分散決策

這些原則類似於精益和敏捷原則。 最後，通過遵循 SAFe 實施路線圖來完成組織轉型。

團隊和技術敏捷能力/團隊水平

團隊和技術敏捷性能力描述了創建高質量解決方案的高性能敏捷團隊所需的技能、原則和實踐。 兩個關鍵特性至關重要：

• 團隊敏捷性：團隊採用敏捷實踐和原則，使他們能夠以可靠的節奏工作、學習和適應

• 技術敏捷性：團隊應用敏捷技術實踐來確保代碼和組件的質量，以及他們生成的代碼的可維護性。質量是團隊和技術敏捷性能力的一個重點。 為了實現這一點，敏捷工程技術如行為驅動開發 (BDD) 和測試驅動開發 (TDD) 被用於提高質量和流程。 快速流取決於整個系統的構建質量，因為錯誤會嚴重影響流和延遲發布。

  

SAFe 圖的團隊級別描述了各個敏捷團隊如何運作。 所有團隊都是敏捷發布火車的一部分，致力於交付產品增量。 大多數傳統的敏捷/Scrum 流程都適用，團隊在迭代中工作以交付工作系統。 在 SAFe 中使用 scrum master、產品負責人和團隊成員的角色，就像大多數 scrum 活動和工件一樣。 團隊還受到項目級別角色的支持，例如產品管理、系統架構師和其他共享服務。 看板用於通過交付生命週期以及團隊之間的交互和移交來幫助可視化功能流。

DevOps 和按需發布能力/程序級別

DevOps 和按需發布能力描述了“實施 DevOps 和持續交付管道如何為企業提供在任何必要的時間釋放全部或部分價值以滿足市場和客戶需求的能力”。

DevOps 致力於協調開發、運營、業務和其他領域，以共同交付業務成果。 雖然並非每個組織都需要像 DevOps 運動的某些行業領導者那樣頻繁地發布（亞馬遜每隔幾秒發布一次），但所有組織都需要能夠按需發布。

• DevOps 提供了文化、自動化、精益流程、測量和恢復 (CALMR) 方法，可實現持續交付和按需發布

• 敏捷發布火車 (ART) 是由敏捷團隊組成的團隊，它們被組織起來通過持續交付管道按需交付價值

該圖的程序級別描述了通過敏捷發布火車 (ART)持續交付所需的角色和活動。 此級別以與團隊級別類似的迭代方式工作，但集成了多個敏捷團隊並包含更多周期。 ART 是一個敏捷團隊，由 5 到 12 個團隊（50 到 125 人）組成，包括傳統的敏捷角色以及發布培訓工程師 (RTE)和產品管理等關鍵項目角色。 ART 以 8-12 週的計劃增量 (PI)交付，這些增量是通過PI Planning 計劃並由產品經理領導的。

通過程序看板板跟踪和管理 PI 功能、史詩等的進度。 RTE 充當 ART 上的 Scrum Master。 每日同步會議包括團隊每日站立會議、Scrum-of-Scrums（RTE 和 Scrum Masters）、PO Sync（產品管理和產品負責人）和 ART Sync（Scrum-of-Scrums 和 PO 同步）。 每個 PI 都有系統演示和回顧。

業務解決方案和精益系統工程能力/大型解決方案級別

業務解決方案和精益系統工程能力描述了“如何將精益敏捷原則和實踐應用於大型複雜軟件應用程序和網絡物理系統的規範、開發、部署和演變”。

除了 SAFe 原則之外，在處理大型解決方案時應用以下 8 項原則是此能力的關鍵：

大型解決方案級別包含構建大型複雜解決方案所需的角色、工件和流程。 多個 ART 正在合作開發解決方案系列以提供解決方案。 主要目標是：

• 管理頻繁的集成

• 持續解決合規問題

• 規模、模塊化、可發布性和可服務性的架構師

解決方案管理控制解決方案的內容，解決方案培訓工程師 (STE)指導工作。 解決方案架構師負責為解決方案中的所有 ART 維護良好的架構。 前期和後期 PI 計劃用於計劃通過多個計劃增量交付的解決方案。 解決方案積壓包含功能和解決方案史詩，並通過解決方案看板板進行跟踪

投資組合水平/精益投資組合管理能力

精益投資組合管理能力“通過將精益和系統思維方法應用於戰略和投資資金、敏捷的投資組合運營和治理，使戰略和執行保持一致。”

精益投資組合管理側重於以下領域：

1. 戰略和投資融資：將投資組合與企業戰略聯繫起來，為價值流提供資金，並建立投資組合流

2. 敏捷的投資組合運營：協調價值流、支持項目執行和卓越運營

3. 精益治理：預測預算、衡量投資組合績效並強制合規

投資組合級別包含啟動和管理一組開發價值流所需的原則、實踐和角色。 Portfolio Backlog包含Business Epics和Enabler Epics ，並通過Portfolio Kanban* 板進行跟踪。 **精益投資組合管理 (LPM)決定投資組合中的價值流，並包括企業中的最高決策者。 企業架構師指導整個價值流的工作和協調。

較少的

大規模 Scrum (LeSS) 框架由 Craig Larman 和 Bas Vodde 創建，他們基於他們在金融和電信行業的經驗。 顧名思義，LeSS 提倡盡可能少的流程和程序，以便讓多個 Scrum 團隊一起工作。 擴展很難，因為人們讓它變得複雜，所以這裡的目標是讓它盡可能簡單。

主要原理和組成部分

“LeSS 是 Scrum，應用於許多團隊，一起工作，開發一個產品”。 LeSS 基於十個原則，任何熟悉精益-敏捷原則的人都會覺得它們很熟悉：

1. 大規模 Scrum 就是 Scrum

2. 經驗過程控制

3. 透明度

4. 事半功倍

5. 專注於整體產品

6. 以顧客為中心

7. 持續改進，追求完美

8. 系統思維

9. 精益思維

10. 排隊論

LeSS 只有兩個主要角色，都是從 Scrum 借來的：

1. 產品負責人：與 2-8 個團隊合作。
2. Scrum master：與 1-3 個團隊一起工作。

所有團隊在 1-4 週的衝刺中使用相同的產品積壓工作。 團隊並行工作，這意味著他們同時開始和結束衝刺。 在衝刺結束時，團隊集體交付產品增量。 一個產品負責人似乎幾乎不可能與 8 個團隊一起工作。 LeSS 提倡將產品 backlog 項目澄清的責任轉移給團隊。 反過來，團隊必須是跨職能的，不僅包含編碼、設計和測試能力，還包含業務領域知識。 更重要的是，團隊必須有權接觸客戶。

衝刺計劃

規劃分為兩部分：

1. Sprint 計劃 1：團隊代表與產品負責人會面並決定他們將承擔哪些待辦事項，並討論在 sprint 期間團隊之間可能需要的任何潛在合作。
2. Sprint 計劃 2：與傳統的 scrum 相同，每個團隊單獨聚集，為如何完成積壓項目制定計劃。

產品待辦列表細化

產品待辦事項細化 (PBR) 在 sprint 期間完成，以便為 sprint 計劃準備產品待辦事項項目。 LeSS 沒有提供如何進行 PBR 的規則，而是讓公司自己找出最有效的流程。 PBR 涉及三個關鍵活動：

1. 拆分大項目。
2. 細化項目，直到準備好。
3. 估計。

衝刺結束

在每個 sprint 結束時會發生三件事：

1. Sprint Review：一個共享的 Sprint 演示，團隊和客戶在其中探索 Sprint 期間完成了什麼以及接下來應該做什麼。
2. 回顧：每個團隊都有自己的回顧以改進他們的流程。
3. 整體回顧：團隊、產品負責人和 Scrum Master 齊聚一堂，檢查和調整組織實踐以提高效率。

Scrum@Scale

Scrum at Scale 和 Scrum@Scale 可以互換使用。 該方法由 Jeff Sutherland 於 2014 年引入，他創建了 Scrum 方法，並且是敏捷宣言的簽署者之一。

Scrum@Scale 以 Scrum 為出發點，並提供了一個簡單、輕量級的框架，以“最小可行的官僚機構”來擴展 Scrum。 它不像其他規模化的敏捷方法那樣具有規定性，可以被視為一個元框架。 它強調了擴展問題和領域，並為如何解決這些問題提供了一個思維框架。

主要原理和組成部分

Scrum@Scale 是一個框架，它通過使用 Scrum 來擴展 Scrum，從根本上簡化了擴展。 在 Scrum 中，“什麼”（產品負責人）與“如何”（scrum master）明顯分開。 Scrum@Scale 中使用了相同的策略，以便更好地理解管轄權和問責制，消除浪費和衝突。

Scrum@Scale 包含兩個循環以明確區分管轄範圍： Scrum Master 循環和產品負責人循環，其中包含兩個接觸點：團隊級流程和產品發布反饋。

Scrum Master 週期

Scrum master 週期負責產品所有者周期確定的事物將如何構建。 在 Scrum@Scale 中，各個 Scrum 團隊擁有與傳統 Scrum 相同的角色、工件、活動和儀式。

Scrum 團隊被分組為Scrum of Scrums (SoS) ，共同負責生產聯合產品增量。 他們參與聯合待辦事項梳理和優先級排序，舉行回顧會議，維護障礙積壓工作，並舉行規模化每日 Scrum (SDS) （格式類似於每日 Scrum）以協調團隊並消除障礙。 SDS 由每個參與團隊的至少一名代表（通常是團隊的 Scrum Master）參加，並由負責與 Scrum 團隊和產品負責人協調的Scrum of Scrums master (SoSM)領導。

如果需要進一步擴展，則有一個由多個 SoS 創建的 Scrum of scrums (SoSoS) ，這些 SoS 也將每天開會，依此類推。 總體領導者是執行行動團隊（EAT） ，負責在組織中推廣敏捷，根據需要協調 Scrum 團隊，並作為消除障礙的最後一站。

產品所有者周期

產品所有者周期負責將創建什麼產品或服務以及支持它所需的所有活動。 產品負責人被分配到 Scrum 團隊，並按照 Scrum 中的定義執行其角色的所有活動。 產品負責人被分組到映射到 SoS 團隊的產品負責人團隊中。 產品負責人團隊每天在Meta Scrum上開會，討論團隊的高級戰略，並根據需要與相應的 SoSM 和其他產品負責人和利益相關者進行協調。元 Scrums 由首席產品負責人 (CPO)領導。

產品負責人以與 Scrum Master 週期類似的方式進行擴展，具體取決於組織的規模，並最終形成一個負責全公司優先級設置的執行元 Scrum (EMT) 。

實施 Scrum@Scale

Scrum@Scale 的實施始於創建一個可擴展的參考模型，即一小部分團隊在小範圍內使用 Scrum。 這樣做是為了解決阻礙敏捷的任何組織策略和開發實踐。 Scrum@Scale 建議儘早解決這些問題，因為所有團隊都可能面臨這些組織範圍內的問題，而隨之而來的挫折可能會阻礙敏捷的採用。 然後將參考模型用作將 scrum 擴展到其他團隊和部門的模式。

必須首先創建執行行動團隊 (EAT) 以實施參考模型。 EAT 由在組織內具有政治和經濟權力的個人組成，因為他們將能夠實施組織政策的變化。

結論

在項目管理藍圖的第二部分中，我們介紹了一些用於大型項目或程序的最流行的框架。 瀑布仍然在許多組織中廣泛使用，雖然由於其流程不靈活而具有許多缺點，但有時在項目較小且範圍明確且不太可能更改時使用此框架是有意義的。

隨著公司遇到需求或目標不斷變化的更大、更複雜的項目，他們尋求更敏捷的方法。 由於敏捷最初是為 5-9 人的小型團隊設計的，因此各種敏捷實踐者已經提供了多種方法來將敏捷從單個團隊擴展到多個團隊，再到整個企業。 在本文中，我們介紹了有紀律的敏捷交付 (DAD)、規模化敏捷框架 (SAFe)、大規模 Scrum (LeSS) 和 Scrum@Scale。

在項目管理藍圖的最後一部分，我們將介紹一些項目管理特定框架，如 PMP (PMBOK) 和 PRINCE2。 我們還將介紹一些創新流程和框架，例如“待完成的工作”（JTBD）和“設計思維”。