什么是 Scaled Agile Framework?(SAFe)

了解 Scaled Agile Framework (SAFe) 及其原则,并了解它与其他敏捷开发框架的区别。

Jessica Piikkila 作者:Jessica Piikkila
浏览主题

Scaled Agile Framework®(SAF®)是一套组织和工作流程模式,用于在企业规模上实施敏捷实践。该框架是一种知识体系,包括关于角色和责任、如何规划和管理工作以及要坚持的价值观的结构化指导。

SAFe 促进大量敏捷团队之间的一致性、协作和交付。SAFe 围绕三个主要知识体组成:敏捷软件开发、精益产品开发和系统思维。

随着企业规模的扩大,SAFe 提供了一种结构化的方法来实现敏捷扩展。SAFe 中有四种配置以适应各种规模级别,分别是:Essential SAFe、Large Solution SAFe、Portfolio SAFe 和 Full SAFe。

迪恩·莱芬威尔和德鲁·杰米洛于 2011 年发布 SAFe,目的是帮助组织设计更好的系统和软件,以更好地满足客户不断变化的需求。当时,团队使用传统的项目管理流程来交付软件。但是,随着快速应对不断变化的市场条件的需求增加,出现了新的框架来帮助企业改善整个企业的解决方案交付,SAFe 便诞生了。如今,SAFe 是最受欢迎的扩展敏捷交付框架之一,SAFe 的全球从业者社区也在不断使其发展壮大。

核心原则和价值观

核心价值观

SAFe 的核心价值观描述了领导层需要培养的文化,以及人们应该如何在这种文化中行事才能有效地使用该框架。

一致性

SAFe 要求公司在组织的各个层面上制定规划和反思节奏。有了这些,每个人都可以了解业务的现状、目标以及每个人应该如何共同努力实现这些目标。通过定期同步人员和活动,项目组合的各个层面都保持一致。与传统的自上而下的指挥和控制结构不同,信息会及时向上和向下流动。

内置品质

在 SAFe 框架中,敏捷性绝不能以质量为代价。SAFe 要求各级团队为每个任务或项目定义“完成”的含义,并将质量开发实践融入每份工作协议中。根据 SAFe 的说法,内置质量有五个关键维度:流程、架构和设计质量、代码质量、系统质量和发布质量。

透明度

SAFe 鼓励建立信任的行为,包括小批量方式规划工作,以便问题可以更快浮现,提供跨级别待办事项进度的实时可见性,以及检查和调整仪式

计划执行

计划执行是 SAFe 的核心,为框架中的其他一切提供动力。团队和计划必须能够定期提供高质量、有效的软件和商业价值。

领导力

SAFe 需要精益敏捷的领导行为,因为只有领导者才能改变系统并创造接受所有核心价值观所必需的环境。

SAFe 原则

Scaled Agile Framework 的原则旨在通过激发跨职能和组织界限的精益敏捷决策来改善整个公司。这些原则不仅旨在影响领导者和经理的决策,还影响组织中每个人的决策,并转变他们的思维方式,从传统的瀑布思维变为精益敏捷思维,而精益敏捷思维中则应用了精益投资组合管理等实践。

原则 1:从经济角度来看

受到唐纳德·赖纳森畅销书中关于产品开发的理论的启发,要实现最短的可持续交货时间,决策链中的每个人都必须了解延误的经济影响。提前交付,而且这往往还不够。根据 SAFe 的要求,需要在整个组织中分担的责任包括:对工作排序以获得最大收益、了解经济权衡以及在精简预算内运营等等。许多概念和工具都来自瑞纳特森关于产品开发流程的理论。

原则 2:运用系统思维

SAFe 鼓励该框架的用户将系统思维应用于三个关键领域:解决方案本身、构建系统的企业以及价值流。解决方案可以指交付给客户的产品、服务或系统,无论它们在是企业内部还是外部。

大型解决方案有许多相互关联的部分,因此团队成员应该对他们自己的部分如何适应更大的图景有更高层次的看法。在考虑企业构建系统时,遵循 SAFe 的人员应考虑组织的人员、管理和流程。因此,如果一个组织正在寻求优化人们的工作方式,它可能需要消除孤岛,成为跨职能部门,并与供应商和客户形成新的工作协议。最后,企业应明确界定解决方案开发价值流中的价值如何从概念流向现金。领导者和管理层需要最大限度地实现跨职能和组织界限的价值流。

原则 3:假设可变性;保留选择权

默认情况下,设计系统和软件是一项不确定的工作。该原则通过引入基于集合的设计概念来解决不确定性,这要求在开发周期中保留多个需求和设计选项。基于集合的设计还依赖于经验数据,以在流程中进一步缩小对最终设计选项的关注。

