从11个视角来解析当前流行的三种规模化敏捷框架

摘要：本文作者孔兆祥，由Jim Wang审校，作者从自己的视角尽可能做到文章观点的中立和完整的剖析，如果你对本文和规模化敏捷有其他见解，欢迎留言与作者互动。

本文以多个维度不同视角向你呈现Scrum@Scale 、LeSS 和SAFe三个规模化敏捷框架的共性和各自的特点。包括Scrum团队容器、沟通机制、沟通饱和度、适应性、系统思考、实施路线图、原则、角色、DevOps、Product Owner、实践者，11个维度可以分为三类受众。Scrum团队容器、沟通机制、沟通饱和度是设计规模化敏捷框架的重要元素，这三个维度能为敏捷推动者设计框架提供参考。适应性、系统思考、实施路线图、原则四个维度企业决策者会比较关心。角色、DevOps、Product Owner、实践者属于框架的角色和认证的共性，对实施层面的朋友可能会有所帮助。

一、规模化敏捷框架

1.1 Scrum@Scale

(图1：Scrum@Scale框架的组件透视图)

Scrum@Scale由Jeff Sutherland设计，也是Scrum框架的发明者。从框架的组件透视图看到，Scrum@Scale框架由一个Scrum Master Cycle和一个Product Owner Cycle的工作闭环流程组成，中间有Executive Action Team(EAT)和Executive Meta Scrum(EMS)两个组织，这两个组织是整个框架的核心。框架看上去都很容易理解，那么它有什么独特之处呢？究竟它与其它框架有什么不一样？它背后的设计逻辑是怎样的？它的沟通机制是怎样的？

1.2 LeSS (Large Scale Scrum)

(图2：LeSS框架的组件透视图)

LeSS由Craig Larman和Bas Vodde共同设计，框架基于Scrum进行扩展，通过大大量的实践经验，糅合精益思想沉淀而成，支持企业以敏捷的方式进行大型产品研发，是一个轻量级的规模化敏捷框架。

1.3 SAFe (Scaled Agile Framework)

(图3：SAFe框架的组件透视图)

SAFe的设计和主要方法论由Dean Leffingwell主导，是另一个流行的规模化敏捷框架，特点是将敏捷实践在企业中分层而治，从团队级(Team level)到项目群级(Program level)乃至投资组合级(Portfolio leve)，糅合精益-敏捷知识体系。

二、规模化敏捷框架的11个维度分析

2.1 Scrum团队容器(Scrum Team Container)

在计算机领域对容器的解释是，容器是用来存储和组织其他对象的对象。那么在规模化敏捷框架上下文中，Scrum团队容器(以下简称团队容器)是指在框架中用来容纳敏捷团队的一个对象，在规模化敏捷框架并没有清晰地定义出这个概念，但笔者认为它是存在的，它很显式地体现在框架的组织设计当中，在框架设计时是抽象的，在实践以组织架构形式实例化。所以可以这么认为，团队容器就是一个企业的组织架构。规模化敏捷的组织架构设计与传统组织有很大的区别，企业要扩大敏捷的范围，自然会涉及更大范围的的组织变革，所以每一个规模化框都会有组织变革措施，但企业组织变革往往是规模化敏捷最大的障碍，因为企业的组织架构就是它的中枢神经。组织变革的过程就像科幻片里的情节，人类研发并植入外星的基因，想创造出新的物种，目的都只有一个，就是为了更好地活下去。同样，在企业规模化敏捷上下文中，我们可以把企业组织看作一个系统，敏捷就是一种新型基因，当我们尝试植入这种基因时，组织自有的免疫系统开始可能会产生抵触，极端情况甚至是会产生抗体消灭新来基因，如果适应下来后，双方会很好地融合形成新的物种。

