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