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 可以在其他框架之上使用以进一步扩展。
| 如果您的组织： |
|---|
|
谨慎选择并缓慢扩展
扩展敏捷团队并无缝集成他们的工作很困难，但通过选择最佳框架可以变得更容易。 使用下面的流程图作为指导您的决策过程的第一步。
我相信您会在此处介绍的内容中找到适合您组织的经验、方法、预算和产品的扩展框架。 无论您选择哪种框架，都不要急于求成——逐步扩展以最大限度地减少中断并提前计划变更。
您是否在任何扩展活动中使用过这些框架？ 在评论部分告诉我们您的经历。