清楚团队容器的设计逻辑能更好地帮助你在实践时设计出适合组织的价值生产单元，采用不同的设计逻辑会直接影响组织的沟通机制和沟通饱和度，这两个是组织设计的重要指标。组织设计是一门科学和艺术，如果可以掌握就可以设计自己的组织结构，提高组织适应性。倘若我们并不想去设计组织或者还不具备这种能力，那么了解现有框架设计者的逻辑也会有所帮助。所以笔者认为团队容器是一个十分重要的概念，无论你是规模化敏捷实践者或管理者都需要去了解。

注：
*本文默认读者已经对Scrum有一定的知识基础，所以不会对Scrum做额外的知识普及。

2.1.1 Scrum@Scale Team Container

Scrum@Scale的团队容器设计十分特别，也是它的核心，所以这节会以较大篇幅去分析。从下图可以看到，Scrum@Scale组织结构里Team的最小单元是一个Scrum团队，一个Scrum of Scrum(下称SoS)的最结构是小于等于5个Scrum团队，再上一层的SoSoS也是同样的规则，可以有多层的SoSoSoS…..,所以Scrum@Scale的这种网状组织结构是可以支持无限大团队。至于为什么它设计的单元是5呢？背后的设计逻辑稍后会再作分析。

Scrum@Scale这种组织结构让人感觉和LeSS与SAFe都很不一样，后两者对于团队容器都有一个很清晰的容量限制，SAFe有ART的限制，LeSS也有Team的人数限制，后两者要突破限制就要添加新的Role和规则来平衡沟通的效率，本文的沟通饱和度一节会对这种设计进行详细分析。

(图4：Scrum@Scale的组织设计进化透视图)

(图5：Scrum@Scale会有不同的组织结构实现形式)

Scrum@Scale框架是Scale-Free network的仿生设计，这种设计能更适应更快速的组织发展和功能开发响应，理论是基于无尺度网络模型，这种网络在实现中普遍的存在，如神经网络、社交网络、航空网络等。

(图6：Scrum@Scale以Scale-Free network设计的实现)

The Executive Action Team(EAT)组织内只有一个，有些组织可能叫精益/战略转型等类似的名称。

对组织中Scrum的质量负责；
拥有组织转型战略；
拥有转型代办清单和清除阻碍转型的所有障碍；
消除由于范围，预算或公司政治权力而未在团队级别处理的障碍；
执行转型战略或将其委托给专业部门(通常称为敏捷实践)；
测量并提高组织中Scrum的质量，以构建业务敏捷性的能力；
敏捷践行小组(Agile Practice)，十分重要，它是企业内推行敏捷的组织，Scrum Master会向这个小组汇报。Agile Practice成员也是EAT成员，负责推动敏捷实践，这样自上而下的推动，才能保证敏捷不只是以形式留存于基层。

(图7：Scrum@Scale的Meta Scrum几种组织形式)

MetaScrum：

这个组织要说明一下，是所有PO和利益相关者的容器，从SoS的Team层开始他就有，直到企业执行官层(EMS)都存在，这个组织在不同层次有不同的企业成员，重要的一点他们也是一个Scrum团队，职责如下：

Executive MetaScrum(EMS)：

管理层成员(CPO、 CEO、CFO、CCPO)拥有组织愿景、识别价值流、设定组织优先级

CCPO MetaScrum：

设置多个团队组(可以理解为所有的产品线)的优先级，产品澄清、识别价值流、跨团队协调。

2.1.2 LeSS Team Container

(图8：LeSS的团队容器)

LeSS的团队容器十分特别，是由1个Product Owner、多个Scrum Master和Scrum Team组成，设计是通过系统思考的方式推理和优化出来的。LeSS只扩展Dev Team，整个组织的上限是50人(再大就会是LeSS Huge，本文不会展开)。LeSS建议Scrum Master全职同时支持两个团队，这样可以得到不同团队的视角，更好地提高团队的适应性。当然，如果Scrum Master的能力足够，可以支持更多的Scrum Team。

