前面我们通过三篇不短的“短文”比较系统的介绍了SAFe，是不是让你对大规模敏捷的实施更有“安全感”了？
照例，今天我们聊聊“我眼中的SAFe”。
初次接触SAFe，我跟大家的第一印象一样——怎么这么复杂？！甚至觉得这又是敏捷圈又一个“内卷理论”的实例。但随着对SAFe的深入了解，却越来越发现它背后的逻辑其实是“清晰而简单”的。
SAFe是优秀的企业级敏捷解决方案
笔者认为，毫无疑问，SAFe是优秀的企业级敏捷解决方案。这也难怪SAFe目前是扩展敏捷实践的最常用方法，没有之一。
SAFe是全面的
首先，SAFe是非常全面的。涵盖了软件研发（甚至是包括硬件的复杂系统）的方方面面。
其架构设计是非常清晰且各有侧重的：团队层关注的是敏捷团队；项目群层聚焦的是多支团队如何协同；投资组合层和价值流层（可选）将侧重点放在如何进行公司战略拆解落地以及价值流的全面管理。
而且各层之间的关联关系和边界也是明确的：
由上至下：战略拆解通过业务史诗体现，并通过价值流的投资组合输入到价值流层/项目群层；在项目群层，价值流被拆解形成了PI目标，并进一步拆解为迭代目标；团队层通过PI以及迭代目标对齐团队PI及迭代目标，以跨职能的敏捷团队的工作方式完成功能交付。
由下至上：团队层敏捷团队通过完成迭代任务交付工作；在项目群层做更大范围的工作交付的集成和进度检视，通过迭代目标和PI目标的达成情况向价值流层和投资组合层反馈结果；价值流层及投资组合层通过PI的结果和节奏不断向用户交付价值和进行预算与价值流优先级的调整，确保整个团队工作始终围绕企业战略目标开展。
同时，SAFe也重点提及了“跨层级面板”相关角色对于大型团队协作的支撑作用。要支持大型敏捷团队的协同，一些必要的基础设施是必不可少的。
尤为难能可贵的是，SAFe也没有忘记基础层对于精益-敏捷领导者的要求，同时也强调了“实践社区”对于大型敏捷团队不可忽视的作用。
在笔者看来，这其实是决定敏捷转型成败的、但非常容易被忽略的“文化”层面的重要因素。
所以，笔者认为对于“SAFe过于分层”的吐槽是毫！无！道！理！的！
SAFe是可实操的
通常比较复杂的体系，都比较难于理解和落地，但SAFe恰恰相反。
SAFe不仅分层是非常清晰的，而且对于每一层的重要活动，尤其是涉及到多敏捷团队的中大型活动的如何开展，SAFe都给出了比较明确的实操方法。
我们简单对比一下LeSS：其实LeSS，尤其是LeSS-Huge的迭代组织方式与PI非常类似（只是PI更重一些），我们可以姑且等同认为是项目群层。如果说LeSS项目群层相关活动应该如何实操还有所提及的话（关于LeSS-Huge的篇幅其实也非常少），那么往上的层级以及支撑团队的作用是根本没有涉及的。
或许LeSS想秉承“Less is more”的理念，又或许极其重视团队建设的LeSS认为这是敏捷团队本身应该拓展的工作：因为让团队的工作更有价值本身就是我们追求敏捷变革的初衷。
但笔者认为，如果没有一系列明确的机制作为保障，单靠团队自身的力量，在实际应用场景中其实是很难落地的。所以，笔者认为这是LeSS的不足之一。
而SAFe相较之下相对完整，各层都有可以落地实操的方案。
除此之外，如果我们不是从0到1去建设敏捷组织，而是要将现有的中大型组织做“敏捷转型”的话，SAFe较之LeSS参考价值更大。
LeSS里的角色很少，除了单个敏捷团队的“三人天团”之外，就拓展了一个APO的角色。如果一个中大型企业想做敏捷转型的话，我觉得恐怕阻力很大：因为其他的角色都没提及，那么原有的这些角色自然会比较担心自己“失业”，进而抵制“变革”了。从推动变革的角度来看，其实是很难实操的。
SAFe则不同，请大家仔细回忆一下：其实除了敏捷推出的新角色之外，其他在传统大型团队中存在的角色都能多多少少在SAFe中找到对应关系，只是承担的具体职责可能会有“敏捷化”的改变。
所以，笔者认为，从这个角度来看，SAFe对于“敏捷转型”亦是更为可以落地的方案。
SAFe是注重细节的
SAFe除了比较全面和系统，在细节上也是周到的：在中大型团队协作过程中可能出现的问题，SAFe都给出了明确的答案。
比如“如何处理团队依赖？”
SAFe短期是通过PI计划做识别，通过Scrum of Scrums和PO同步会来跟进解决。长期也跟LeSS一样，关注“最小化约束”，尽量做到团队间解耦。
又比如“如何进行基础设施建设？”
SAFe明确了“跨层级面板”相关团队的职能，避免多支团队自发的无序建设带来的问题。这一点是笔者认为明显优于LeSS的。
再比如“如何做架构演进？”
SAFe从价值流层以及项目群层都有专门的角色和特别显性的有效机制来确保这部分的工作有专人负责和有效推进。这也是在LeSS中没有涉及的。
可以说SAFe照顾到了大型团队协作的方方面面的细节，一定是通过大量的实践提炼总结而成的，可谓字字珠玑。
SAFe对于项目管理理解比较到位
笔者曾经吐槽，LeSS对于组织中的横向部门的工作职能（如PMO）似乎有些误解，甚至有些排斥。相较之下，SAFe对于项目管理这个角色的理解是比较到位的。
诚然，敏捷项目管理与传统项目管理是有不小的差别的。但笔者一贯认为，不管在敏捷体系里项目怎么运作，需要处理的那些事情并没有消失。
只不过在敏捷里，有些属于传统“项目经理”的职责移交到了更合适的角色身上而已。在SAFe里也是如此，而且随着角色职能越宏观，其差异越小：
在团队层，Scrum Master类比“项目经理”，聚焦于单个项目（敏捷）团队的价值交付；
在项目群层和价值流层，RTE和VSE类比“项目集经理“，工作重心是多个项目（敏捷团队）之间的协同；
在投资组合层，甚至名字都没有换，就是项目投资组合管理。也就是传统意义上，公司级PMO应该承担的责任；
注：请注意是“类比”，至于其中差异，在专栏的前述文章里面有专门讨论，此处不做赘述。
综上，可以说，笔者对于LeSS的槽点，SAFe全解决了。
SAFe的不足
正如事物永远有两面一样，下面聊聊我认为SAFe的不足。
过于“复杂”
虽然深入了解了SAFe的底层逻辑后，SAFe相关内容还是相对清晰的。但相较于敏捷一贯给人“轻量级”的印象，SAFe仍是过于复杂了。
SAFe试图去适配的场景非常多。比如你看到了，SAFe给出了如何与硬件团队甚至于外部供应商合作的的方法，因而会有“价值流”层的产生。又比如，在不同层次中，因为职责略有不同，创造了非常多新的“角色名称”。还有一些其他的例子，如果你没有真正把握SAFe的设计逻辑，理解起来还是有一定门槛的。
过于“复杂”的一个直接后果，就是无从下口，想尝试的同学往往会望而却步。
另外，SAFe提供的解决方案相对更适合比较成熟的中大型组织。而对于一些发展中的中大型组织，虽然人员规模已经完全达到了可以实施规模化敏捷的条件，但一些角色在目前组织暂时很难找到对应的关系。SAFe的“复杂”似乎不利于发展中的组织逐步“迭代实践”，剪裁运用。
过于依赖“由上至下”
与LeSS由下至上相反，笔者认为SAFe还是比较依赖“由上至下的”。
虽然SAFe也提供了所谓的“Implementation Roadmap”，但总体上就是一个思路：“培训”，让相关人员弄清楚怎么玩；然后，Go！
虽然从敏捷“通过实践不断迭代优化”的大方向来说，这本身也无可厚非。但是如果一开始无法获得高层的全力支持的话，转型应该如何实施，SAFe似乎没有正面回答这个比较现实的问题。
以笔者的经验来看，除非是对于变革非常有信心和魄力，大多数公司高层的态度开始往往往是“既不反对，但亦不会全力支持”的状态，而会随着变革的逐步开展逐步加大关注和支持力度。
所以，SAFe一开始摆出的就是一副“全员高度一致”的状态，似乎本身就有些“不敏捷”。：（
投资组合层设计有些模糊
上述两点不足可能会对SAFe的进一步广泛推广带来一些阻碍，下面聊一点我认为SAFe在设计本身上的问题。
对于投资组合层，依笔者愚见，除了通过PI的节奏及时拆解企业史诗以及获得执行反馈之外，其他与传统的企业的实际运作并无太大的区别。甚至建议“预算每年调整两次”，是不是嗅到了而一些“熟悉”的味道？
这多少与企业当今面临的多变的外部环境有很大反差。在这个层面上，SAFe并没有给出如何激发组织如何从业务方向这个层面上快速应对变化、更不用说用何种机制确保“业务创新”的方案。
这不免也是SAFe让我觉得有点美中不足的地方。
我的猜测
以下又是“我的猜测”时间啦，仅供各位参考，各位“砖家”轻拍。^_^
研究SAFe的同时，不免要了解下其发明人Dean Leffingwell。笔者发现这位居然也是一位“上古大神”：上世纪90年代发明了《软件需求管理统一方法》，后续被收入了“UML”的大的框架之下。
注：不怕暴露年龄的同行一定看过他的这部著作，照片在文末作为彩蛋放出。^_^
如果说LeSS的发明者有点像是“工程师”出身，那么Dean Lefingwell就一定是“架构师”了。所以两者的思考的侧重点是不同的。
正因为如此，SAFe给出的一定是不同于LeSS的“企业级、系统级的解决方案”。
大家明显可以感受到：LeSS更注重底层团队建设，而SAFe更注重体系建设。打个不恰当的比方，如果说LeSS给大家展示的是“代码之美”，那么SAFe更倾向于给大家诠释“架构之美”。
如果我们从架构师的视角来看，SAFe既全面又细节的解决方案，以及希望“适配”所有场景的设计思路是不是就不难理解了。笔者认为，这也是客观上造成SAFe比较“复杂”的主要原因。
需要特别指出的是，虽然SAFe大部分篇幅花在体系侧的描述，但不意味着发明人忽视团队层的建设。从篇幅不算太多的团队层的具体实践方法，可以看出SAFe在团队层的思考也非常深入，一点不比LeSS少。
正因为SAFe想要提供的是一个全面的企业级解决方案，如果仅作局部的“改良”，其成效会随着“转型”的进行，被“企业重力”不断的拖慢和拉回原地。笔者见到类似的Case也非常多了，相信Dean这样的骨灰级的专家一定不会忽视。
可能是出于以上考虑，SAFe才特别强调获得从上到下的全面支持，来推动“敏捷转型”的进行，确保转型成功。我现在倒是有点理解，为什么一开篇SAFe那么强调对于“敏捷-精益领导者”的培训，以至于有点像“培训推销”了。^_^
综上所述，SAFe是一个优秀的企业级敏捷解决方案，比较强调至上而下的进行“变革”。
所以，我把SAFe定义为“组织敏捷”。
以上就是我眼中的SAFe，希望大家就这个话题跟我积极互动！
BTW，预告一下，Spotify篇On the way......
附彩蛋封面一张，读过这本书的我们握个爪！^_^