基于集合的设计可以识别选项和预期结果,有助于在不确定时期为决策提供信息,就像战略赌注一样。整合“学习里程碑”的概念是指决策的最后期限,对于基于集合的设计非常有用。随着时间的推移,团队学到的内容越多,他们可以排除的选择就越多。他们排除的选择越多,就越容易确定最佳前进道路,为客户带来尽可能好的结果。

原则 4:通过快速、集成的学习周期逐步构建

与原则 3 类似,该原则通过学习里程碑来解决风险和不确定性。仅仅证明系统的每个组件部分都能正常工作是不够的,必须考虑整个系统来评估当前设计选择的可行性。必须定期规划整合点,以加快学习周期。这些整合点是沃特·阿曼德·休哈特所提出的 “计划-执行-检查-调整循环的一个例子,该周期是持续质量改进的框架和控制开发可变性的机制。休哈特的工作和他启发的工作经常出现在 SAFe 中。

原则 5:将里程碑建立在对工作系统的客观评估的基础上

与需求文档或其他一些肤浅的成功评估相比,实际工作系统的演示为决策制定提供了更好的基础。尽早让利益相关者参与这些可行性决策有助于建立信任和系统思考。

原则 6 可视化和限制进行中的工作(简称 WIP)、减少批量大小并管理队列长度

限制正在进行的工作有助于利益相关者准确了解工作的进展情况。

这样原则的三个要素代表了最大限度地提高吞吐量和加快价值交付的主要方式,换句话说,就是实现“流动”。俗话说“怎么吃掉一头大象?”答案是:一口一口吃”。

当您将其应用于软件开发时,这意味着限制重叠工作的数量、每个工作项的复杂性以及在给定时间处理的工作总量。小批量允许持续验证工作朝着正确的方向发展。还要管理队列长度...

该原则旨在为此优化提供指导以获得最佳结果。

原则 7:应用节奏,与跨域规划同步

敏捷团队通过冲刺或迭代自然地应用节奏。为所有可能的事情创建节奏可以降低复杂性、解决不确定性、增强肌肉记忆、强化质量并灌输协作精神。同步这些节奏使人员和活动能够像车轮上的齿轮一样移动,从中学习到的信息可以为决策和增量计划提供信息。

原则 8 释放知识工作者的内在动力

受有影响力的管理顾问彼得·德鲁克和作家丹尼尔·平克的启发,这是我们的最爱的原则之一!这是关于释放团队的潜力,并帮助领导层以指挥和控制的心态来指导和服务他们的团队。

原则 9:去中心化决策

减少队列长度并通过分散决策采取经济的方法,这些措施为团队提供完成工作所需的自主权。领导者应保留其对具有战略重要性的话题的决策权,并使团队能够在其他所有问题上做出明智的选择。

SAFe 如何运作?

准备好实施 SAFe 的组织通常有高管级别的支持、强烈的变革目的以及扎根于 Scrum 的基础。

Scaled Agile, Inc. 提供了一份 SAFe 实施路线图,其中详细介绍了关如何开始和建立组织以在项目组合中广泛采用。实施 SAFe 的 12 个步骤包括:

  1. 到达临界点
  2. 培训精益敏捷变革代理人
  3. 培训高管、经理和领导者
  4. 创建精益敏捷的卓越中心
  5. 识别价值流和 ART(敏捷发布系列)
  6. 制定实施计划
  7. 为 ART 启动做好准备
  8. 训练团队并启动 ART
  9. 指导 ART 执行
  10. 推出更多 ART 和价值流
  11. 扩展到项目组合
  12. 维持和改进

SAFe 与其他可扩展的敏捷框架相比如何?

尽管 Scaled Agile Framework®(SAFe®)在拥有大型软件开发团队的企业中被广泛采用,但随着时间的推移,其他可扩展敏捷框架也越来越受欢迎。所有用于扩展敏捷的框架都有五个主要组成部分:来自 12 条敏捷宣言原则的灵感、节奏、同步、Scrum 和质量开发实践。了解其他框架的起源、核心差异以及成功应用的条件可以帮助组织选择最适合其需求的框架。

想了解一些顶级规模化敏捷框架的更多背景信息吗?查看敏捷教练上的大规模敏捷性概述页面。

SAFe 与 Scrum@Scale 对比

在 Scrum@Scale (S@S) 中,每个人在 Scrum 团队中都是可互换的。根据他们的目标,Scrum 团队的网络聚集在一起形成一个生态系统。S@S 的目的是通过“无规模架构”创建一个 Scrum 团队网络,这意味着基本的 Scrum 角色和事件是线性扩展的,不会引入新的流程动态。例如,对于拥有 25 个 Scrum 团队的极复杂产品来说,一个集群 Scrum (SoS) 可能还不够,因此可能需要一个带有 Scrum of Scrum of Scrums Master (SoSM) 的 Scrum of Scrum of Scrums (SoSoS)。

