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

Posted 2023-05-13

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了洞悉规模化敏捷框架S@S、LeSS、SAFe(中篇)相关的知识，希望对你有一定的参考价值。

参考技术A 上篇说到规模化敏捷框架和从Scrum团队容器(Scrum Team)维度分析规模化敏捷框架。文章分为上中下三篇。本篇是《洞悉规模化敏捷框架》中篇，从其他维度分析规模化敏捷框架。如果你对本文和规模化敏捷有其他见解，欢迎留言与作者互动。

点击阅读：洞悉规模化敏捷框架上篇

正文

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把这项工作明确地固化在一个角色的每日工作当中。

( 图10： 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产品级别的会议。

( 图11： 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

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

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

SAFe

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

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

LeSS

        LeSS和Scrum@Scale是同样的思路，只是形式不一样，在导入前大概需要1个月的前期准备，没有Raodmap，看CLP的经验和实际情况来做方案，确保首次启航成功。坚持了他一向简约的风格，也是抽象了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的组织变革更倾向一次进行大刀阔斧，目的也是很明确，宁愿开始时把最花精力的事完成，之后成功的几率会大很多，使用越少的改变得到最大的杠杆效果。

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

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

未完待续，下篇更精彩。

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

LeSS is more - 大规模Scrum浅析

阅读完本文预计需要5分钟

在敏捷转型过程中，如何将在单个团队级别上取得的良好效果扩展至组织内的多团队上？启用一个有效的大规模敏捷框架是很有必要的。今天我们就来聊聊其中的一种 - LeSS（Large-Scale Scrum）。

1、为什么基于Scrum？

Scrum是一种基于经验过程控制的研发框架。其中，跨功能的自管理团队通过增量迭代的方式研发一款产品。每个Sprint都按约定交付潜在的产品增量。这种经验性的过程控制需要的是透明，而这种透明来自于团队短周期的迭代以及对迭代的定期回顾。它强调持续学习、观察以及不断适应。Scrum的整体理念基于对研发过程的复杂性、动态性做出的回应，并不断提出问题、执行及所改进。

具体的Scrum框架在此就不赘述了，想了解详情可查阅之前的文章。Scrum的有效性在于它能够将抽象的框架与实践经验相结合，从而改变组织的文化。根据组织行为学中的Larman定理，通常组织的变革是通过组织结构的改变来促使文化发生变化的，这也是Scrum能够作为有效的工具为组织带来成功敏捷转型的原因之一。

2、LeSS是什么？

Craig Larman于2002年出版了《敏捷与增量开发》一书，此时，人们还认为敏捷开发模式仅使用于小团队。而Craig及Bas从这时便开始将关注点放在了敏捷的大规模应用，尤其是将Scrum应用到大型、跨区域及外包团队的研发中。

LeSS就是Scrum，它并非对Scrum的任何更新或优化，而是一种设法将Scrum的原则、目标、元素等应用于大型语境下的方法。与我们常说的适用于一个团队的Scrum不同之处在于，它是针对多团队的，且这些功能团队是共同在同一个产品中工作，有着共同的交付目标。

LeSS is more - 大规模Scrum浅析

3、Scrum与LeSS的相同点？

LeSS是单团队Scrum的扩展版，它仍然保持了单团队Scrum中的许多规则及理念。在LeSS中你能找到如下相同点：

一份产品待办列表（因为这是针对一个产品而非一个团队的）
所有团队有共同的DoD
每个Sprint结束有同一个潜在可交付产品增量
一位产品负责人
多个完整的、跨功能的团队（不包含任何单一的职能团队）
单次完成一个Sprint

4、Scrum与LeSS的差异？

Sprint计划会议 Part 1：会议除了产品负责人外，还包括来自所有团队的相关人员。会议中，团队成员自主决定他们的产品待办列表清单（PBI）。同时共同就需要相互分享及合作的工作进行讨论。
Sprint计划会议 Part 2：各团队自行组织的sprint计划会议（通常是多团队同步进行的），会议可根据实际情况安排在相同或不同的会议室进行，亦或者同一会议室不同区域。
Daily Scrum：这个会议同样是由各自团队自行组织。但是不同团队中的成员可以作为观察员参与到有相互合作的团队的Daily Scrum中。
总体产品待办事项列表梳理（PBR）：这个梳理是可选的，且会议时间比较短（对于两周的Sprint而言，通常一个小时可以完成），它针对总体的产品代办事项。会议需要产品负责人及来自多有团队的相关人员参与。此会议的主要目的是决定后续要进行深度团队PBR的团队及条目。这是一个产品负责人与所有团队对齐信息的好时机。
产品待办事项列表梳理（PBR）：对于LeSS中的单团队PBR而言，它的运作跟单团队Scrum一样。其不同点存在于多团队PBR。在多团队PBR中，两个或者多个团队在同一个房间中讨论，增加学习及合作的机会。
Sprint Review：除产品负责人外，所有团队成员、相关的用户或者客户及干系人参与。可考虑采用集市后者科学展览的形式组织：一个大的房间，区分不同的区域。每个区域由不同的团队成员负责，向大家演示团队团队研发的功能并进行相关讨论。
总体回顾：这是一个在单团队Scrum框架中没有的会议。这个会议旨在探索总体系统中的改进点。会议时长在45分钟（针对单周Sprint）。会议包括产品负责人、Scrum Master以及来自各团队的轮值代表。