另外，LeSS很强调产品的定义，组织的设计是为了更好的支持产品的迭代和适应性。而产品的定义又涉及投资组合、DoD(完成的定义)等因素，所以清晰的产品定义是团队容器的基础。

Team Design vs. Coaching，可以看到花成本去设计好组织结构比教练团队，得到的回报会更高。

( 图9：Team Design比Coaching Team更重要)

2.1.3 SAFe Team Container

( 图10：SAFe在TEAM层的团队结构)

SAFe的团队容器在框架的TEAM层，容器里有多个Scrum团队和看板团队。SAFe的TEAM层会有多个Product Owner和Scrum Master，并没有强调和限制使用特定哪一种形式的团队，水平扩展多个多功能团队，直到到达上限150人(包括所有人)。SAFe以层级的设计思路，层间的沟通问题通过引入新的角色去解决。团队容器抽象为一列敏捷发布火车(Agile Release Train)ART，在框架的PROGRAM层，用火车来比喻十分形象，一列火车承载着所有团队成员和要交付的产品价值，这也是SAFe中最大的特色。SAFe在各层之间还有一个系统团队(System Team)，它是一个共享的资源团队，如类似架构团队和设计团队等，在同层是用火车来承载，跨层是用System Team来承载。

2.1.4 小结

通过对比我们可以看到三个框架的组织结构设计都有它的思路，Scrum@Scale以仿生Scale-Free架构设计理论依据，支持可无限扩展的组织。LeSS在小范围内达到极致，到达一定极限后扩展成Huge。SAFe在到达一定上限时扩展多个ART和RTE。三者都以Scrum作为团队基础单元，LeSS的结构更像是Scrum@Scale的其中一种实现。

每个组织都有它自运转的生态和惯性，这个生态我们称它为系统，它的惯性我们称它为心智模式。系统的组织结构是它运作的核心，是管理者十分关注的一个维度。系统有它的心智模式，当我们要对系统进行变革的时候，它自然会产生抗体，所以变革的阻力就在于系统的惯性，然而我们实践者往往要做的是这个核心的变革工作。

组织结构的设计逻辑直接影响实践者实施的难度，那么我们该如何选择框架为企业赋予敏捷的属性？作为一名敏捷教练如果理解了框架背后的逻辑和设计原理，那么我们就能更加容易做出正确的决策，在实施组织变革时的成功机会也会增加。

Scrum@Scale认为如果一个系统没有自生态的机制，那么当它发展到一定体积后就会慢下来，对于组织管理和设计者来说，也是有必要考虑的因素。LeSS发展到一定体积后要切换到Huge模式，SAFe的ART到达150人后也需要更多的RTE建立沟通机制，这种进化也必然要引入新的资源配套，倘若系统天然就支持和具备快速进化发展的机制和基因，就能减少系统在决策和申请资源时的消耗，Scrum@Scale以Scale-Free的架构设计就具有这种天然的基困。

2.2 角色(Roles)

Scrum@Scale和LeSS并没有新增角色，他们都是Scrum的角色，LeSS对Product Owner的能力要求提到了一个新的高度。SAFe在Scrum的角色基础上添加了一些新的角色，由于章节篇幅问题，不再一一展开。RTE（Release Train Engineer）是SAFe中一个重要的角色，主导SAFe的一个核心活动PI Planning。Scrum@Scale虽然没有加新的角色，但对原有Scrum Master角色职责有所扩展。

2.2.1 Scrum@Scale Roles

Scrum@Scale并且没有引入新角色，但对Scrum Master和Product Owner有了新的职能扩展，扩展后的每日站会叫Scale Daily Scrum (SDS)。SDS里关注和讨论的问题也有变化，不再是原来Scrum里的三个问题，SDS要处理更多的是团队之间的依赖问题，只有把团队尽可能的解藕才能提升整个组织的适应性，这种变化在几个框架中只有 Scrum@Scale把这项工作明确地固化在一个角色的每日工作当中。

