转载

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)关注我们,并与我们的编辑和其他读者朋友交流。

正文到此结束
Loading...