LeSS简介
Scrum开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作，一个建议的数值通常是7加减2人，这样既可以保持敏捷性又可以在Sprint内交付潜在可发布的产品增量。
对于小规模产品，1个Scrum团队也许可以很好的应付，然而现实中大规模产品开发时常常会涉及到多个团队协同开发一个产品。
如果我们继续采用Scrum的方式进行产品研发，我们就不得不需要思考一个问题：不同团队如何一起有效的合作完成一个产品的开发？
行业里目前有一些大规模敏捷的解决方案，如 Large Scale Scrum（LeSS）， Scrum of Scrums， Scaled Agile Framework（SAFe）， Disciplined Agile Delivery（DAD），NEXUS等等。这里简单介绍一下LeSS这个框架，当年在NOKIA的时候用的就是这套框架。
“LeSS is Scrum applied to many teams working together on one product.”简单说LeSS依然是Scrum，依然是那三个角色，三个工件，五个会议。LeSS框架想要解决的问题是如何将Scrum的原则，元素尽可能简单够用的使用到多个团队，合作开发一个产品的场景里去。
LeSS框架分为两类：LeSS以及LeSS Huge，超过8个Scrum团队的时候使用LeSS Huge框架。不要问我8是怎么来的，就这么定的，当然在实践的过程中需要考虑产品负责人以及Scrum团队成熟度适当调整，理论总是要联系实际。
LeSS框架
LeSS实践
笔者去年的时候接手了一个研发团队，准备开发一个公司内部DevOps研发平台产品。团队成员包括3个前端JS开发，9个后端JAVA开发，1个测试，1个交互；前后端分离设计，前端基于React，后端基于SpringBoot；团队成员几乎不懂敏捷开发，Scrum以及LeSS等。如果是你，你会如何开始？
没有合理的团队设计让产品研发事倍功半，而有了合理的团队设计让团队事半功倍。团队设计是影响团队绩效的一阶因素。团队设计简单说包含两方面考虑，一个是团队自身结构的设计，一个是团队间沟通协调方式设计；团队自身结构设计上通常有两种选择：组件团队或特性团队。
在组件团队模式下需求拆分为组件子需求，往往一个需求会涉及到多个组件团队，通常会产生以下一些影响：
组件团队缺少产品整体视角，关注组件交付而非客户价值交付；常见的句式是：“我的做完了”。
组件团队通常资源共享，关注资源效率，而非价值交付效率。当一个组件团队服务多个业务方的时候，往往容易导致组件团队陷入公共绿地的困境，不用白不用，白用谁不用，各个业务方拼命争夺组件团队资源，在整体沟通信息不顺畅的时候，一个潜在的结果是最会哭最会喊的那个业务方需求获得了资源，而不是对于公司或客户最有价值的业务方需求获得。
组件团队组织产品研发时通常也会采用项目制开发模式，从各个组件团队抽调资源，组建短期项目团队。不同的PM，不同的团队成员，不同的做事风格，不同的项目复杂度，不同的完成标准，不否认有非常牛X的项目经理带领非常牛X的团队完成非常牛X的项目，但整体上看，往往整个项目进度，质量，效率不稳定可控。同时在短期的项目团队里，人往往被视作实现项目目标的一个资源，成员工作动力不足，高效的团队是需要长时间磨合的。
项目制方式加上关注资源效率，通常产生的一个现象是团队/个人多任务并行。适当的并行可以提高团队的吞吐量，但同时会延长客户价值交付周期。当并行超出某一个限度的时候往往会导致整体质量效率下降。在一定程度上这是一个投入产出比平衡的结果。
跨组件团队沟通时需要非常清晰明确的公司策略，产品优先级等信息支持，才能更好的协调多个团队协作开发。但现实的情况往往是整个信息不够透明。另一方面团队都会有自己的屁股，有做大做强自己组件的冲动，往往导致跨团队沟通协调成本高。
在沟通协调不顺畅的情况下，往往会产生强烈的项目管理需求。笔者曾见过比较极端的case，一个人半天代码量的需求，前前后后花费了不同团队10个人讨论了3天，最后在外力的介入下才拍板。
客户价值匹配组件团队技能，而非团队技能匹配客户价值；当某一组件需求集中涌现的时候，容易产生扩大团队的冲动；当某一组件团队高优先级需求不足的时候，并不会缩小团队规模，反而会找活做，容易导致低价值交付，后果是不断扩大的组件团队；
在某些组织里经常会看到组织调整，一个原因就是不断扩大的组件团队，导致研发成本不断攀升，但研发成本攀升的同时并没有实现同等客户价值价值交付，投入产出比降低，所以需要动一动，也算是一种应对的方式，只是这种变化通常更剧烈一些。
当需求被拆分到各个组件团队后，带来的另外一个后果是后期集中集成，集中测试，反馈周期往往拉长，并且将风险留在最后，往往导致项目延期，交付周期变长。
相对于组件团队，特性团队：
长期稳定存在，长期的合作利于打磨高效团队，质量和效率稳定可预见。
跨技能，团队成员技能中包含前端，开发，测试等多种技能。
跨组件，团队覆盖的范围同时横跨多个组件。
团队能独立完成客户价值交付。
团队间协调合作从项目管理域转移到代码技术域。
当然特性团队也带来了一些挑战：
每个人都需要掌握所有东西？整个团队需要拥有产品交付的所有技能，并在客户需求开发过程中不断学习扩大个人技能领域，这是一个长期的过程，取决于团队学习的能力。BTW：在现在以及未来的千变万化的社会中，无论是个人还是团队，学习能力将是一个非常重要的能力。
如何保证组件代码质量？需要工程实践上的配合，例如主干开发，持续集成，保证产品不被破坏；组件守护者，review组件相关修改，技能指导；不同人从产品交付的角度修改组件促进代码学习以及程序员社交。
整体上特性团队对外更加关注客户价值价值，促进创新；对内打破团队边界，促进组织转型升级；对个人促进个人学习，提升个人技能。
敏捷原则之一“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”对于一个从0到1的产品，持续不断的满足客户需求，持续不断的从客户收集反馈对于产品来说非常重要，特性团队更适合当前的产品研发场景。笔者选择组建了三个特性团队，每个团队4人，其中包含前端开发，后端开发，可以独立完成产品需求交付。
团队自身结构设计好了，接下来需要考虑团队间沟通协调方式。团队间沟通协调方式会受到产品需求组织方式的影响。团队将要开发的DevOps平台是一个非常复杂的产品，涉及的需求领域很多，比如环境管理、应用管理、版本管理、持续集成等，同时这是一个从0到1的过程，每个需求领域都有着充足而稳定的产品需求，并且每一个领域都需要一定的领域背景知识才能更好的设计实现产品，所以笔者决定划分为4个产品需求领域：环境，应用，版本，持续集成。
在LeSS里是没有需求领域的，需求领域是LeSS Huge里的概念，当团队个数大于8个的时候建议使用LeSS Huge，并且区分需求领域，每一个需求领域里依然是LeSS工作方式，同时增加APO角色负责一个需求领域。
笔者虽然只有3个特性团队，但依然选择划分了需求领域，这点和LeSS有所不同。笔者的考虑是团队个数是一个划分需求领域的参考，同时产品复杂度和产品所处的阶段可能也是需要考虑的一个维度。
在LeSS里不区分需求领域的情况下，每一个特性团队在一定程度上是等同的，提供最大的灵活性。需求领域的划分在一定程度上降低了团队跨需求领域的灵活性，但是在当前产品初期从0到1的情况下，每个领域高优先级需求充足而稳定，足以保证每一个特性团队持续的高价值交付，团队的跨领域灵活性暂时不是笔者考虑的最主要的问题。
最终团队整体设计如下图所示，一份产品待办列表，划分四个需求领域，每一个需求领域由一个特性团队负责需求，特性团队中包括前端开发和后端开发，其中特性团队C负责两个需求领域。
这在一定程度上即保持了产品特性团队的特征，又减缓了特性团队在工程实践上带来的挑战，当然也牺牲了一定的团队敏捷性，这是当下的选择。
需要指出的是，团队的结构设计不是一成不变的，随着产品的演进，需求领域不断的涌现和消亡，团队的结构设计也是随着时间调整的，未必一个团队就只能工作在一个需求领域，或者一个需求领域只能一个团队工作，甚至是否还需要需求领域划分，这是需要根据现实的情况来调整的。
完成了团队自身结构设计以及产品需求组织结构设计之后，那么团队之间如何在LeSS框架下协助完成一个产品从0到1的开发呢？敬请期待大规模敏捷开发框架LeSS实践（二）。
总结
简单总结一下，Scrum是敏捷世界里广泛使用的一个框架，简单，易懂但难于掌握。LeSS是大规模敏捷开发世界里一个常用的框架，它的本质上依然是Scrum，它想要解决的问题是如何将Scrum的原则，元素尽可能简单够用的使用到多个团队，合作开发一个产品的场景里去。
在LeSS框架里，很重要的一点在于团队设计。记得以前去拜访一个公司，公司领导介绍了公司的组织结构，交流中我会问他一些潜在的问题点，他会很惊讶于你怎么知道？组织的很多问题根源在于组织结构设计，相同的结构设计上往往存在相同的问题。没有合理的团队设计让产品研发事倍功半，而有了合理的团队设计让团队事半功倍。团队设计是影响团队绩效的一阶因素。BTW：世界上没有所谓的最佳实践，没有所谓的银弹，有的仅仅是在特定的上下文里合适的实践和方法。