Bas Vodde 和 Craig Larman 设计并介绍了 大规模 Scrum（Large Scale Scrum (LeSS)）)），一种规模化模型。
大规模 Scrum 也是 Scrum，适用于多个团队工作在同一个产品线上的情况。
LeSS 不仅仅只是一系列的原则与试验。它还提供了附有规则的框架。 LeSS 规则定义了 LeSS 是什么（以及不是什么），并且提供了应用 LeSS 的具体框架。有了 LeSS 框架，产品团队可以应用这些经验，并找到在特定时期最适合他们的方法。
LeSS 提供了两种规模 Scrum 的框架：
- LeSS：最多至 8 个团队（每个团队不超过 8 个人）
- LeSS 巨型（LeSS Huge）：同一产品线多达几千人。
InfoQ 采访了 Bas，并谈论了 LeSS 和 LeSS 巨型。
InfoQ**：您可否为读者介绍一下LeSS？**
Bas：LeSS 是一款产品开发的框架，用于两个以上团队构建同一产品的情况。框架是基于 Scrum 规则，并为建立多团队的 Scrum 做了扩展。
扩展规则包括：
- 解释了多团队如何进行 Scrum 活动。
- 主要增添了有关产品开发组的结构（我们使用“产品开发组”表示构建产品的组织或者部门）。
规则之后，我们定义了十大 LeSS 原则。
原则有三种：
- 基于 Scrum 的原则，例如透明原则或经验过程控制。
- Meta 原则，例如精益思想和系统思考，以及
- LeSS 所特有的原则，例如关注整个产品以及以客户为中心。
LeSS 还有大约 50 条指南，大多是解释在组织中如何应用 LeSS 框架以及需要什么类型的改变。
LeSS 的最后一部分是 LeSS 试验，大约有 600 条，这些都是在规模化敏捷开发时可以尝试或避免的。
InfoQ**：LeSS的核心思想是什么？**
Bas：它的实质是，LeSS 试图忠于 敏捷宣言和 Scrum，解决同一产品线上多个团队如何一起合作的问题。
在创立敏捷宣言的时候，敏捷宣言的共创者， Jim Highsmith 杜撰了“刚刚足够的方法论（Barely Sufficient Methodology）”这一短语，它同样也适用于 LeSS。现实的情况是，持续改进需要组织的所有人参与，你需要让团队拥有他们的流程。这就意味着摒弃计划与工作分开的科学管理理念。它还意味着放弃强大的、由科学管理理念演化过来的项目管理理念。
另外，我们想要管理产品是按照产品而非项目来管理。这样就会导致永久性的、长期性的团队一直拥有自己的工作并持续地改进。多个角色、工件、流程以及层次所带来的影响是团队并没有控制流程，而是流程控制了团队……在 LeSS 框架中，我们不想有更多，而是拥有少的角色、少的工件，以及少的流程。这些内容的减少意味着更多的自主权、创新、改进和更多的目的。我们把这个原则称之为不只是LeSS（More With LeSS）。
InfoQ: 将精益思想和系统思考整合在LeSS框架的原则中 ，其目的是什么?
Bas: 嗯， 精益思想和系统思考都深深地影响了我和 Craig。我想让参与 LeSS 的所有人都知道这两个思考工具，他们阐明了 LeSS 是如何工作的并有助于你解决开发中的实际问题。
在过去，精益思想和系统思考都是“思考工具”的一部分，我们在第一本书《精益和敏捷开发大型应用指南》有描述过。当我们把它反映在 LeSS 原则上时，它贯穿我们的思想从而实现真正的原则，例如“全局优化”和“相互尊重”，但我们不这样做，而是保留他们现在的样子，只称他们为原则（然而他们更侧重于思考框架）。
如果你想学习有关更多“原则”的内容，我可以推荐自认为有价值的一些素材。对于精益思考，有很多现成的材料，但并不都是好的。我通常推荐寻找更贴近丰田起源的内容而非解释性的东西。通常来讲，Liker 和 Ohno 的著作不会错。我特别喜欢 Ohno 编写的有关丰田生产的过程（Toyota Production Process），书名为《车间管理（Workplace Management ）》。对于系统思考， Peter Senge 的著作永远不会过时。对于系统思考的其他应用，可以查看一下 John Seddon 或者 Gerald Weinberg 的书，Gerald Weinberg 正在编写针对软件开发的系统思考应用的书籍。
InfoQ**：LeSS框架有两个版本——LeSS和 **LeSS 巨型。这两个版本有什么区别？
Bas：对的，LeSS 或者说基本的 LeSS 框架是针对 2 到 8 个团队，而 LeSS 巨型框架则是针对 8 个以上团队的。LeSS 巨型是 LeSS 的扩展，是针对大型产品开发的。LeSS 包含 2 页的规则，而 LeSS 巨型则又多一页的附加内容。
有两个框架的原因是，当超过 8 个团队时，你需要一些额外的规模化技术，帮助产品负责人及产品待办目录的规模化。然而，如果你没有 8 个以上的团队，这些辅助的技术并不需要。他们只会让你的开发更加复杂。如果把它们应用在小的 LeSS 实施中，还会带来负面的影响。为了更加清晰，我们决定把框架分成 LeSS 和 LeSS 巨型。你可以认为 LeSS 巨型是多个 LeSS 堆叠在一起。
InfoQ**：“LeSS就是扩展Scrum本身，目的是精简组织。”LeSS是如何做到的？**
Bas：当采用了 LeSS，它就会影响到组织的结构。通常发生的是，组织问题是通过传统的、复杂的方式解决的。而在 LeSS 中则比较简单。每一个迭代都有小批量的可工作软件，这就移除了组织的复杂性，这些复杂性是在传统的开发方式中为了应对缺乏透明度而产生的，最好用一些例子来解释这一点。
传统上，组织使用项目来管理工作。一个项目，用敏捷 / 精益的视角来看，就是管理大批需求上线的一种方式。当关注在产品及持续为用户发布价值时，用项目的方式管理工作就变得很过时。而通过产品周期中的产品待办目录来管理小批量的工作则更加简单。投资人还可以基于预计与实现的客户价值来投资（预算）产品。因此，好的 LeSS 组织就通过移除项目和项目管理，通过不同方式解决管理工作的组织问题，从而精简了组织。
进一步，大型组织在同一大型产品内通常都有不同项目的项目组合。当把一个项目考虑成一大批需求，项目组合管理就意味着大批需求的优先级。这不是我们想要的。因此，取而代之的是，我们考虑产品的定义是可扩展的，而且倾向于广泛的，这样产品待办目录就扮演了项目组合中的类似角色，但它是简单的、细颗粒度的优先级。
InfoQ**：LeSS也强调了技术卓越。它有多重要以及好处是什么？**
Bas：没有这个，你的开发很可能会失败。
Craig 和我用“组织的敏捷性总是受制于技术敏捷性”来表达这一点。如果代码库没有灵活性，组织就不可能灵活，换句话说，如果你的代码一团糟，你就会慢。
我们认为，很少有组织认识到技术实践的重要性。大多数都是在口头上说说而已。当深入到代码库（这是我们最喜欢的事情之一），你在最“敏捷”的开发组内也会有惊奇地发现。如果代码一团糟、很多复制的内容、缺乏领域抽象以及没有自动化测试，那么代码改动就很痛苦，不管你怎么组织开发工作，都是不灵活的。
InfoQ：您可否谈一下您即将面世的书籍？
Bas：好吧，我希望它再也不是即将到来。我们一开始认为这本书是一个小的项目，但实际上它变成了怪兽项目。不管怎样，这本书的名称是《Large-Scale Scrum: More with LeSS》，它描述了有助于实施 LeSS 的一些 LeSS 规则和 LeSS 指南。与前两本书相比，它更加容易阅读，更加规范。它应该已经出版了，但实际要到 2016 年初才会出版。
再多分享一下这本书，这本书分成三个部分：1）结构，2）产品，3）Sprint。结构的部分讲述了产品组的设计、管理的角色和 Scrum Master, 以及实施。产品部分讲述了产品待办目录、产品负责人、产品目录修整以及完成定义。Sprint 的部分涵盖了 Sprint 规划会议、评审和回顾会议以及协调与整合。
InfoQ**：请分享一些有关LeSS培训的信息。**
Bas：是啊，你参加了。我希望你喜欢！
我和 Craig 创建了两种认证培训，我们认为 Certified LeSS Practitioner 是主要的一个。这是为期 3 天的课程，深入介绍 LeSS 以及组织实施 LeSS。之后，参与者就是认证的 LeSS Practitioner，并且会在 less.works 网站上收到一个账号，这个网站列出了所有 LeSS 的内容。
我们正在建立一个培训网络，全世界各地都会有培训。
如果你感兴趣，可以在网站上看我们的课程安排。
InfoQ**：对想要实施LeSS的组织有什么建议吗 ** ？
Bas：如果你想想寻求一种简单的改变，容易地实施以及提供快速的修复开发问题…请不要采用 LeSS。如果你对开发中长期改善的，而往往又不易控制的方法感兴趣，LeSS 对你的组织正合适。
严肃的说，LeSS 解决一些组织的结构问题会有显著的改进，但却并不容易。必须持久并且保持学习。
InfoQ 今年早期发布了一些文章。 LeSS 介绍 、 Bas Vodde 谈 LeSS 框架 以及 功能性团队使用LeSS，每个迭代交付你的产品。
如果你想了解更多有关LeSS 的实施，请参考 LeSS 案例研究。
关于受访者
Bas Vodde对敏捷方法，特别是 Scrum 指导工作有着丰富的经验，他也是 Scrum Master 认证培训师。Scrum 之外，他也培训和指导团队的测试驱动开发（TDD）、回顾和敏捷计划等工作。他来自与荷兰，曾居住在中国、芬兰，目前居住在新加坡。在上世纪 90 年代，他曾作为一名开发人员在荷兰工作，他感觉到工作经验与“官方说你应该做什么”不符合。随着极限编程和其他常规的敏捷开发的引入，问题随之而解。在 2001 年初 ，他有了足够的“正常生活”，移居到了中国，开始在诺基亚工作。在那里，他获得了超大项目以及他们运行的传统方式的经历。经历这之后，他更加确信敏捷开发是正确的前进方向，并且适用于所有大小的项目。目前，他创建了自己的一家小型的、名为 Odd-e 的顾问咨询公司。
查看英文原文： Q&A with Bas Vodde on the LeSS Framework: Principles, Practices and Core Concepts
评论