市占率遥遥领先的SAFe一直以来饱受争议。本文试着把对SAFe的批评声分类辨析，寻找对转型实施的启示。

1    批判之：SAFe不是敏捷

典型代表：SteveDenning的UnderstandingFake Agile。Denning此文提出了一个“敏捷三定律”：

1-客户法则：专注于为客户提供价值是组织的全部目标。

2-小团队法则：假设所有工作都由小型自组织团队进行。

3-网络法则：努力消除官僚主义和等级制度，使公司作为一个互动网络运作。

定律2，3结合在一起，形成一个业内很有影响的一个观点：规模化的挑战在于如何将大型系统/组织”去规模化”，以使小型自组织、以客户中心的团队可以驾驭；而非“规模化敏捷性”。这实质与LeSS所提倡的“去规模化”类似，也是SAFe与LeSS在在规模化道路上分道扬镳的一个基本点：SAFe的设计则是为大型复杂组织而生，并不强调”去规模化“，而是设计了一系列适应不同复杂程度的体系（4种配置方案）来适应组织需求，与Denning的敏捷三定律不是一种思路。

这里选取一些与小团队法则/网络法则一致的一些具体的批评声音。

Ron Jeffries:

SAFe过于强调Topdown。重要的东西在Portfolio层面搞清，features在Program层面定义…

Marty Cargen:SAFe是自上而下的管控。上层的人(产品经理、架构师…) 做所有的关键决策，然后产品负责人给工程师团队分配工作… 团队只负责执行

Chris Matts:

 - Epic-Story的结构适应并固化了组件型团队, 以及自上而下的“计划者”和“执行者”的分离。

这部分批评中，ChrisMatts的“Epic-Story的结构适应并固化了组件型团队”所描述的情形并不符合SAFe的设计（Story的定义需基于客户价值），这里不作进一步讨论；其他的几条类似，都是批评SAFe有自上而下的结构，这与传统敏捷爱好者“所有工作都由小型自组织团队进行”的期望不符。

Chris Matts:

 - SAFe聚焦于识别、计划工作并适应现存依赖。Agile方式则是组织团队和工作、最大程度避免依赖。

 - ART提倡同步、标准化、一致性…适配其共同开发、发布的需要；而这种需要又增加了协调工作量…大规模系统应依赖异步性…向每个团队独立发布的方向演进

Ron Jeffries:

- 单个团队成为真正敏捷团队、具备良好工程实践之前，不是引入这套复杂流程的时候（US DoD， James Grenning有相似评论）

这部分批评大致集中于SAFe的协调、同步机制立足点是管理依赖和同步，而并未强调去规模化思想所期望的消除依赖。

以上批评声音对大型组织敏捷化的期望可以归结为：转型应该聚焦于使敏捷团队能够独立自主交付客户价值，这样就不太需要自上而下的管理结构，也不会有太多的协调需求；那么SAFe这种较重的机制设计就不需要了。

网状结构组织的本质是去中心化的大规模自组织，一个个能够独立交付的自组织团队成为互联的节点，因为自主所以擅长捕捉机会并把信息传递给网络的其他部分、从而使整个组织能够灵活应对变化，这是一种激动人心的组织形式。但是，大产品开发是否能全面地去规模化到小型自组织团队可以独立承担价值交付？大型网状组织的成功案例，比如美国的Morning Star, 荷兰的Buurtzorg，读来令人激赏，但其所需的协作紧密程度与复杂软件是不同的。这种结构需要哪些前提，以及这些前提在大型软件产品中是否普遍可得，还需要更多观察和研究；这个方向值得多尝试，但把它作为唯一答案，至少是为时尚早。为什么呢？

小团队法则所推荐的团队组织形式可以看作一种“逆分工化”。社会化分工伴随工业革命而来，分工带来的效率提高促进了工业发展，这使“分工化”成为一种思维定式，软件产业也深受其影响。然而分工同时也带来了整合成本的提高，这在软件产品中尤其突出——传统的分工思维通常导致软件产品中的分工过度。我们用一个简单的系统动态表达。

图1 分工的两个影响

所以，跨职能团队实质上是对分工过度的一种纠正。

然而跨职能团队是否应该做到端到端全覆盖？延续上面动态图，我们用下图来分析分工粒度与成本之间的关系。一般而言，分工细致程度带来的领域内效率提升（也即成本降低）有其极限，如下图中蓝色曲线所示：但它所带来的整合成本趋向于以指数形式增加，因为沟通渠道以指数级数增长（图中黄线）。那么分工细致程度与总的人力成本之间关系如下图中红线所示。

