前 言

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

第二次加入培训，对于LeSS的更粗疏内容以及使用System Thinking来思考LeSS背地的深层机理有了更深的意识。依照集体学习习惯，照例还是会在培训后写一篇文章作为学习的总结。

特别强调一点，不是说本人有多怠惰，而是想通过输入倒逼输出。大家晓得，很多培训因为在短时间内灌输了大量常识，所以过后大部分的内容只是浅层记忆，尽管感觉有播种，然而过几天就忘得一尘不染了。而如果培训后没有做进一步的整顿，常识没有造成体系化变成本人脑袋里的货色，最终只是竹篮打水一场空。所以我也只是强制本人做一些整顿工作，不然就没有能源再进行温习了。

一、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框架。

二、LeSS全图

咱们只有理解完LeSS的历史后，能力对LeSS全图有更粗浅的了解。

LeSS全图分为四个档次：

  • 最外层是试验，也就是下面提到的Craig和Bas在LeSS施行期间做了600多个试验来验证；
  • 往里面一层是指南，两位创始人总结了大略50多个指南，并在他们的第三本LeSS著述《大规模Scrum：大规模麻利组织的设计》中进行具体介绍；
  • 再往里一层是框架，接下来咱们会对LeSS框架进行具体的探讨；
  • 最外面一层是准则，Craig和Bas把LeSS设计的核心思想提炼了10条准则，咱们将在下个大节介绍。

三、LeSS准则

LeSS的准则一共有10条，咱们能够把它们分成三类：

1）与Scrum相干

  • 大规模Scrum也是Scrum——它不是新的被改良的Scrum；
  • 透明度；
  • 经验性过程管制——Scrum自身就是基于经验性过程管制。

2）LeSS本身相干

  • 以少为多——不想要减少更多的角色，因为会导致团队的责任感变弱；不想要更多的工件，因为会导致团队与客户的间隔更远；不想要更多的流程，因为团队对流程的所有权更弱。
  • 整体产品聚焦——一个Product Backlog，一个Product Owner，一个PSPI，一个Sprint。
  • 以客户为核心——专一于理解客户真正的问题并解决这些问题。

3）Meta准则（准则的准则）

  • 排队论；
  • 零碎思维——察看、了解和优化整个零碎而不是部分；
  • 精益思维；
  • 继续改良以求完满——团队须要一直地进行改良试验。

四、LeSS框架

LeSS依据团队规模不同有两个框架，一个是LeSS框架，适宜2-8个Scrum团队；一个是LeSS Huge框架，适宜8个以上团队。尽管两个框架有所不同，然而它们还是有一些独特要点：

  • 一个产品负责人和一个产品代办事项列表；
  • 一个跨所有团队的独特Sprint；
  • 一个可交付的产品增量。

1）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框架：

2）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的框架如下：

五、LeSS启动策略

对于LeSS如果发展，官网教材给了领导办法，步骤如下：

  1. 给每个人培训；
  2. 定义“产品”；
  3. 定义“实现”；
  4. 组建结构合理的团队；
  5. 只有产品负责人为团队提供工作；
  6. 让项目经理远离团队。

其中第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节奏中了。

六、组织应采纳LeSS还是SAFe？

咱们晓得规模化麻利有不同的框架，除了LeSS之外，也有SAFe、Scrum@Scale等。我在一年前写过一篇文章《规模化麻利SAFe和LeSS的同与不同》，论述了SAFe和LeSS在设计思维层面的相同之处以及不同的中央，这次培训让我又有了新的领会。

联合之前与不同企业交换以及征询的教训，集体感觉LeSS适宜于组织构造比拟扁平或者包袱不重的企业，比方原来规模不大但当初正在扩张的企业，特地是互联网企业会更加适宜。LeSS的核心理念是尽量不减少角色，这使得原来没有那么多包袱没那么多角色的组织施行起来阻力较少。

而SAFe是通过减少层级来解决规模化问题，减少层级也意味着减少角色，所以对于本来包袱比拟重，组织层级比拟多的企业（比方大型国企）来说，可能使得不同的人在SAFe框架中找到本人的地位，从而不会产生危机感而阻止麻利的改革。

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

起源：晨小菜
作者：陈晓鹏

3月每周四晚8点，IDCF【冬哥有话说】将解读四位国内大咖的经典演讲，一起精进#麻利#DevOps。
第4期，今晚8点，王立杰老师解读规模化麻利SAFe联结创始人Dean Leffingwell《业务麻利，博得数字化时代》。关注公众号回复“牛上加牛”获取直播地址哦~