三分钟读懂规模化敏捷框架：SAFe vs. LeSS|ShineScrum认证

SAFe与LeSS之间一直有争论不完的话题和观点，所以拿他们进行对比的意义作用并不大，笔者并不想加入这场框架讨论的博弈之中，本文的目主要是把学习实践中引发的一些思考记录下来。本人也很好奇想弄个明白究竟他们有什么不一样，于是在网上搜索了一下，但资料并不多，并且感觉都很抽象，并没有解答到自己的疑惑。正是因为别人的分享都别人的经验，并不能理解到作者的观点，文章对于没有实践过或者学习过的我来说帮助并不大。

因为业务的发展，团队规模不断壮大，敏捷规模化就遇到的瓶颈，于是就有了系统学习规模化敏捷框架的动力。在上完SAFe的课后并不想被它的思维所局限，于是就想再学习LeSS，想知道在SAFe里所遇到的问题，在LeSS里又是怎样去化解的，亲身体验一下他们究竟有什么不同，怀着强烈的好奇心把两个框架都系统学习了。

笔者是以学员和实践者的角度进行分析，所以会局限于自己对框架理解深度、知识面和实践，文章分析也不会很全面，如有不足或不同观点十分欢迎交流和补充。

注：下文所说的LeSS都是指框里的LeSS规模，并不包括 Huge LeSS

1、Team容器

SAFe的容器在Team层，容器里有多个SCRUM团队和看板团队，即是会有多个PO和SM，SAFe并没有强调和限制用户使用特定一种形式的团队，它是单纯的水平扩展团队，直到到达上限150人（包括所有人）。
LeSS的设计就比较特别，只扩展SCRUM Team（在SCRUM里的组成只有三部分，SM、PO、SCRUM Team），它会有多个SCRUM Team，只扩大SCRUM Team的规模，但它只配置1个PO和多个SM，所以它是垂直扩展的，上限是50人(再大就会是LeSS Huge，这里不会展开)。建议SM支持两个团队，可以得到不同团队的视角，Fulltime。

思考

LeSS的团队容器设计是它的最大特色，在上CLP时就一直带着很大的疑问它是怎么能做到的？他为什么要这样设计？SAFe的设计是正常的人的设计思维，从1个团队到多个团队之后的困局，一步步地设计解决。LeSS的团队容器设计是经过实践再总结出来的，它也遇到过SAFe这样的设计问题，但为什么它不选择SAFe的同样设计（多个SCRUM团队）呢？而是多个SCRUM Team,请带着疑问往下看。

2、Roles

SAFe的Roles多得连自己也记不清楚，记得最清楚的一个Role就是RTE，因为整个SAFe的核心活动就是PI Planning,而RTE就是这个活动的核心人物，并且还进行了PI Planning沙盘,所以印象深刻。
LeSS的Roles就只有几个，PO、SM。

思考

讲到Roles真的是很大的一个反差，SAFe与LeSS的理念完全的相反，SAFe中把有的都列出来了，基本上企业是能够对上号的，如架构师，发布经理等等，这里真的很容易让人联想到为什么SAFe是这么受市场欢迎，框架的设计也是考虑了市场化的因素在内，要知道导入SAFe的决策者也是利益分配者，失败对于导入者是不能接受的风险，所以你懂的。角色的引入容易，但要撤就十分的难，LeSS这么少的Roles的原因就是给你设计一个用最少的Roles就能让你跑起，框架设计得尽可能的轻，对于那些从SCRUM团队发展起来的企业会比较适合进行扩展。那问题来了，这么说那不就是说LeSS对于转型企业导入就比较难了吗？因为要砍不少的人。这里的上下文还是在企业收支平衡的状况下，要是企业都要快挂了，那么决策的重点就不是在这里了，决策者更关注的点还是在是否对现有的团队有重大的改变或者未知的风险。那么LeSS的确相对于SAFe会有一个更大的组织变革，它更倡导的是用最短的时间过把组织结构调整过来，而不是一个渐变的过程，因为在渐变的过程中也要不断思考和调整，这样的过程也是一种浪费。以上两个问题都与精益思想吻合，延迟决策和消除浪费。

