十分钟了解规模化敏捷LeSS

00 前言

LeSS的第一次学习是在2019年1月份，当时的感觉挺烧脑，对SystemThinking第一次接触，很多东西似懂非懂，学的并不是很扎实。幸运的是，两年后终于有机会跟着吕毅老师重修LeSS，也算是对知识的重新回炉了。

第二次参加培训，对于LeSS的更细致内容以及运用System Thinking来思考LeSS背后的深层机理有了更深的认识。按照个人学习习惯，照例还是会在培训后写一篇文章作为学习的总结。

特别强调一点，不是说自己有多勤奋，而是想通过输出倒逼输入。大家知道，很多培训因为在短时间内灌输了大量知识，所以当时大部分的内容只是浅层记忆，虽然觉得有收获，但是过几天就忘得一干二净了。而如果培训后没有做进一步的整理，知识没有形成体系化变成自己脑袋里的东西，最终只是竹篮打水一场空。所以我也只是强迫自己做一些整理工作，不然就没有动力再进行复习了。

01 LeSS由来

LeSS的全称是Large-Scale Scrum的缩写，是由Craig Larman和Bas Vodde提出的。在2005年左右，Bas还是诺基亚西门子通信公司（简称诺西）的雇员，当时的诺西正在经历从传统开发向敏捷开发转型的时期，而Craig作为其中一名外部敏捷教练被应聘到诺西帮助进行敏捷转型。

Craig一开始准备了当时流行的各种轻量级开发框架介绍对诺西的各个团队进行简单的培训，这些轻量级开发框架包括DSDM、XP和Scrum等。然后Craig让团队自己选择需要采用哪种框架。最后，有80%以上的团队选了Scrum，原因很简单，Scrum是相对比较简单的框架，而大家都想挑简单的做。

确定好Scrum后，Craig和Bas又面临一个新的问题。因为Scrum推荐的团队人数是5-9人，而诺西当时的产品团队少则几十人，多则几百人，这种情况该如何更好的采用Scrum使得既能支持数百人的团队规模，又能保持Scrum的轻便性呢?

于是Craig和Bas在敏捷转型期间做了大量的实验（600多个实验），有些实验有效，有些实验无效。他们俩根据这些实验总结提炼出了一套适应于大规模敏捷被称之为LeSS的方法，并写成了两本书，一本叫《精益和敏捷开发大型应用指南》，一本叫《精益和敏捷开发大型应用实战》。

然而之前的著作主要是分享LeSS具体的试验成果，比如哪些试验可以采纳，哪些试验需要避免，这对于习惯于先了解总体后了解细节的人们来说有点难入门。因此两位创始人进行了反思，并且认可了“守破离”的方式，于是他们设计出了今天我们所看到的LeSS框架。

02 LeSS全图

我们只有了解完LeSS的历史后，才能对LeSS全图有更深刻的理解。

LeSS全图分为四个层次，最外层是试验，也就是上面提到的Craig和Bas在LeSS实施期间做了600多个试验来验证；往里面一层是指南，两位创始人总结了大概50多个指南，并在他们的第三本LeSS著作《大规模Scrum：大规模敏捷组织的设计》中进行详细介绍；再往里一层是框架，接下来我们会对LeSS框架进行详细的讨论；最里面一层是原则，Craig和Bas把LeSS设计的核心思想提炼了10条原则，我们将在下个小节介绍。

03 LeSS原则

LeSS的原则一共有10条，我们可以把它们分成三类：

与Scrum相关

大规模Scrum也是Scrum——它不是新的被改进的Scrum

透明度

经验性过程控制——Scrum本身就是基于经验性过程控制

LeSS自身相关

以少为多——不想要增加更多的角色，因为会导致团队的责任感变弱；不想要更多的工件，因为会导致团队与客户的距离更远；不想要更多的流程，因为团队对流程的所有权更弱。

整体产品聚焦——一个Product Backlog，一个Product Owner，一个PSPI，一个Sprint。

以客户为中心——专注于了解客户真正的问题并解决这些问题

Meta原则（原则的原则）

排队论

