关于less:十分钟了解规模化敏捷LeSS-IDCF

前 言

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《业务麻利，博得数字化时代》。关注公众号回复 “牛上加牛” 获取直播地址哦~