Bas Vodde 访谈：LeSS 框架与 Scrum

在最近的敏捷新加坡大会上，Bas Vodde 进行了有关大规模 Scrum（LeSS）的演讲，LeSS 是他和 Craig Larman 共同推出的一种规模化模型。他解释了 LeSS 的一些重要元素，并在最近发布的网站上描述了这个框架。

InfoQ**：Bas，您好。欢迎您。感谢你能够光临此处并接受我们的采访。您可否为读者简要介绍一下自己呢？**

Bas：当然可以。我来自荷兰，在那里工作了几年。然后，我搬到了中国北京，我加入了一家名为诺基亚的‘小’公司。这不是指诺基亚手机业务，后者现在已经是微软的了，而是它们的电信网络组业务，现在就叫做诺基亚。在我搬到中国之前，我有极限编程（那时候还没有出现敏捷宣言）的经验，并且我在诺基亚继续尝试极限编程。一年以后，我搬到了中国杭州，我开始在一家大型的、基于瀑布式流程的电信产品开发组工作。

那个时候，大家都知道敏捷是针对小型项目的，因此接下来的两年我回到了非常传统的基于瀑布式的开发。但我发现这种方式对于大型产品开发并不是很有效。于是，我又回到了我熟悉的敏捷 / 极限编程式的开发。并且我开始尝试用这个经验做大型产品组的项目。与此同时，诺基亚网络对尝试更多的敏捷开发也变得有兴趣了。他们开始在组织内部寻找有敏捷开发经验的人，我最终成为为数不多的几个人之一。他们问我是否有兴趣在诺基亚电信内部领导一个变革项目。

后来，我搬到了芬兰，开始与我的好朋友，也是合著者 Craig Larman 一起工作。我是内部变革代理人，他是外部变革代理人，我们结对工作。那时合作得非常好。

我们在变革项目中所做的第一件事情，就是进行了大量关于敏捷开发的常规演讲，概括了所有不同的方法。接着，我们会问他们是否愿意尝试一些方法，哪个听起来最感兴趣。大家说 Scrum 看上去似乎很简单。我们就做 Scrum 吧…

当我们开始用 Scrum 工作时，我们决定邀请 Ken Schwaber 来帮我们在组织内部启动 Scrum。从小到两个团队的研发产品团队，到上百个团队的研发产品团队，整个组织最终都采用了 Scrum。

在芬兰待了两年之后，我决定回到中国，并加入了总数约 600 人的产品的管理团队中。他们已经尝试了 Scrum，并且决定一直进行下去。我们在整个组织都实施了 Scrum，并且开始应用现在已经成为 LeSS 一部分的一些思想。做了一年之后，我决定搬到新加坡并创建了 Odd-e 公司。

Odd-e 是一家敏捷教练与培训的公司，团队分布在东京、首尔、上海、曼谷、马尼拉、新加坡和香港。我一直在新加坡与诺基亚和其他一些公司合作。Craig 全球到处飞，继续在不同的大型项目和公司进行规模化 Scrum。在那段时间，我们也开始写最初的两本书，那时候我们都在新加坡。后来的几年中，Odd-e 的人开始尝试不同类型的组织设计，但这是属于另一个采访的不同的故事了。

InfoQ：这将是一个很好的故事

Bas：是的，它会的。继续讲，我作为外部的敏捷教练继续与诺基亚合作，也和其他几个公司合作实施 LeSS。现在又过了几年，我们正在写第三本书。

InfoQ**：第三本书是特别针对LeSS吗？**

Bas：是的，书名会是《大规模 Scrum（LeSS）》，并且我们刚刚建立了 LeSS 的网站。

InfoQ**：LeSS试图解决的根本问题是什么 **?

Bas：根本问题是 - 当所参与的团队不止一个的时候，如何应用 Scrum 的概念。

InfoQ**：这与Scrum中的 ** Scrum**** 有何不同？

Bas：Scrum 中的 Scrum 通常被描述为团队之间的简单协作方法。LeSS 假设多个团队工作在同一个产品上，提供了一个像 Scrum 一样的框架。LeSS 的核心是 LeSS 框架，它扩展了 Scrum 的规则，并设定了一系列简单的规则（两页）。除此之外，还有很多指南解释了组织方面的影响，例如典型的组织架构应该是什么样，或者管理风格应当进行怎样的转变。当有多个团队工作在一个项目组上时，LeSS 框架为此提供了我们对该产品组所应有期望的最小值。

InfoQ：当您昨天在描述的时候，提到一个有趣的观点，您说不是构建一个大的框架把它变小，而是提供一个非常非常小的框架，只增加一些最小的需求。那么，作为催化剂，您定义的最小附件有哪些？

Bas**：是的，我们做的其中一件事情是转变思考工具 **（从我们早期的工作）到十项 LeSS 原则。这十项 LeSS 原则说明了所有规则、指南和尝试。其中的一项 LeSS 原则是“LeSS 是 Scrum”。LeSS 并不是指首先在团队级别使用 Scrum，随后添加了一些材料来处理多个团队的情况。相反，LeSS 就是使用 Scrum，并且探索如何把相同的概念应用到多个团队中。LeSS 不是一个特别的规模化框架，包括“Scrum 到每个团队”，而是规模化的 Scrum。这是 LeSS 和其他规模化方法的根本区别。Scrum 本身是一个团队的框架，团队必须弄清楚他们怎么工作。有多少人真正知道 Scrum 本身有多小？很多人以为一些实践是 Scrum 中的一部分，其实并不是。

InfoQ：确实，Scrum指南只有 16 页。