从推广的难度来看，SAFe里有多种协调的角色，给用户的感觉比较重，垂直是协调层间价值流从企业顶层战略一直向下分解到达Team层交付，水平是协调层里各团队、交付速度和吞吐率。SAFe定义的角色让用户可以选择性地去，只要达到同样的效果就可以，因为架构的设计是层级的，所以为了解决层级间和层内的沟通框架必须要引入更多的角色，从框架设计角度上是一个加法，设计者允许用户对框架进行裁剪，即用户要为框架做减法（之前已经分析过了，人们在做减法的时候往往会更加困难），推广上相对是容易导入。LeSS角色比较简单，从框架的设计角度上是一个减法，如果企业原来组织也是比较扁平那导入也是比较容易的，相反的话那就是困难。

3、系统思考

SAFe把系统思考作为了它的第二个原则，教材是这样说的，但只有一页说明

LeSS 把系统思考作为它的核心，并应用于全局的设计中,并且有详细的建模指引，系统思考是LeSS中解决延迟反馈的问题的处理方式。

思考

我翻查了SAFe的官网，系统思考的内容就只有截图所示的内容，意思应该是只有管理者才能去改变系统，并且要具备教授和展示系统思考的能力，要SAFe的SA认证课，官方的教程中对系统思考的教授是比较少的。LeSS中会把系统思考列入在教程中，系统思考是CLP应该要掌握的。所以两门课下来本人对两个框架的理解深度是有一个很大的差距，CLP会让你明白到框架设计背后的原理，而SA下来可能你只能记住PI Planning和RTE，掌握系统思考后，你可能会想知道为什么PI Planning一次要排4个迭代？背后有些什么因素驱使他这样设计？

对比到这里我们应该要停一停，慢下来回答之前Team容器抛出来的问题，SAFe与LeSS的团队容器设计的选择不一样，导致了整个框架的设计都不一样，而团队的容器设计也正是为了尽量减少Backlog的份数，而为什么要框架的设计与Backlog的份数有关系？而产品边界的定义又与团队的划分有关系，团队划分就会产品Backlog，那么这又是如何去解决呢？这个正是这LeSS的核心价值，也是这些CLP得到最大的收获，个中的杠杆原理请看吕毅老师最新的文章，这里不展开。只可以说一句“系统之美”！

SAFe的设计是多个SCRUM团队之间的协作，引入RTE角色去引导协调沟通会议、对齐信息，这是一个正常的思路所以就设计了一个沟通会叫PI Planning，这样设计的好处在于之前SCRUM团队的所有流程产品定义等都是以SCRUM为单元，不用改变，当然默认也是团队以SCRUM为单元，SCRUM团队所应有的能力都要具备，只要在上层加一个沟通的机制即可解决，但副作用就是降低了团队的适应性为代价。

而LeSS是以适应性为最大化目标设计，它要打破小团队的SCRUM（5-7人），变为大团队SCRUM（50人），CLP要理解它这样的设计背后的原因，就要对组织的设计、产品的定义、组件团队与特性团队的协调机制等都要明白，所以课程中你会强烈感受到两种截然不同的课堂体感。SAFe下来你会觉得比较空洞，LeSS下来你会明白他设计的原理。对于实践者来说LeSS是相对容易接受，而SAFe是管理者相对容易接受，观点与角度不一样。

4、沟通机制

SAFe设计了PI Planning,最多150人，由RTE来引导，1次计划一个SCRUM团队的4个Sprint的Backlog，有多少个SCRUM团队就有多少个Backlog和PO。
LeSS设计了Product Backlog Refinement ，最多50人,由PO来引导，1次计划一个团队的Backlog，尽量少的Backlog为目标，只有1个PO。

思考

这一部分是笔者最想去深入理解的，因为大规模框架的设计一定是有它特写的机制去解决沟通的问题，所以搞清楚两者的设计背后有没有共通和不同之处。两者的沟通会议是十分相似的，都是集体Review Backlog，但有一点LeSS的实践是有可取之处，就是为了让团队提高适应性，在集体澄清需求时，可打散团队，提升广度学习能力，这些实践在SAFe中并没有提及过。因为SAFe中只是直接沿用SCRUM或看板方法框架，所以实践都在其中了。而LeSS是通过实践总总结出来的框架，SAFe的实践在SCRUM团队的上层，而LeSS的实践是在SCRUM团中。所以他们两者表面上的不同之处就在于会议的频率、规模、形式等，但执行方式方法都是取决于他们的核心Backlog份数和PO数量。

这里我们在CPL课程时大家一起用系统建模推导过，SAFe为什么他要设计4个Spring的Backlog和一个IP，正正是由于团队的人数数量、澄清需求的成本、PO的能力、PO的数量、特性团队的专业化程度等因素相关。所以这样也回答了上面的问题，SAFe使用了正向思维的设计方式，所以框架的设计在开始时就被局限了，必须要有所牺牲适应性来换取设计的不足。

