规模化敏捷框架 （SAFe） 是一个企业实施敏捷实践的组织架构和工作流模式，主要基于敏捷软件开发、精益和系统思考三个知识体系形成。
SAFe 框架为敏捷的实施提供了包括角色、职责、规划、管理、价值观、团队结构的指导。同时也为大型企业提供了一套实现大规模敏捷的结构性方法，设计了四种配置以适应不同规模的团队：基本 SAFe（Essential SAFe）、大型解决方案 SAFe（Large Solution SAFe）、投资组合 SAFe（Portfolio SAFe）和全面 SAFe（Full SAFe），有效的促进了规模敏捷团队的一致性、协作和交付。
随着时间的发展，企业用传统的软件项目管理方法已经无法应对激烈的市场竞争。所以敏捷教练 Dean Leffingwell 和 Drew Jemilo 于2011年推出了 SAFe 框架，旨在帮助企业优化组织结构、提高软件交付质量以满足不断变化的客户需求。
如今，SAFe 已经成为最流行的规模化敏捷框架之一，敏捷教练们在全球的企业中实践 SAFe 框架并不断对其进行改进。
一、SAFe 核心原则和价值观
1.SAFe 框架的核心价值观
SAFe以增强领导力和提高团队运作效率为核心价值。
一致性：SAFe 要求企业在各个层级制定统一的工作规划和进行周期性总结，让每个成员都要了解目前的业务进度和业务目标，以及每个人要如何为目标的实现做出贡献。这样的好处就在于能够统一团队的工作节奏和工作任务，提高了各层级资源配置的协调度。与传统的自上而下进行信息传递的控制型模式不同，SAFe 模式中信息可以及时的自上自下双向流动。
内建质量：提高敏捷度不应以牺牲工作质量为代价。 SAFe 要求各级团队定义每个任务或项目的“完成”的标砖，并将高质量的开发实践融入到每个工作过程中。根据 SAFe 的描述，内建质量有五个关键维度衡量工作质量：流程、架构和设计质量、代码质量、系统质量和发布质量。
透明度：SAFe 鼓励团队中建立信任的行为，比如：以较小的周期为单位规划工作，以便更快地发现问题；待办事项清单进度在各个层级实时透明，以便及时检查和调整规范。
程序执行：程序执行是 SAFe 的核心，是框架中一切规则的推动力。各个团队和项目组必须能够创造价值，定期交付高质量、高性能的软件。
领导力：SAFe 的实现需要精益敏捷领导行为的支持，因为只有领导层有权改变组织体系，创造有利于实现核心价值的工作环境。
2.SAFe 框架的9大原则
大规模敏捷框架的所有原则都是旨在通过在跨职能、跨组织协作中激发精益决策来改善整个公司的运行效率。其作用不仅是影响领导和管理层的决策，并且通过实践精益投资组合管理，会影响组织中每个成员的决策以及思考模式——从传统的瀑布思维向精益敏捷转变。
原则1:采取经济视角
唐纳德·G·莱伊纳岑（ Donald Reinertsen ）的畅销书中关于产品开发流程的理论告诉我们：想要使可持续交付的前置时间最短，决策链中的每个人都要了解延误交付带来的经济影响。短时间频繁交付的方式并不总是适用。SAFe框架规定，对工作进行合理优先级安排以实现利益最大化，了解影响业务收益的因素，以及思考项目如何在精益预算内运转，是所有成员都应该共同分担的责任。SAFe 框架中的很多概念和工具都来自莱伊纳岑的产品开发流程理论。
原则2:运用系统思维
SAFe 框架倡导企业把系统思维应用在三个关键领域：业务解决方案，企业构架和价值流。解决方案可以指企业内部或者外部交付给客户的产品、服务或系统。
大型项目的业务解决方案通常由很多相互关联的部分组成，团队成员要具备如何将自己负责的部分融入整体的大局观。在构架上，企业应该同时考量员工、管理和流程三个方面。一个企业如果想通过实践 SAFe 改进员工的工作方法，首先要清除部门之间相互合作的障碍，使团队之间真正实现跨职能合作，然后与供应商和客户签订新的工作协议。
最后，企业应明确定义价值如何从方案开发价值流中从概念转化为资金。而且领导者和管理层需要最大限度地提高跨职能和组织边界的价值流动。
原则3: 预留空间，拥抱变化
默认情况下，系统和软件开发面临的不确定因素有很多。所以该原则通过引入基于集合的设计概念（Set-Based Design）来应对不确定性问题，在研发初期不要只选定一套认为是正确的方案，然后一条道走到黑。而是保留一个设计集，在后续的研发中通过收集经验数据，这样越到后期排除的选择就越多，就越容易选出最佳方案，甚至可以在进入市场后来逐步地确定最终的方案，从而为客户交付最满意的成果。
原则4:建立持续学习闭环，进行增量式构建
与原则3类似， 该原则要求通过“学习里程碑”来应对风险和不确定性。因为开发团队不能仅仅关注系统中的部分功能是否运行良好，而必须适时测试整个系统以评估当前方案设计选择是否可行。学习里程碑要求团队规划学习的集成点以加速学习周期。 集成点概念来自休哈特（Shewhart）的PDCA（计划–执行–检查–调整）循环，这是一个是质量持续改进和控制开发中变量的机制。
原则5:基于对可行性方案的客观评估设立里程碑
与做报表这些表面性成果评估相比，定期展示工作成果更有利于最终决策。让利益相关人员尽早参与可行性决策有助于建立彼此信任、提高系统思考能力。
原则6:可视化和限制在制品，小步快跑
限制在制品有助于利益相关者准确了解工作进展情况。这一原则的三个要素是实现最大吞吐量和加速价值交付的主要方法。将可视化和限制在制品应用在软件开发上，就意味着：减少工作重叠的数量、降低每项工作的复杂度以及在给定时间内需要处理的工作总量。 减少批次规模可以使团队不断验证工作是否朝着正确方向进展。
原则 7 ：通过跨领域计划建立同步的工作节奏
敏捷团队的工作节奏的一般方式是通过冲刺或迭代会议。 为所有可能发生的事件设定一个应对节奏可以降低问题的复杂性、减少不确定性、建立肌肉记忆、强化工作质量并且有利于在团队中普及协作理念。如果工作节奏得以同步、信息得以共享，就能促进决策和增量规划，团队成员的工作会像齿轮一样彼此咬合，有益于加速整个项目的推进。
原则 8:释放知识工作者的内在动力
这个原则是受著名管理顾问彼得·德鲁克（Peter Drucker ）和畅销书作家丹尼尔·平克（Daniel Pink）的启发，旨在释放团队的内在动力，并帮助领导层通过指导和服务团队的角度出发，而不是命令和控制的心态。
原则9: 去中心化的决策
通过分散决策来缩短流程长度并采取合适的方法，可以赋予团队更多自主权。 领导者应该保留团队成员对战略重要性的话题的决策权，使团队能够对其他所有事情做出明智的选择。
三、SAFe的实施步骤
想要实践 SAFe 的企业需要得到高管层的支持、有强烈的变革欲望和 Scrum 基础。
SAFe 给出了详细的实施路线图 ，包含了如何启动、如何设置组织，以便在在跨投资组合中实现大规模敏捷。
SAFe 的 12 个步骤包括：
- 到达临界点（Reaching the tipping point）
- 培训精益敏捷变革代理人（Train lean-agile change agents）
- 培训高管，经理和领导者（Train executives, managers, and leaders）
- 创建精益敏捷卓越中心（Create a lean-agile center of excellence）
- 识别价值流和敏捷发布培训（Identify value streams and Agile Release Trains）
- 制定实施计划（Create the implementation plan）
- 准备启动ART（Prepare for ART launch）
- 培训团队并启动ART（Train teams and launch the ART）
- 辅导ART实施（Coach the ART execution）
- 推出更多ART和价值流（Launch more ARTs and value streams）
- 扩展到产品组合（Extend to the portfolio）
- 维持和改进（Sustain and improve）
四、SAFe 与其他规模化敏捷框架的异同
尽管SAFe在很多大型软件开发企业中得到了广泛实践，但随着时间推移，还有很多规模化敏捷框架也逐渐受到企业青睐。 而所有大规模敏捷框架都有五个共同的构成基础：敏捷宣言十二条原则、节奏、同步、Scrum 和质量开发实践。了解其他框架的起源、主要差异及奏效的条件可以帮助组织选择最适合自己的框架。
1.SAFe vs. Scrum@Scale
在 Scrum中，每个成员都是可相互替换的 Scrum 团队的一部分，并且分散的 Scrum 团队网可以根据目标聚合为一个生态系统。S@S 旨在通过“可自由扩展的架构”组建Scrum团队的网络，实现线性扩展性，无需引入新的动态流程。 例如，对于拥有 25 个 Scrum 团队的企业来说，一个 Scrum (SoS) 可能应付不了的非常复杂的产品交付，因此可能需要 Scrum of Scrum of Scrums (SoSoS) 或者 Scrum of Scrum of Scrums Master (SoSM) 才能完成。
S@S 并不像 SAFe 一样有很多规范性标准，但它却给出了一个指导性的问题——如果在组织中增加更多的人员，企业运行效率是会呈指数式增长，还是生产力受到影响？从而启发企业去思考自己是否已经准备好实施大规模敏捷。
与 SAFe 一样，网络上也有很多关于S@S的参考资料，如被频繁引用的 《Scrum@Scale 指南》。
S@S 发挥作用的条件：
- 技术栈以目标用户为导向（比如：垂直用户故事可以在两周内交付）
- 功能团队具备 T 型技能，秉持以产品为中心的价值观，和最少的官僚主义
- 在S@S实践成为第二天性之前，不需要敏捷或敏捷生命周期管理 （ALM） 工具
- 执行团队愿意实践 Scrum 并致力于移除组织结构中的障碍
2.SAFe vs. Large-Scale Scrum (LeSS)
LeSS 框架对角色、结构和工件上采用的是简化的策略。相对于 SAFe 提供四种配置来适应越来越大的规模和日益复杂的解决方案团队， LeSS 则只有两种：
- LeSS 模式：适用于2-8个团队的规模；
- LeSS Huge模式：适应于超过8个团队的规模。
在决策方面，LeSS和 SAFe 也有很大区别。LeSS的产品负责人（Product Owner）有绝对战略决策权，而SAFe 则在决策上更民主。SAFe 决策规划的产生受多种因素影响，而 LeSS 更聚焦于以客户为中心，专注于服务付费客户。
和S@S 一样，LeSS 也是基于 Scrum 框架，在 Scrum 的事件、工件和职责上进行大规模敏捷的扩展。 SAFe 和 LeSS 的指导原则类似，都强调系统思维和精益思维。 但LeSS以持续改进为目标，且更注重减少组织体系中的资源浪费。
LeSS 发挥作用的条件：
- Scrum 团队已经掌握了 Scrum 敏捷实践
- 领导层愿意为了长远的发展不断重建和不断试验
- 有一致性的产品定义
- 有标准的“完成”定义
- 聘请外部教练参与组织、团队和技术团队的合作改进
- 具备有 T 形技能的功能团队与组件团队
- 组织愿意完全摆脱传统项目管理模式
3.SAFe vs. DA
与上述其他框架都不同的是，Disciplined Agile (DA)——规范敏捷是一个让企业决定哪种工作方式最适合自己的工具包。 它是植根于 Scrum 和看板的轻量级敏捷管理方法，囊括人力资源、财务、管理、DevOps、投资组合管理等多个领域的知识。 DA 根据项目的不同设定不同级别的敏捷管理方法，着重指导企业如何在战略方向上进行决策。
DA发挥作用的条件：
- 企业希望自己定义规模化敏捷的扩展路径
- 企业想保持组织体系的灵活度
- 企业不想尽快决定选择哪种工作流程或管理框架
4.SAFe vs Spotify模式
Spotify “模式”是一套以人为驱动、高度自治的规模化敏捷管理方式，旨在协促进敏捷团队之间的协作。Spotify 模式严格意义上讲并不能被称为一个模式或框架，但一些企业把它当作框架进行实践。Spotify 模式强调自主性和跨职能协作，把在同一地点工作的团队称为“小分队”（相当于 Scrum 团队），而SAFe只鼓励团队进行 PI 规划，并没有规定团队要在同一地点办公。
在 Spotify 模式中，由多个“小分队”组成的大团队被称为“部落”。 “小分队”之间没有过多的相互依赖关系，在遇到复杂的任务时通过SOS （Scrum of Scrums ）来协作。 “分会”和“协会”是根据技能分类和兴趣爱好建立起来的非正式团体，内部知识可共享。
本文所提及的其他模式都有在线资源、培训课程和认证机构，而有关 Spotify 模式的资料仅限于发布的博客内容，以及先行实践过的企业和粉丝的经验分享。 Spotify 模型越来越受欢迎，相信未来会有更丰富的理论总结出现。
Spoify 模式发挥作用的条件：
- 实践此模式要结合本公司的实际情况。
- 组织文化侧重于学习、允许错误和承担可控的风险
- 团队和产品“松散耦合，紧密对齐”以避免依赖冲突
5.SAFe 5.0
SAFe 框架一个核心原则是在汲取全世界企业的实践经验后不断优化升级，最近社区 Scaled Agile, Inc. 推出了 SAFe 5.0 版本， 增加了第 10 条原则：“围绕价值组织”，并将第 12 步从“维持和改进”更改为“加速”。
结语
SAFe 和本文介绍的其他框架，为企业在内部如何实现敏捷转型和取得业务成果方面提供了切实可行的方法。思考如何让目前所遵循的敏捷框架发挥最大效用，是和权衡选择哪种工具同等重要的问题。