系统思维——观察、理解和优化整个系统而不是局部

精益思想

持续改进以求完美——团队需要不断地进行改进试验

04 LeSS框架

LeSS根据团队规模不同有两个框架，一个是LeSS框架，适合2-8个Scrum团队；一个是LeSS Huge框架，适合8个以上团队。虽然两个框架有所不同，但是它们还是有一些共同要点：

一个产品负责人和一个产品代办事项列表

一个跨所有团队的共同Sprint

一个可交付的产品增量

LeSS框架

让我们先来思考，当一个项目只有一个Scrum团队的时候，毫无疑问大家都比较熟悉了，在这里不再赘述。但是如果一个项目超过一个Scrum团队的范围该怎么办？很多人马上会想到，那就组织多个Scrum团队一起工作呗。（比如3个Scrum团队）

我们再来看Scrum中有个著名的“3355”的说法，也就是Scrum里面包含3个工件、3个角色、5个活动和5个价值观。那么这时问题就来了，对于多个Scrum团队一起工作，我们是需要1份总的Product Backlog还是保留3份各自Scrum Team的Product Backlog？抑或是1（总的Product Backlog）+3（每个Scrum team各自的Product Backlog）份？

到底是1还是3还是1+3？不知道大家有没有进行深层次的思考？LeSS中的答案是只有1份Product Backlog。具体原因在吕毅老师的LeSS培训中花了大量的精力从系统思维的角度分析过。

第二个问题是PO需要多少个？只有1个PO还是每个Scrum Team有各自的PO？还是说有一个总的大PO+3个Scrum Team的PO？

当然，LeSS中强调即使有多个团队，但是只能有一个PO，一个PO对应一份Product Backlog才能保证整体产品聚焦，同时可以避免多PO职责不清的情况。同理可知，一份Product Backlog只对应一个PSPI的输出。

而为了实现在每个Sprint结束后只有一个PSPI的输出，所以3个Scrum团队需要有统一的开发节奏，也就是说Sprint的开始结束时间必须拉齐，所以LeSS只能有一个Sprint；最后，如果输出只有一份交付件的话，那Sprint Review Meeting也只需一次就行了。因此我们可以从客户和产品为中心的维度拉出这样的功能条目工作流：

（1个）PO ->（1份）Product Backlog ->（1个）Sprint->（1份）PSPI ->（1个）Sprint Review Meeting

接下来我们再从团队的工作流角度来分析:

我们知道现在有3个Scrum团队，每个团队各自做自己负责的工作。我们在做Sprint Planning的时候该怎么做？

我们需要有一个所有人或者至少所有Scrum团队的代表能参加的计划会，从而使得每个团队都能了解本次Sprint的目标以及各团队知道该做什么条目，这也被称为Sprint计划一。

当然各团队领了具体工作条目后，具体的任务还需要每个团队自己回去商量，所以每个团队还会进行Sprint计划二；因此Sprint Planning变成了1+3。（如果有些需求在两个团队之间关联比较紧密的话，也可以两个团队合在一起做多团队Sprint计划二。）

接下来我们看Sprint Backlog的份数，由于我们每个团队各自都会做Sprint Planning，毫无疑问应该每个团队各自有各自的Sprint Backlog，也就是说Sprint Backlog应该是3份。

我们再看每日站会，显然各自团队可以自己开每日站会，我们没必要举办全体的站会，这会非常耗时。可能很多人会问，对于有些任务会涉及到一些跨团队协作，该怎么办？

一但碰到需要跨团队协作的事情需要实时的进行团队间沟通和协调，而不需要依赖某个固定的时间和会议再来讨论。

最后我们再看回顾会议。LeSS建议每个团队自己先开团队的回顾会议，当然有些措施可能涉及到跨团队，所以还会有一个全体的回顾会议，大家一起讨论和改进。

所以我们根据团队数量的维度来分析得到以下的团队工作流：

（多个）Scrum团队->（多份）Sprint Backlog->（1+多个）Sprint Planning->（多个）每日站会->（多个+1）Sprint回顾会。

最终，我们得到以下的LeSS框架：

LeSS Huge框架