( 图11：Scrum@Scale中SDS团队层面的每日站会结构）

扩展Scrum Master，Scrum of Scrums Master（SoSM）：

共享和清除障碍
知识分享和标准化
讨论和解决依赖
SoS作为发布团队，发挥作用

Scale Daily Sccrum(SDS)，同样是站会，但三个问题可能不一样：

我的团队有什么阻碍令到我们无法完成Sprint目标的？
我的团队是否有影响到别的团队完成Sprint目标？
我们是否有发现新的依赖或者找到一种减少依赖的方法？

扩展Product Owner：Chief Product Owner, Chief Chief Product Owner。

在MetaScrum里CPO是一个主导者，MetaScrum是一个负责产品级别的团队，Scrum对Product Owner的要求不低， Scrum@Scale的要求更高，CPO要负责引导MetaScrum产品级别的会议。

( 图12：Scrum@Scale中MetaScrum中的团队成员)

至此，Scrum@Scale的组织结构与其相关的Role都已经清晰，也很好理解。组织结构的设计一个重要的元素就是Role, 框架都通过Role来稳定它的设计架构。就像盖房子和大楼需要有主力梁柱，Role就是这些关键的主力支点。我们用系统思考来分析一下，每个框架自身都有他要解决问题的目标，就像一个系统，Role就是它的杠杆点。如果一个系统的杠杆点越多，我们认为可以影响它的目标因素就越多，可以推理，这个系统的抗干扰能力越弱。这里也会让人引发一些思考，为什么SAFe会不断地加入新的东西？设计者的假设是什么？Scrum@Scale和LeSS 与SAFe是两种截然不同的设计风格和思维，LeSS角色设计原则是刚好满足框架的需要就够，不多也不少。

小结

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

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

Scrum@Scale设计者在Scrum的基础上再一次突破，定义了EAT和EMS两个核心组织，以及Agile Practice和MetaScrum与两个核心组织的关系和协作方式，明确了管理层在整个敏捷组织架构中的位置和职责，是首个做到的规模化框架。LeSS角色比较简单，从框架的设计角度上是一个减法，如果企业原来组织结构扁平，那么导入Scrum@Scale或者LeSS都是比较容易的。当发展到一定规模的企业，涉及管理层的结构设计问题，Scrum@Scale就给予了这方面的支持。

2.3 系统思考(System Thinking)

系统思考是高管或者变革推动者必备的技能，能让他们从系统的高度来做决策和思考，也是一位优秀的规模化敏捷实践者必须学习的知识体系，至于系统思考为什么这么重要这里不展开，但三个框架都无一例外提及它。Scrum@Scale和LeSS都推荐《第五项修炼》一书，SAFe把系统思考作为了它的第二条原则，但在SA（SAFe Agilist）的认证课上官方并没展开系统思考。SAFe的SA设计是给管理层的上的，相信多数管理层都不具有系统思考的能力或学习过系统思考，既然这么重要的一个原则，更应该展开说明。系统思考是LeSS的第四条原则，LeSS的CLP课程你会深深感受到框架设计的逻辑，因为它就是通过系统思考推导和设计出来的，CLP课程会让学员感受框架是怎么通过系统思考设计出来的，并且明白为什么系统思考在规模化敏捷组织中这么重要。LeSS 把系统思考作为它的核心，并应用于全局的设计中，有详细的建模指引。系统思考是解决延迟反馈问题的一种处理方式，LeSS官方网站对系统思考的说明是三个框架中最详细的。

小结

“只有管理者才能去改变系统”——Deming, W. Edwards。系统思考是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要理解它这样的设计背后的原理，就要对组织的设计、产品的定义、组件团队与特性团队的协调机制等都要明白，所以课程中你会强烈感受到两种截然不同的课堂体感。

2.4 沟通机制(Communication Mechanism)

Scrum@Scale基本都是Scrum活动和SDS，没有具体的特色事件，要实践者去实践出企业最适合的方式和事件。这里听起来让人有点不适应，正常规模化框架都应该有一个沟通机制或者一个类似PI Planning这样的特色事件和工具去落地，这是我们正常的思维和心智模式。这里会带出一个问题，我们一直认为规模化敏捷就必然有一个沟通机制，那么这个论断的假设是什么？在Scrum@Scale的教程有一页让我当头棒喝。

“Add cross-team coordinating mechanisms ONLY in response to identified impediments to avoid wasteful bureaucracy”——增加跨团队协调机制只是为了应对已发现的障碍，以避免官僚主义造成浪费。

为什么要有沟通协作机制？团队不协作？或者不高效？或者这些就是我们所在的环境对你心智造成的影响，我们所处的环境可能或多或少存在官僚，所以我们论断的假设是我们都存在于这样的环境中，然而我们自己并没有察觉，笔者在学习之前也是这样的心智模式，并没有跳出系统的视角。每个系统都有他的障碍，而沟通机制的存在是为了克服和清除这些障碍，这个机制会随着障碍的减少不断地进化。所以只有组织自己才知道怎样的机制最适合它，也是Scrum@Scale设计者对自组织的最大化设计。

SAFe设计了PI Planning,最多150人，由RTE来引导，1次计划一个Scrum团队4个Sprint的Backlog，有多少个Scrum团队就有多少个Backlog和Product Owner。

LeSS设计了Product Backlog Refinement ，最多50人,由Product Owner来引导，1次计划一个团队的Backlog，尽量少的Backlog为目标。LeSS有一个特色实践，就是为了让团队提高适应性，在集体澄清需求时，可打散团队，提升广度学习能力。

小结

这一部分是笔者最想去深入理解的，规模化框架的设计一定有它特定的机制去解决沟通的问题，清楚它们设计背后的设计逻辑和度量的指标才是价值所在。SAFe和LeSS两者的沟通会议是十分相似的，都是集体Review Backlog，而Scrum@Scale的这种沟通就分散在Meta Scrum的日常当中和SDS。两者的区别是一个集中，一个分散，分散的形式与Scale-Free的设计十分契合。

因为SAFe中只是直接沿用Scrum或看板方法框架，所以实践都在其中了。而LeSS是通过实践总结出来的框架，SAFe的实践在Scrum团队的上层，而LeSS的实践是在Scrum的Dev Team中。所以他们两者表面上的不同之处就在于会议的频率、规模、形式等，但执行方式方法都是取决于他们的核心Backlog份数和Product Owner的数量。

通过系统建模推导，SAFe为什么要设计4个Spring的Backlog和一个IP，与团队的人数规模、澄清需求的成本、PO的能力、PO的数量、特性团队的专业化程度等因素相关。分析结果回答了上面的问题，SAFe使用正向思维推理的设计方式，框架开始设计时就受局限，为了平衡一些副作用，必然要牺牲适应性来换取设计的不足。Scrum@Scale采用的是分散和涌现的沟通方式，这种机制和集中式的相比似乎更加灵活。

2.5 适应性(Adaptability)

规模化敏捷框架在适应性方面，LeSS的设计已经是达到极致。通过一个案例，来说明一下框架适应性的设计，在某种场景下也有不适应的状况。中台系统*，在某种条件下，引入中台系统设计会给企业带来适应性的下降。

中台系统是互连网公司文化的产物，并不适合与它背后所承载的文化有冲突的企业导入。在激烈的市场竞争中，互联网公司为了生存，系统架构必须能够支持更短的产品研发周期、更快的产品迭代。企业的系统架构制约了自身的发展和创新的速度，为了更快的响应市场变化，产品要进行快速开发和试错。系统架构要适应企业的战略，一些共性的服务抽象出来由一个系统来提供服务，支持多个产品复用服务，从而减少重复开发带来的浪费。在这种上下文，中台系统是企业战略分解和经验积累下来的一个产物。但如果企业在一个产品都还没有做稳定的情况下，盲目追逐新概念，反而会降低企业的适应性，适得其反。

根据上面的分析，中台系统的出现必然会增加多一份属于中台的Backlog，并且企业组织还不具备高效的沟通机制，这时引入中台，就相当于增加了一个沟通壁垒。特性团队的任务要依赖中台系统，沟通成本增加，效率随之下降，适应性必然也会下降。

另一种情况是，当适应性文化已经植入到企业每一位员工的骨髓后，就能打破架框的局限，做到极致的适应性。从系统思考的角度，我们都不能看清整个事物的全貌，而企业文化的基因也是我们在设计框架时所忽略的一个系统变量。国内大型互联网公司，能够做到一个产品2个月内不赚钱，团队可以全部解散，团队成员要适应新的岗位和技能。团队成员都知道只有产品成功才能生存下去，企业能做到如此高的适应性，瓶颈就在如何发现有价值的产品上。当企业已具有高适应性的文化，能驾驭任何框架。即使大型互联网公司没有使用任何规模化敏捷框架，企业同样可以能具备高适应性的特质，正是这个原因。

规模化敏捷框架能帮助企业提升外部和内部的适应性，外部对应市场，内部对应组织。中台系统是高适应性企业的系统架构产物，经过产品的包装，呈现在给人们的信息是，企业引入它就能够提升适应性。通过上述的案例分析，如果企业想通过建设中台系统提升自身的外部适应性，但又忽视了自身内部的适应性时，整体的适应性反而会下降。

规模化模敏捷框架设计，都是以提升企业和组织的适应性为设计原则。但我们这里想讨论一下框架本身的适应性能力。一个框架是否能成功帮助企业转型，它自身的健壮性和适应性也是有关系的。企业跟随市场的变化而变，通常企业的变化比较缓慢，假如我们选择的框架适应性越强，就越能适应企业的变化，企业在调整的过程产生的成本就越低。相反，是就成企业转型的障碍。

2.6 实施路线图(Roadmap)

Scrum@Scale虽然没有明确的Raodmap，但也给出了一些建议，系统的反作用力是在所难免的，所以我们要先做容易提升的事，采用最快的方法把效率提高，争取更多的资源，支持更长远的改进工作，从而提高导入成功率。

Co-location
Small & Stable teams • Finish Early
T-shaped people
Swarming
Scrumming the Scrum • Interrupt buffer
Daily Clean

Scrum@Scale没有给出具体方案，同样需要Practitioner运用你的智慧找到组织最适合的方案。没有明确的Roadmap,因为每一个组织都不一样，可以通过以下的维度对自己的组织进行诊断，方式有两种，可以像下图用POST-IT和用维度表。

Executive Meta Scrum
Executive Action Team
Team-Level Process
Cross-Team Coordination
Continuous Improvement & Impediment removal
Strategic Vision
Backlog Prioritization
Backlog Decomposition & Refinement
Release Planning
Deployment
Product & Release Feedback
Metrics & Transparency

( 图13：POST-IT不同维度展示企业现状）

( 图14：维度表展示企业现状）

SAFe

SAFe有很清晰的Roadmap，由SPC来主导，照着走就可以。

( 图15：SAFe的实施路线图）

LeSS

LeSS和Scrum@Scale是同样的思路，只是形式不一样，在导入前大概需要1个月的前期准备，没有Raodmap，看CLP的经验和实际情况来做方案，确保首次启航成功。坚持了他一向简约的风格，也是抽象了6点。

educate everyone
define ‘product’
define ‘done’
have appropriately-structured teams
only the Product Owner gives work to the teams
keep project managers away from the teams

小结

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

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

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

Scrum@Scale给出的建议是先从两个Scrum团队开始做生态，之后就是系统自行繁衍，EAT和EMS保证系统的环境，就像一个Scrum。

在工作中我们经常会遇到一个场景，你只要给管理者计划和Paper，他们就会对项目有信心，相信项目就会按既定目标完成，一天拿不到计划似乎若有所失。从Roadmap的设计上看，SAFe对市场极具亲和力。

2.7 实践者(Practitione)

认证并不是笔者的目的，但这里也简单介绍一下。Scrum@Scale的Practitioner认证(SaSP)只要参加认证课程，通过考试就可以获取认证。Scrum@Scale Trainer（SaST）要先取得SaSP，然后要有培训经验和一个Scrum@Scale 案例，再参加5天的课程，并Show Case，通过评审之后就可以成为SaST。对于实践者来说Scrum@Scale是一个完美的框架，如果有很好的Scrum实践，Scrum@Scale会有很多可能性。作为一个SaSP，不单要掌握Scrum，更多的还要去动推动EAT和EMS。

LeSS的实践者是CLP，CLP并不需要正式的考试，只要上完课就能取得认证。课程中你能清楚理解到LeSS框架设计的原则，所以个人觉得考试与否并不重要。再高一层次是CLB和CLT，CLT的认证条件是十分严格，讲师要有真实的LeSS案例。LeSS的CLP更多的要去引导Product Refinement，使用系统思考去提高组织的适应性。

SAFe的实践者是SA，SAFe里的几个关键角色RTE、SPC等都要通过认证考试，考试过程会让你更加理解SAFe框架。SA再高一层是SPC，SPC要关注整个框架的运作，关注价值流和ART。

三个框架认证之后，笔者有如下感受。Scrum@Scale认证后，感觉LeSS就是它的一种实现形式，框架的设计接近完美。LeSS认证后，你会明白他设计的原理和了解到系统思考。SAFe认证之后，个人需要更完整的知识体系才能理解框架。对于实践者来说Scrum@Scale和LeSS是相对容易接受，而SAFe是管理者相对容易接受，观点与角度不一样。

2.8 DevOps

DevOps在企业级敏捷中已经是一个不可或缺的基础能力，企业能够做到功能按需发布、快速获取用户反馈、持续改进。DevOps从SAFe 4.5版本正式加入，并且有它自己的一个DevOps认证SDP。而LeSS和Scrum@Scale并没在框架中提及，DevOps应该是由Team去肩负起来，这种原则和思维方式已经融入到框架之中，所以在框架中并没有明确声明。

2.9 Product Owner

Product Owner在每一个框架中都是关键人物。SAFe中有它领域内的认证POPM。LeSS与Scrum@Scale并有没额外的PO认证，但后者对PO的能力要求并不低于前者。LeSS一个PO要支持50人的团队，大概7个Scrum团队，对PO的能力要求极高。在CLP的课程中会有一个篇幅去讲产品的定义，笔者清楚记得当时问了讲师一个问题。为什么要讲产品的定义？这个系统变量也是通过系统思考推导出来的，因为PO对产品定义不清晰，会影响整个团队的目标实现。

Scrum@Scale的Meta Scrum里PO更是需要有导引能力，并且与SM互补和有交集，扩展了PO的职责，识别价值流，引导会议等。通常我们衡量一位PO的指标都是直接与他负责的产品挂勾，相信每一个人都有追求卓越的心，但我们往往忽视了PO们所处系统的环境，环境影响了心智模式。我们是否为PO提供了可持续发展的空间和环境。

2.10 沟通饱和度(Communication Saturation)

上表列出三个框架各自有特色的设计和活动，它们之间似乎都没有很大的关系。但笔者发现它们背后要平衡的是一个指标，就是沟通饱和度。如果我们从沟通饱和度的维度来看这些设计，就会发现这些设计和活动之前的关系。沟通是团队协作过程中最大的成本之一。Scrum设计之初，Jeff在他的书中（《敏捷革命》/《The Art of Doing Twice the Work in Half the Time》）第三章团队规模一节，就提及设计Scrum团队人数时考虑的就是这个指标。另外，在学习Scrum@Scale的Slide Deck时候也发现这个线索暗中贯穿整个框架。

( 图16：沟通饱和角色数量关系图)

( 图17：Jeff Sutherland的一条推文）

( 图18：Software Engineering Institute的论文)

三个框架都以不同的形式去找到团队沟通饱和度的平衡点，如果我们明白框架背后的逻辑那么我们就可以去设计我们自己的机制，团队沟通饱和度越高那么团队共享的知识就越多，需求就越明确。但要达到这种状态是需要成本的，工作时间不可能全部用于沟通，即我们的沟通饱和度不可能达到100%。假若我们想要沟通饱和度达到50%，那么这个机制的形式可能会有几种方式，要么一次达到50%，如开一个集体澄清会议（PI Planning）；或者我们加大沟通的频率，但每次沟通的时间变短；或者我们使用不同的频率和节奏；都能达到同样的沟通饱和度。

SAFe的PI Planning属于大型的沟通，所以频率不能高。LeSS的Backlog Refinement相对人员较少并且只设置1个PO，可以以迭代频率进行。S@S以5个为一组的SoS，多层SoS的Scale Daily Scrum，可以每天都进行同步。下图的例子是2000人的组织能在1.25小时内完成同步沟通。以上事件都是为了提升沟通饱和度的，但框架的组织结构设计不同就有不同效率的区别，和不同的沟通表现形式。

( 图19：SAAB的案例)

2.11 原则(Principles)

Scrum@Scale就是Scrum，它的原则就是Scrum的原则。

( 图20：三个框架的原则示意图)

框架的原则让人思考到敏捷原则，通常都有一种共识，做事不拘于形式，只要我们按原则做事件，就能标签敏捷和框架。框架的原则也是笔者想去推敲的事情，由于篇幅问题，我们只可以在这里简单思考一下。如果把框架看作一个有机的生态系统，那么这些原则也是就是它的变量。规模化敏捷框架重要的一个目标是提升组织的适应性，这个观点我相信是正确和成立的。那么这些变量是如何杠杆框架的目标的呢？给大家一个思考的空间。

三. 结束语

所有的框架课程都是设计给Management去参加的，规模化敏捷是否成功取决于决策者的决心和智慧，框架对管理者的能力要求非常高，甚至连管理者都没有意识到，自身将要面对的改变幅度之大、范围之广，所面临的障碍是如此巨大。管理者要有所觉察，改变的不单是企业，更多的是自身。需要管理者有紧迫感、使命感、领导力、勇气和决心。至于每一个企业的决策因素都是复杂的，对于决策者们无论选择哪一个框架都是基于成功率最大的基础之上，因为失败的风险对管理者来说是不能接受的事实。

框架设计者的背景，他们所追随和认同的科学理论，直接影响着框架的设计风格特点。本文通过从不同维度来呈现规模化敏捷框架的设计逻辑，从中试着抽象和提炼出共性，希望能为企业在框架选型时提供多一份的参考。敏捷有不同的派系和理论的信奉，业界存在多样性是创新的源动力。本文可能未能做到观点的中立和完整的剖析，也必须承认笔者的视角并不完整。因此，希望能在尊重和理解的前提下，通过交流和探索互相刷新心智模式，并希望本文对正在学习或将要学习规模化敏捷框架的你有所帮助。

注解：

*ART：Agile Release Train
*Scrum的组成：Dev Team 、Product Owner和Scrum Master
*中台系统：支撑前端和连接后台的一个中间层系统

引用：

【1】图8*，吕毅：https://blog.odd-e.com/yilv/2017/06/team-first-or-organization-first.html
【2】LeSS系统思考说明官方网址：https://less.works/less/principles/systems-thinking.html
【3】SAFe系统思考说明官方网址：https://www.scaledagileframework.com/apply-systems-thinking
【4】《待办列表的份数-终极杠杆》，吕毅：https://yihuode.io/articles/335