洞悉规模化敏捷框架S@S、LeSS、SAFe(下篇)

        前面我们分享了《洞悉规模化敏捷框架》上篇和中篇，本篇是文章下篇，将继续从其他维度分析规模化敏捷框架。

点击链接阅读：

《洞悉规模化敏捷框架》 上篇

《洞悉规模化敏捷框架》  中篇

正文

2.7	实践者（Practitioner）

        认证并不是笔者的目的，但这里也简单介绍一下。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时候也发现这个线索暗中贯穿整个框架。

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

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

( 图19：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小时内完成同步沟通。以上事件都是为了提升沟通饱和度的，但框架的组织结构设计不同就有不同效率的区别，和不同的沟通表现形式。

( 图20：SAAB的案例)

2.11	原则（Principles）

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

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

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

3. 结束语

        所有的框架课程都是设计给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

本文作者孔兆祥，由Jim Wang审校

版权所有，反对抄袭，欢迎转发。

转载请联系ShineScrum捷行。