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\u0026amp;A with Bas Vodde on the LeSS Framework: Principles, Practices and Core Concepts