01-大规模scrum（Less）简介

Posted 2021-04-25 敏捷DevOps那些事儿

关注我，看更多！

字数：2060

阅读：预计6分钟

 前面写过敏捷基础系列文章，从这一篇开始会写一个关于规模化敏捷框架的系列文章，预计主要会介绍Less框架和SAFe框架，欢迎读者联系我沟通交流！

从团队级敏捷到规模化敏捷

近几年各个组织和个体讨论的已经不再是是否需要做敏捷的话题了，更多的是思考怎样更快、更好地实现敏捷转型，得到期望的价值，而团队级敏捷也被更多的人所熟知，继而大家开始把目光转向了规模化敏捷的话题，如果去抠字眼的话规模化敏捷又不等同于敏捷的规模化，敏捷规模化看起来是更大的命题，你可以结合自己的实践经验摸索出敏捷规模化的道路，也可以直接借鉴市场上已经成型的规模化敏捷框架。

在最新的（2020年）敏捷状态报告中，SAFe依然是规模化敏捷框架中市场占比最高的一个，其他的包括Less、DAD、Nexus、Scrum@scale也都占了较高的比重。不过我想把SAFe的介绍放到后面，先从Less（large-scale scrum）说起。

Less原则

关于less的信息，我印象最深的只有两句话，“less is more”、“large-scale scrum is scrum”，而这两句话恰好也是Less原则中的两个，所以我们就来聊一聊less的原则：

1、大规模scrum仍是scrum

less的基础仍然是scrum，换句话说less并不是对scrum的升级换代，而是关注在大规模的环境之下，如何更好的运用scrum框架，团队规模的扩大带来的就是结构的复杂性，继而对沟通、管理、协调、同步各个方面产生了影响，而scrum一直强调小团队运作，当团队过大时该如何应对在指南中并没有明确的描述，less希望把scrum扩展到更大的范围，所以必须对大规模团队的机制、原则进行阐述；
那么，如果您并不认为scrum那您一定也不会认可Less；

2、透明

对scrum了解的朋友应该知道，scrum的三大支柱是：透明、检视、调整，在less的原则中也同样提到了透明，只不过这个透明更多的会关注到大规模团队的层面，比如：多团队之间如何协调、如何保证信息共享以及待办事项列表是否需要有更多的变化和改建。这部分内容在后续的文章中会详细介绍；

3、以少为多

scrum之所以易上手，就是因为scrum框架本身是很简洁的，而less不希望打破这种简洁，所以less从角色、工件到流程的各个层面都只做了简单的调整，有增加也有减少，但是始终遵循以少为多的理念；

4、整体产品聚焦

要做到整体产品聚焦，各团队就要保持共同的目标，交付同一个产品，而对产品的管理要通过一个产品负责人在一个产品待办事项列表中实现，这一条原则也和上一个“以少为多”的原则相呼应；

5、以客户为中心

这句话不管敏捷领域还是其他领域都被不断的提到，而在SAFe5.0中也在强调以客户为中心，这个层面上来说less似乎比SAFe关注的更早一些，客户就是上帝，所以以客户为中心的思想是非常宝贵的，这个不只是在产品层面的体现，从需求、设计、研发、测试、运维的各个环节都应该具有这种思维和原则，服务好客户帮助客户解决根本问题，加强与客户的沟通交流，这才是产品和企业的成功之本；

6、持续改进

这一条原则已经说得太多了，从精益思想到敏捷开发再到DevOps，每个理论和实践都在提持续改进、追求完美；

7、精益思想

敏捷的起源离不开精益思想，而在less中也特别强调了精益思想的重要性，而当我们去学习精益思想时除了要学习如何减少浪费和利用管理工具实现精益管理的同时，更应该关注文化建设，比如精益的支柱是：尊重人的文化和持续改进；

8、系统思考

以前在讲团队级敏捷的话题时就聊过系统思考的重要性，局部优化带来的不一定是整体优化，甚至可能对整个系统产生负面影响，而在less中所谓的整体已经上升到多团队的规模，从整个产品的层面考虑，不管是团队结构、流程改进还是协作机制都要进行系统思考；

9、经验过程控制

经验过程控制的根本是通过不断小批量交付产品增量，获得客户反馈的同时对产品进行迭代和改进，而在less框架中期望所有的团队保持同样的节奏，也就意味着各个团队按照共同的交付周期交付产品增量，根据整体的市场反馈规划后续的方向和功能，也同时用于指导各个团队的持续交付；

10、排队论

依据排队论管理队列的长度、在制品的数量和交付的周期，以期望各个团队能够快速、高效运作，排队论必然要和系统思考相结合，从更高的层面考虑队列的合理性，帮助产品交付能力的提升。

less框架设计

以上，就是less的10项原则，从原则中我们就能看出less的核心思想并不是增加很多内容，而是在精益、敏捷的基本思想指导下从大规模组织的层面更好地运用scrum，那既然提到了大规模，这里先澄清下less的设计；

less其实分为了less和less huge两个框架，less关注的是2-8个团队的规模，而当超过8个团队一起协作时就要参考less huge框架进行运作了，为什么是8个团队作为分界线，用less官方的话说这是一个通过经验和试验总结出来的数字，或许您的数字是9也未尝不可，两个框架具体有什么区别会在后续进行讲解，下一节我们就来看一下less的基本结构是什么样子的。

作者简介，杨久成

某商业银行PMO

敏捷、DevOps实践者，培训师！

 

欢迎联系我深度交流！