转载

Bas Vodde谈LeSS框架

在最近的敏捷新加坡大会上，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）关注我们，并与我们的编辑和其他读者朋友交流。

正文到此结束