尽管 S@S 通常不是那么规范,但它确实提供了一个指导性问题来帮助组织确定他们是否已准备好进行扩展:如果向系统增加更多人员,绩效会成倍增加还是生产力会受到影响?

与 SAFe 类似的是,S@S 确实提供在线参考内容,包括越来越受欢迎的广泛的 Scrum@Scale 指南。

S@S 在以下情况下最行之有效

  • 技术堆栈是面向对象的(即纵向用户故事实际上可以在两周内交付)
  • 组织的特色团队具有 T 型技能、以产品为中心的价值观和最少的官僚主义
  • 在实践还没有成为第二天性时,并不需要敏捷或敏捷生命周期管理 (ALM) 工具
  • 高管团队愿意实践+ Scrum 并为组织消除障碍

SAFe 与大规模 Scrum (LeSS) 的对比

大规模 Scrum (LeSS) 对角色、结构和工件采取了极简主义的方法。SAFe 提供四种配置,以适应规模越来越大、解决方案日益复杂的团队,而 LeSS 则提供两种配置:LeSS 适用于两到八个团队,LeSS Huge 适用于八个以上的团队。LeSS 的立场也有所不同,LeSS 的立场是:产品所有者应该拥有完全的内容权威和战略影响力,而 SAFe 鼓励采取更民主的方法。尽管在 SAFe 中,有许多因素为战略提供了依据,但 LeSS 强调以客户为中心的方法,专注于报偿客户。

与 S@S 类似,LeSS 从 Scrum 事件、工件和角色扩展。SAFe 和 LeSS 都强调系统思维、精益思维和类似的指导原则。然而,LeSS 将重点放在减少整个组织的浪费上,以持续改进为目标。

LeSS 在以下情况下最成功

  • Scrum 团队已经掌握了 Scrum
  • 领导层愿意为更大的利益不断进行重组和实验
  • 对产品的定义有一致性
  • 对“完成”的定义有一致性
  • 外部教练正在与组织、团队和技术小组合作
  • 具有 T 型技能的功能团队与组件团队
  • 该组织愿意彻底摆脱项目管理范式

SAFe 与 DA

与所描述的其他框架不同,规范敏捷开发 (DA) 是一种工具包,可帮助组织决定哪种工作方式最适合他们。它提供植根于 Scrum 和看板的轻量级敏捷治理,以及人力资源和财务、治理、DevOps、项目组合管理等领域的转型知识。DA 涉及在情境中为每个项目使用不同级别的规模,并强调决策赋能,以帮助指导战略方向。

DA 在以下情况下最成功

  • 组织希望定义自己的扩展敏捷路径
  • 组织希望在整个企业中保持灵活性
  • 组织希望保留流程和/或框架选择

SAFe 与 Spot 的对比

Spotify“模型”是一套以人为本的自主实践,可用于协调敏捷团队。这个模型从来没有打算成为一个模型或框架,但已经被一些企业采用。Spotify 强调自组织、跨职能和同地办公的团队,称为"Squad"(相当于 Scrum 团队)。相比之下,SAFe对团队的同地办公没有这样的规定,鼓励进行 PI 规划。

Squad 被组织成更大的单位,称为“Tribe”。Squad 之间的依赖关系很少,如果出现依赖关系,则通过集群 Scrum 进行处理。知识共享是通过“Chapter”和“Guild”实现的,它们是根据技能和兴趣组织的非正式团体。

与提供在线资源、培训课程和认证的其他示例相比,Spotify 模型上的资源仅限于公开可用的博客以及由其先驱者和粉丝开发的其他配套文章。该模型越来越受欢迎,因此将来我们可能会看到更多有关该模型的信息。

Spotify 在以下情况下最成功

  • 在您自己的商业环境中运用这些想法
  • 组织文化的核心是于学习、允许犯错和承担可控风险
  • 团队和产品“松散耦合,密切一致”,以避免依赖冲突

SAFe 5.0

SAFe 的中心宗旨是,与世界各地的实践者社区合作,不断发展。最近,Scaled Agile, Inc. 推出了 SAFe 5.0 版本。重要变化包括增加了第 10 条原则“围绕价值进行组织”,并将第 12 步从“维持和改进”更改为“加速”。但还涉及到了更多内容。想了解更多?阅读我们的 SAFe 5.0 的新功能和变化博文。

总结

SAFe 以及上文中讨论的框架提供了一个可行的选择,可帮助企业在组织内有效地扩展敏捷性并实现其业务成果。但同样重要的是,您选择哪些工具来帮助您扩大现有实践并实现这些实践的全部收益。进入 Atlassian 的 Jira Align,这是一款专为 SAFe 构建的企业敏捷规划平台。使用 Jira Align,您可以改进可视性、战略一致性和企业适应性,从而加速数字化转型。

后续内容
Spotify 模型