项目管理蓝图第 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）和“设计思维”。