所以，分工粒度有其甜区，而不一定是“全栈团队”（除非是中小型、人员较稳定的产品，模块生产成本可以大致拉平）；客户需求往往还是需要多个团队的协调一致，多团队的统一优先级管理仍属必要。

图2 分工粒度与成本关系

关于网络法则，JohnKotter认为，成功的初创公司天生更接近网络结构。然而公司一旦渡过初创阶段，总是会为效率优化，为效率优化的结果是产生层级结构（另文分析此问题：驱动组织演进的心智模式）。

Kotter认为层级结构有其价值，全部去除未必理智，于是提出了“第二操作系统”的概念：保留层级结构的同时，引入一个善于创新、善于捕捉战略机会的网状结构。

SAFe借鉴了这种思路，把基于价值流组织的产品研发体系作为“第二操作系统”，因为背后的管理层级无需改变，所以第二操作系统可以按照业务需求迅速重组。

SAFe的第二操作系统并没有革传统组织的命，然而对大型组织而言它往往是一种简化。例如，我做过的一个SAFe案例，敏捷发布火车获得了比传统团队大得多的独立性，产品经理对能够直接驱动团队很满意，因为之前优先级的确定往往需要在业务侧经历费时费力的流程，现在产品经理可以自己决定。

第二操作系统的概念并不意味着层级权力结构不做任何调整，否则“第二操作系统”的运作可能受到比较大的制约，极端情况甚至会是完全的新瓶装旧酒（比如，原先的组件组织重命名为敏捷发布火车）。但公平地讲，这种“假转型”无关你选择了什么框架，而在于组织是否有变革的决心、变革推动者是否理解转型的目的。

我想，组织变革跟产品研发有一点相似之处：都要追求效费比。如果能以不是太大的投入、基本可控的风险换取比较明显的效果，这会是一个显著优势。我认为这正是SAFe的特点：它是实用品而非艺术品，其优先关注点是企业的现实问题而不是“敏捷”本身。传统敏捷爱好者期望的去规模化网状组织是路途遥远的远方，路上风险难以逆料。SAFe则更看重提供一个基于企业现状的、相对简化的、现在就可以见到效果的机制，是一种改良而非革命。

2    批判之：SAFe过于繁重

先看一些批评的声音。

Al Shalloway:SAFe的复杂已经远超所需。。。

Mike Cohn 做了个“lafable”网站，嘲笑SAFe的复杂

Bob Galen: SAFe太庞大、远离了simplicity；太多角色、层次、flow …

Luca Minudel: 所有敏捷框架都“故意不完整”并提供通用指导，以促进进化。SAFe则太预定、标准化、强制化。

Ron Jeffries: 2天的会议定10周的计划是BPUF (Big Plan Up Front)

这些批评背后是一种特别多人认可的理念：框架要尽量简单通用，并提供原则让用户去演进他们的方案。我们可以看到这里面有一种对优雅的追求。

SAFe则是一种不同的范式，它试图为尽可能多的常见问题提供具体的答案——这仍然体现了它作为实用品的特点。比如ART层的角色、职责、活动设计，需求管理层级结构，等等，都提供了具体、细致的定义。

实际上，我认为提供完整的指导和工具箱正是SAFe成功的原因之一。这有点像实例化需求中的一个实例，具体而容易把握。针对你的场景而言，SAFe提供的答案很可能不是最好或者不完善，但这些参考答案有两个很重要的价值：

第一， 你知道了有哪些问题需要回答。有时候这比答案本身更重要。

第二， 有了参考答案，你能更快地找到更好的答案。

没有参考答案, 你自己也可能琢磨出来，学习效果还更好，只是要花费更多时间成本。而时间是最贵的。

前文提到对SAFe有很多批评的Steve Denning前些天发了一篇对VOLVO的访谈，从中摘取部分问答：

Denning: “批评者认为SAFe有自上而下、命令与控制的特质，其实施与敏捷心态很难合拍。但从你的描述来看，沃尔沃汽车对SAFe的体验很好？”

VOLVO: “…规模化环境下实施敏捷需要很多的系统性思考和纪律…如果没有某种框架和层级结构来辅助我们做决定、辅助我们排序优先级，老实说，我不知道怎么实施规模化敏捷。重要的是，我们的方式是开放、透明的，环境是信任、协作的，每个人都有机会提出问题、给出输入，从中可以识别依赖，并能看到我们是否有足够的资源完成承诺，等等。”