Bas：是的，但这描述已经很长了。我还是一名 Scrum 培训师，与其他资深的培训师一起参考了《Scrum 敏捷项目管理》书中附录 A 中的很多内容。附录 A 被称为“规则”，有三页纸。LeSS 规则和那个附录很像，他们是基于 Scrum 的规则进行扩展的。对于基本的 LeSS，他们增加了两页内容，另有一页 LeSS Huge（针对超过 8 个团队的工作组）的附加内容。

LeSS 实际上包含了两个框架，一个就叫 LeSS，另一个叫 LeSS Huge。基本的 LeSS 最多支持 8 个团队，可能对 80% 的产品组适用。在过去这几年，我主要忙于超过 8 个团队的 LeSS Huge 的实施上，有时候是上百个团队。

LeSS 框架只对 Scrum 增加了一条内容：一个称为整体回顾的会议。这是与多个团队进行的回顾会议，他们可以发现系统组织上的东西。其余的规则是在澄清如何做 Sprint 规划会议、细化和其他类似的内容。当然，还有如何在团队之间进行协调。

LeSS 规则明确地告诉你如何组织你的产品开发。这些可能是组织内部最难实施的一部分，因为这需要对组织进行变更。

InfoQ**：当您谈到LeSS，不是LeSS Huge，我最好奇的一件事情是：所有的团队只有一名产品负责人、一个产品待办目录。参看一下其他的“规模化方法”，这似乎与他们是矛盾的。**

Bas：是的。所有人一起构建一个产品。其中的一项 LeSS 原则是“整个产品聚焦”。根据我在大规模开发方面的经验，其中的一个关键问题不是如何让 Scrum 在一个团队工作有效，而是如果每个团队都工作在他们“自己的部分”，如何让所有人都理解，如果不在一起工作，那你就不会有同一个产品。LeSS 就不会产生作用。

每个团队都需要将整个产品置于自己的那一部分之前。在 LeSS 框架中有几个规则建立了整个产品聚焦。一名产品负责人工作在一个产品目录上是其中之一。这名产品负责人并不是专注于澄清所有条目，而是关注在优先级上。团队没有他们自己的产品待办目录，而是他们工作在一个产品待办目录上。这就保证了跨多个团队的工作优先级，从而确保所有团队工作的内容是对产品最有价值的。团队并没有提前分配这些条目，而是尽可能最晚地决定，从而保持灵活性。这也意味着团队需要广泛地理解产品。这有助于团队构建整个产品，而不是构建产品独立的部分。

团队最终决定做哪些内容是在一个 Sprint 规划会议上最后决定的。团队的代表挑选他们团队想要工作的条目。在这之前，他们可能已经有过一个共同的细化产品目录的会议，所以他们在 Sprint 规划会议上挑选条目之前就已经清楚了。同样地，他们在 Sprint 最后有一个 Sprint 评审会议，参与者检查并调整整个产品。

InfoQ**：一个共享的Sprint评审会议，这样防止了康威定律吗？**

Bas：不，这个与康威定律并没有关系。那是完全不同的主题。添加到 LeSS 中的一项规则是大多数的团队是功能性团队。康威定律指的是根据架构组织，而功能团队是根据客户为中心的功能组织。它实际上只是坚持在每一个 Sprint 最后必须得到一个可工作的产品的逻辑影响。如果你工作在基于组件的团队，那么就很难弄清楚哪个团队将负责全功能整合和测试。而基于功能的团队就没有这个问题。

虽然实施 LeSS 的目的通常意味着采用全新的组织架构。但 LeSS 规则包含了实施的规则；我们看到很多 LeSS 实施都做错了，那是因为他们不能够恰当地使用一些基本元素。所以，对于基本 LeSS 的规则（不是 LeSS Huge）规定你必须一次性全部切换到功能性团队，而不是渐进式地实施。

InfoQ：所以它是完全切换吗？

Bas：是的，没有恰当的结构，成功的几率就会大幅减少，所以我们觉得你应该进行恰当的结构是非常值得的。但这也是非常困难的，因为不改变结构就不能够实施 LeSS，这与其他方法不同。

InfoQ：您有新书要出版了。

Bas：是的。我已经提到过，名字是大规模 Scrum。

InfoQ：您还提供培训和认证？

Bas：是的。我们的关注点将是 LeSS。我们已经成立了一个推广 LeSS 的组织。我们将在 2015 年 2 月份提供 LeSS 培训课程，并且我们还会建立可提供参加 LeSS 课程人员认证的培训师网络，我们已经建立了一个网站并正在写一本书。

这本书快写完了…但它处于快完成的状态已经持续了一段时间了。原来的目标计划是两个月…但那是两年前。我们现在集中精力在这上面。一谈到它我就感到非常兴奋。

我很高兴能够和很多人一起工作，并且与有 LeSS 经验的人一起建立了这个人际网络。现在已经有很多人都拥有 LeSS 经验了。

关于受访者

Bas Vodde对敏捷方法，特别是 Scrum 指导工作有着丰富的经验，他也是 Scrum Master 认证培训师。Scrum 之外，他也培训和指导团队的测试驱动开发（TDD）、回顾和敏捷计划等工作。他来自与荷兰，曾居住在中国、芬兰，目前居住在新加坡。在上世纪 90 年代，他曾作为一名开发人员在荷兰工作，他感觉到工作经验与“官方说你应该做什么”不符合。随着极限编程和其他常规的敏捷开发的引入，问题随之而解。在 2001 年初 ，他有了足够的“正常生活”，移居到了中国，开始在诺基亚工作。在那里，他获得了超大项目以及他们运行的传统方式的经历。经历这之后，他更加确信敏捷开发是正确的前进方向，并且适用于所有大小的项目。目前，他创建了自己的一家小型的、名为 Odd-e 的顾问咨询公司。

查看英文原文： Bas Vodde on the LeSS Framework

感谢邵思华对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。