刚才我们在上面分析到LeSS只有一个PO，这对于在团队规模不大（小于8个团队，50人以内）的情况下，PO还是勉强可以应付的。但是如果团队规模变大，比如20个团队，那对于PO一个人来说根本不可能协调得过来。

虽然LeSS不提倡随便增加角色，但是在目前这种情况下，确实只能妥协增加新的角色了。因此在LeSS Huge框架你可以看到，LeSS中唯一比Scrum多的一个角色就是Area PO（APO，领域产品负责人）。

每个APO负责某个需求领域（Requirement Area），一般一个需求领域包括4-8个Scrum团队，这样20个团队可能对应了4个需求领域，有4个APO，还有一个PO，他们一起构成了PO团队。

在产品中需求领域范围比较大且相对比较独立。关于需求领域的颗粒度大小，我们可以拿滴滴打车软件作为例子，在滴滴产品中，出租车是一个需求领域，顺风车可能是另一个需求领域。

所以对于无论是Sprint计划一还是Sprint Review会议，抑或是全体回顾会，这些我们都以需求领域作为范围来组织即可。但是从整个产品层面来说，我们只有一个PO，一份Product Backlog，一个PSPI。

这里需要补充说明的是尽管只有一份Product Backlog，但是每个需求领域可以有各自的领域产品代办事项列表“视图”，这个视图和数据库表的“视图”是挺类似的含义，也就是本质上这些视图还是属于Product Backlog，只是每个需求领域过滤掉和它无关的条目而已。

最终，你看到的LeSS Huge的框架如下：

05 LeSS启动策略

关于LeSS如果开展，官方教材给了指导方法，步骤如下：

给每个人培训

定义“产品”

定义“完成”

组建结构合理的团队

只有产品负责人为团队提供工作

让项目经理远离团队

其中第5和第6个步骤更像是rule，第5个主要是确保PO作为唯一人员为团队提供工作，使得团队能集中注意力，而且帮助团队减轻来自外部的压力；第6个主要是项目经理的责任已经由PO和团队来共同分担掉了，也就不需要项目经理了。

上面是“官方”的教程，但是个人觉得吕毅老师分享的在某个客户做LeSS实践的启动策略更加的接地气，如下图：

首先，对所有团队进行1天的培训，培训完后根据经验，一般80%的团队没有反馈，20%的团队会考虑下一步；

其次，会有一段时间的等待，需要客户内部进行讨论和准备，确定哪些项目来试行LeSS。这段时间可长可短，一般需要1-3个月；

再次，确定好试点项目后，需要进行一系列准备过程，包括1）针对试点项目进行培训；2）定义产品列表，这个可能是initial的产品列表；3）做好技术相关准备，比如单元测试框架，自动化框架，CI/CD等。这个时间大概会有几个星期。

最后，是flip阶段，大概是2天时间。可能利用半天时间进行LeSS团队的组建，然后做LeSS Sprint前的准备。两天后就正式进入LeSS的Sprint节奏中了。

06 组织应采用LeSS还是SAFe？

我们知道规模化敏捷有不同的框架，除了LeSS之外，也有SAFe、Scrum@Scale等。我在一年前写过一篇文章《规模化敏捷SAFe和LeSS的同与不同》，阐述了SAFe和LeSS在设计思维层面的相同之处以及不同的地方，这次培训让我又有了新的体会。

结合之前与不同企业交流以及咨询的经验，个人觉得LeSS适合于组织结构比较扁平或者包袱不重的企业，比如原来规模不大但现在正在扩张的企业，特别是互联网企业会更加适合。LeSS的核心理念是尽量不增加角色，这使得原来没有那么多包袱没那么多角色的组织实施起来阻力较少。

而SAFe是通过增加层级来解决规模化问题，增加层级也意味着增加角色，所以对于原本包袱比较重，组织层级比较多的企业（比如大型国企）来说，能够使得不同的人在SAFe框架中找到自己的位置，从而不会产生危机感而阻止敏捷的变革。

当然这只是一家之谈，作为一个参考信息给到大家，具体判断和决定留给各位亲爱的读者。