从VOLVO的回答可以看到SAFe设计所提供的参考价值。从实践而言，我们往往会基于SAFe提供的参考答案去寻找自己的答案，这里不再赘述，有兴趣的朋友可以看这两篇文章：PI计划与渐进计划（如需要可以留言索要PDF格式文件）；SAFe如何应对阵地战。

3    批判之：SAFe违背Scrum设计

Jeff Sutherland说，“...frameworkslike SAFe ... are inconsistent with the Scrum guide and codify disfunction thatcan cripple teams for years.”

一些Scrum支持者认为SAFe中的Scrum偏离Scrum原本的设计，认为这误导了公众对Scrum的理解，因此要求SAFe去掉对Scrum的引用，其活动网站在此：Remove ReferencesTo Scrum From SAFe。下面探讨的内容主要来自于此网站，也有部分信息来源于我平时的见闻。

3.1   Scrum Master角色的背离

可以归为两条：

一是：SAFe SM 被限制在一个“小角色”上，与组织变革无关。

二是：SAFe SM 被定义为一个沟通协调角色，职责中定义了很多本属于其他角色的活（比如跟其他团队协调, 向管理层沟通状态, 等等）。

SAFe Scrum Master的职责没有定义任何关于组织教练、组织变革的内容；而Scrum Guide中明确定义了Scrum Master要领导和计划Scrum导入、教练组织。

这个批评是有见地的。从一个团队扩大到一个组织，每个角色的职责都有分散，因此SAFe中定义的Scrum Master并没有覆盖经典Scrum的全部定义，后者的部分职责在SAFe中给了RTE（甚至STE，如果你有大型解决方案）。实际上，SAFe官方就提到过，RTE相当于整个ART的Scrum Master。

这里我们仍然用一个系统动态来分析何以如此。

图3 两种解决团队间协调问题的机制

上图中，“团队间协调工作差距”代表规模化情势下团队数量、依赖程度及团队分散程度导致的团队之间工作需要协调的问题。（这里我把Scrum Master作为团队一员。）

这个问题有两个可能的解决方案：一个是增加跨团队协调角色-这是图中的B1环路。另一个是保持大团队的自组织，让团队在工作中增强其内在协调能力，这是图中的B2环路。B1环路对B2环路有抑制作用，因为既然RTE负担了跨团队协调工作，那么团队自己发展这个能力的需求就被抑制了（这是一个负担转移结构）。

SAFe再一次体现了其实用主义本色，简单直接地选择设立RTE角色。我认为这一选择与SAFe的核心价值相关-SAFe的四条核心价值之一是“项目执行(Program Execution)”，认为“如果团队不能有效执行、持续交付价值，SAFe的一切其他部分都没有意义”。为“whodoes what”给出一个具体、清晰的答案是为项目执行优化的。而如上图所示，理论上，这个选择是对团队赋能有妨碍。

B2是更理想主义的选择，但理想主义也有其显著代价：团队的协调能力成长起来需要时间，并且有各种制约因素。在没有一个类似RTE角色的情况下，团队可能经历很长时间的混乱无序（甚至，这个坑你不一定爬得出来）。

我们只能二选一吗？其实上述环路蕴藏了其他动态，我们用下图表示中橙色链路表示。团队间协调工作量越多，RTE符合就越大，那么RTE就越倾向于赋能团队。

图4 团队间协调问题的延伸动态

这给我们什么启发？破解之道就在于此。

RTE 与SM可以作为一个虚拟团队工作，SM分担RTE的负荷并在需要时作为RTE的备份。我们可以在组织设计中明确RTE作为资深的Scrum Master身份出现。这事实也为Scrum Master建立了一个职业路径。

那么，理想的RTE候选人应该兼具教练属性和执行能力。日常的工作可以授权给Scrum Master和团队，自己作为守住底线的那个人。所以你就知道，如果RTE整天忙碌不堪，那说明要么是她还很需要改进（有没有意识到RTE的教练属性），要么是她所属的组织还很需要改进（是否支持RTE的教练属性）。

3.2   PO/Team角色的背离

关于PO和团队，主要有三个批评点。

第一个是SAFe里的多份待办事项列表会导致团队的仓筒化。

这个评论不完全来自于上述网站，也来自于一些日常的讨论。在我看来，这个观点并不成立，只要产品经理坚持产品待办事项列表(ProgramBacklog)优先级顺序保持客户价值导向，而非团队专业能力导向——也即当团队能力与优先级要求不一致时，调整团队使能力适应工作，而非调整优先级使工作适应能力——即可在利用团队的专业化提升效率的同时，消除专业化仓筒。实际上，SAFe的基本机制支持这一点（因为产品经理无需关心团队Backlog的内容）。具体分析我另有专文，这里不再展开，有兴趣的朋友请转此处：待办事项列表数量与团队仓筒化风险

