Bas Vodde 的问与答 — Less 框架：原则、实践及核心思想

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 做了扩展。

扩展规则包括：

1. 解释了多团队如何进行 Scrum 活动。
2. 主要增添了有关产品开发组的结构（我们使用“产品开发组”表示构建产品的组织或者部门）。

规则之后，我们定义了十大 LeSS 原则。

原则有三种：

1. 基于 Scrum 的原则，例如透明原则或经验过程控制。
2. Meta 原则，例如精益思想和系统思考，以及
3. 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