5、适应性

两种大规模敏捷框架从适应性的对比上，个人感觉LeSS的设计已经是达到极致，这个感觉是基于两个课程下来的感受。

以下讲一个在CLP中分享的一个案例，来说明一下敏捷框架适应性的设计，在某种场景下原来也有不适应的情况，这个案例让我得到不少的启发。

中台的设计会给企业带来适应性的下降。

国内某大型互联网集团，中台的设计并不适合大部分企业照搬，它的设计是为了支持企业快速产品开发的场景。企业要要进行快速开发和试错产品，把一些共性的服务抽象出来，提供给多个产品的支持，从而减少重复开发的浪费，是企业战略分解和经验积累下来的一个产物。但如果其它企业在一个产品都还没有做稳定的时候盲目照抄，只会降低企业的适应性。根据我们上面的分析，中台的出现必然会增加一多一份属于中台的Backlog，要是企业内组织间在未能形成成熟的沟通机制时引入中台，这样就相当于增加了一个壁垒，特性团队要依赖或等待中台，效率亦会下降。
当适应性文化已经植入到企业每一位员工的骨髓后，就能打破架框的局限，做到极致的适应性。

国内某大型互联网集团，能够在2个月内产品不赚钱就可以全部打散，人员也可以适应新的岗位和技能，在他们的眼里只有产品成功目标，团队做到这样的适应性，瓶颈就在如何发现有价值的产品上。感觉就像我们看的功夫片一样的套路，初学者开始要有基本功，先是有招再无招，达到极致的阶段已经可以无招胜有招，所以综观大型互联网巨头，他们并没有使用任何的框架一样可以取得很高的适应性，正是这个原因。

6、Management

SAFe高大上，看上去很美好，但实际很骨感
LeSS很轻盈和他的名字一样，Less is more,要做到这样简约并非容易。

大规模的敏捷是否成功取决于决策者的决心和智慧，两个框架都对管理者有很高能力的要求，甚至管理者们都没有意识到他们要改变的幅度是如此的巨大（包括个人和团队）。至于每一个企业的决策因素都不是单一和一致的，所以对于决策者们无论选择哪一个框架都是基本成功率最大的基础之上，因为失败的风险对他们来说是不能接受的事实。

7、Roadmap

SAFe有清晰的导入线路图

LeSS坚持了他一向简约的风格，也是抽象了6点

1. educate everyone

2. define ‘product’

3. define ‘done’

4. have appropriately-structured teams

5. only the Product Owner gives work to the teams

6. keep project managers away from the teams

思考

我们默认企业导入大规模敏捷框的目的都是为了提升企业的适应性！这点十分重要，如果这个不成立，那么导引就没必要性了。即企业的Tipping point十分重要，要是你都没有痛点，那么导入行为可能是一种政绩或其它原因。两者都在导入前要作充分准备，如工程实践，CI/CD的基础能力，各种角色的设计培训，最大的还是组织变革。

为什么SAFe总是感觉比较重呢？我思考了一下，很可能是因为他设计了太多的角色的原因，整个组织（即系统）要有序的动作起来，它要需要克服和解决的问题是人的问题，引入的人和角色越多，系统就越复杂，需要调整的范围更广，解决和分析的能力要求也就更高。SPC的引入是必须的，企业的转型怎么也要2年左右才会有成效，因为开始实践时只是在TEAM层，财务预算层还是以年来计算的，所以起码要到第2个财年才会有成效可见。

LeSS的组织变革更倾向一次进行大刀阔斧，目的也是很明确，宁愿开始时把最花精力的事完成，之后成功的几率会大很多，使用越少的改变得到最大的杠杆效果。

8、对实践者的价值

SAFe的实践者是SA，SA的认证要通过考试，考试过程会让你更加理解SAFe,所以觉得考试是必须的。再高一层是SPC，SPC的认证只要考试通过就可以，对实践经验没有要求。
LeSS的实践者是CLP，CLP并不需要正式的考试，只要上完课就能取得认证，课程中你能清楚理解到LeSS框架设计的原则，所以个人觉得考试与否并不重要。再高一层是CLB和CLT，CLT的认证条件是十分严格，这里不展开，目的是要让讲师要有真的LeSS实践。

谢谢阅读

如有不同观点和思考欢迎交流学习！

如认同文章的观点欢迎转发和点赞！

本文作者孔兆祥（南方航空敏捷教练），ShineScrum捷行转发分享