第二个是PO 负责决定故事是否达到完成（Done）的状态，这使得PO位置高于团队，从而导致“合同游戏”。

我认为这是个无可厚非的选择。换一种做法，比如团队决定Done，那么PO可不可以代表客户拒绝接受？很难说哪种做法就一定更好。

第三个批评是，组织中的高层角色拿走了团队的职责，损害团队自主，从而导致动力缺失。

这一条其实跟本文第一部分中Denning的小团队法则的批评是一类的。实际上，规模化中团队的部分责任让渡到组织中的其他部分是难以避免的。但这条批评我认为不应该完全忽略，实践中至少如下可以尝试：

一，系统架构师的角色由团队成员充当。个别专职的System Arch可能是必要的，比如一列较大的火车或许保留一个专职的系统架构师, 其他兼任；小的火车甚至考虑架构师作为团队成员。因为架构师会参与早期需求活动，作为团队成员就可以起到桥梁作用。

二，团队参与”高层”需求过程。

有的公司实践中，需求一旦进入研发评估，团队就会开始跟进。大需求(Epic)潜在需要多个团队，所以也需要控制此时的成本投入（比如同一领域的多个团队可以只出一个代表）。

但是这里有一个前提，即我们需要大致知道哪些团队会承担哪些需求。这涉及团队的专业化程度的的取舍。

三，团队PO直接面向客户。

PdM和PO可以作为一个团队运作；PdM依然负责产品Backlog，但PO在其重点关注的领域内直接面对客户需求往往是可能的。PdM的重点是产品级的优先级排列、优先级冲突解决。

4    总结：为什么这么多组织选用SAFe？

以我的观察，用它与骂它，常常是同样的设计。

警告：以下具有强烈的个人偏见，仅供参考。

第一：SAFe草根气质很重，它的首要着眼点是大型组织的当前需求，而非敏捷本身。不是不要诗和远方，但是更关心粮食和蔬菜。

第二：SAFe是一套完整的、照顾到各层级基本需求的可参照解决方案和工具索引，框架的参照价值较大。

第三：虽然被骂繁重，但SAFe的设计对大型组织通常是一种简化， 对一些管理混乱的组织则提供了秩序。

第四：SAFe的内核是精益；精益的一些思想、工具和方法（相对）易用、易见效（不要误解-建立精益内核很难。但用好皮毛也能使组织受益不浅。）

第五：SAFe的路径是改良而非革命；现有组织能支撑它的“第二操作系统”就好 - 这不仅是为减少抵触，也利于避免重大风险。（这是双刃剑 – 可能导致止于名义的改变 – 但这点取决于人而非框架。）

5    最后的启示

我倾向于认为，规模化和去规模化是同一件事情的两面：规模化图生存，去规模化图发展。这两者合在一起才是规模化敏捷的全貌。SAFe优先考虑的是生存问题，关于SAFe的批评中我认为最需要警惕的一条恰恰与此相关，所以留到最后。

这个批评来自于Ron Jeffries，我们前面已经看到了他的很多批评；如果你留意了你可能会发现Jeffries的批评往往特别具体、特别言之有物。这不是偶然的。作为敏捷宣言签署者之一、极限编程的主要创始人之一，Ron Jeffries为了了解SAFe，是亲自参加过SPC培训的。

他说：

“…It provides some benefit, but endangers an organization's progresstoward really high functioning.” （翻译：“它提供了一些好处，但危及组织向高效运转状态发展。”）

基于价值流建立第二操作系统，组织从中得到好处，这很好。但是，这里的风险是就此止步。不少组织把SAFe转型当做一个项目运作，项目基于问题（痛点）启动，项目结束，问题解决了——继续演进的动力随之消失了。所以，SAFe转型实际上有两个难点：第一个是如何取得成效，第二个是取得成效之后如何继续进化。不过，不能认为其他框架就没有这个问题– 只要组织把敏捷转型当做一个一次性的项目，那么无论用什么方式，都会有这个风险；SAFe尤其需要注意这点，一是因为SAFe定义得具体细致（定义越多，越有成品感），二是因为SAFe转型的实施路线图可能给人项目化的暗示。

第二个难点如何克服，取决于转型的过程中能否让精益敏捷的理念深入人心，尤其是深入领导者的人心。这是对转型推动者的最大考验。