Jeff Sutherland论什么是真正的Scrum

受访人 Jeff Sutherland 译者 郑柯 发布于 2008年1月10日 下午11时40分

社区

Agile

主题

敏捷实施,

方法论

标签

历史,

QCon,

Scrum,

自组织团队

概要
Scrum的创建人Jeff Sutherland估计每个工作日，大概会有120，000个Scrum团队在开展每日立会。但其中有多少是真正在实施Scrum呢？在QCon 2006伦敦会议上，他谈到了“诺基亚测试”，而且他喜欢用其来甄别团队是否在实施敏捷或仅仅是迭代过程，甚或两者都没有实施！他还揭示了在Scrum和火星探测机器人之间的联系。

个人简介
Jeff Sutherland博士曾担任9家软件公司的VP和CTO，他所工作的最近一家公司名为PatientKeeper，是移动和无线健康市场中的顶级厂商。他还是敏捷宣言的签名人之一，一位CST（Certified Scrum Trainer, 认证Scrum培训师）。1993年，他首次在Easel公司使用Scrum，并作为咨询师为微软、雅虎、Ariba、Cadence、Adobe、GE Healthcare以及M3 Media Services等多家公司提供Scrum咨询。个人网站：www.jeffsutherland.com。

Jeff Sutherland，欢迎来到InfoQ。向大家介绍下你的背景和资历吧。

在1993年时，我想找到一种更好的构建软件的方式。我曾在九家软件公司担任CTO和VPO工程师，到了1993年我正在第五家公司，那时我们找到了一种可以工作得非常好的实践，也就是现在的Scrum。在1995年，我遇到了Ken Schwaber，他当时担任一家项目管理和软件公司的CEO。我向他展示了我与之工作很长时间并在许多迭代中都成功提交了软件的项目团队。他看过我们的做法之后说道：“这样做才是王道。”所以接下来的许多年里，Ken帮助我们将它推广到了全世界。虽然我现在仍担任一家软件公司的CTO，但近几年来已经可以从公司的事务中脱身出来，花很多时间走遍世界来探讨和推广Scrum。

上一次拜访Scrum联盟时，我注意到那时已经有一万人受训成为了CSM（Certified Scrum Master）。能告诉我，都是哪些人在实践Scrum吗？

Scrum的普及已经越来越广泛了，有许多人都在实践Scrum。我们的认证课程会让Scrum master的数目每年翻一番，现在共有约12,000个Certified Scrum Master；而且我们知道，对于每个Certified Scrum Master来说，有十个未经任何培训的Scrum团队需要他们帮助。我估计今天早上全球会有120，000个Scrum团队在进行他们的每日立会。真的有很多人都在实践Scrum。

他们实践的都是真正的Scrum么？你是不是见过很多种具体实现方式不同的Scrum呢？

确实挺有意思的，因为随着采纳Scrum的人数和团队的爆炸式增长，人们会处在各个不同的实践阶段。在我最近与一些参与培训课程的人们的会议中，我一直在问：“你们中有多少人正在实施Scrum？”实际上，在周一的Qcon会议上，有三十个人参加了一个Certified Scrum Master的认证课程，我说：“有多少人正在实施Scrum？”，有十五个人举手响应。接下来我说：诺基亚也许拥有比其他公司多得多的Scrum master；实际上，我知道芬兰是世界上人均Scrum Master数目最高的国家，主要是因为诺基亚。他们总结出了一些很简单的建议，可以帮助他们判断一个团队是否在真正实施Scrum。

那诺基亚是怎么知道一个团队真的在实施Scrum呢？

首先，他们要看是否采取了迭代开发的方式。在面向对象开发领域中，多年来我们一直使用迭代式的、增量式的开发，这似乎已经成为所有敏捷过程的基础元素了。他们首先会询问团队：“你们是否采用迭代开发？”因为如果不这样做，甚至都不能称为敏捷的软件开发过程。他们会提到的第一件事会是：“你们有固定的迭代周期吗？你们的迭代是否以某个特定的时间开始并以某个固定的时间结束？”而且迭代周期必须少于6周。如果不是这样做的，那么就没有进行迭代开发。如果人们的回答是肯定的，那他们接下来会询问“那好，在每个迭代结束的时候，你们有可以工作的软件么？”这个问题会把很多人排除在外，因为如果不能给出可以工作的软件的话，那也就是没有进行迭代式开发。接下来他们会说“好，你希望在结束时拥有可工作的软件，那么在可以开始迭代之前，你们的团队是不是必须要有一个有完整细节的需求说明？”如果需要的话，那就不是迭代式开发。最后他们会说：“要在迭代结束时拥有可以工作的软件，将测试作为迭代增量开发的一部分是非常重要的。你们在开发过程中进行测试吗？”这个问题有可能将一般左右的Scrum团队排除在外，这时甚至还没有谈到有关Scrum的话题呢。

那为什么团队是否“进行迭代开发”这么重要呢？

这是因为敏捷的要点是——实际上是几个互相关联的要点——希望整个流程中的所有人都可以一起工作，大家都对产品非常了解：无论是构建产品的人，测试产品的人，还是将会使用产品的用户。他们应该一起工作，如果把过程分隔成“这里的这些人编写需求说明和规范，然后他们把文档交给负责构建软件的人，软件构建者再将软件转给测试人员，最后测试人员把软件提供给客户”，客户就会说那不是他们真正需要的东西。然后就要回到开头，再来一次。如果如此反复三遍的话，客户就会取消这个项目了。这就是为什么世界上有那么多项目被砍掉的原因。你必须马上开始所有的工作。

听起来你很赞同诺基亚应用的判断条件。所有这些工作必须马上开始，这一点很重要么？

是的，实际上这些是要顺利实施Scrum的一系列要点的一个子集。在我一一讲述这些要点之前，上述只是诺基亚八个要点中的四个。他们使用这八个要点来判断团队是不是真的在实施Scrum。接下来会有一系列问题关于“你们的Scrum实施真的顺利吗？你们的交付速度真的很高吗？你们的客户对提交的产品欣喜若狂吗？”所有这些问题都是顺利实施Scrum的要件。但是该检查列表只是判断团队是不是在实施Scrum，接下来就可以探讨下如何改进流程了。

诺基亚对于一般的迭代开发有自己的规则，那你能不能告诉我们他们的附加“Scrum规则”是什么？

对于应用Scrum，他们有四个附加的规则。团队被询问的第一个问题是“你们是否有产品所有者？是不是有人可以代表客户与你们一起工作？”团队在决定应该构建什么样的产品时，这个人就是他们要询问的对象。有许多这样的团队，如果被问到此问题，他们会说“不，我们不知道谁是产品所有者。”诺基亚会询问的第二个问题是“如果有团队所有者的话，他们是否拥有一个待开发功能的product backlog？此backlog是否根据业务价值排定了优先级？是否已经估算过开发这些功能需要多少时间？”。这是一个产品所有者为一次版本发布构建路线图所需要的依据。如果得到了肯定的回答，他们会继续询问：“团队在开发过程中，有没有使用Burndown图，来展示当前迭代中随着时间的推进，剩余工作量的变化，以跟踪进度？并且能否基于Burndown图来推算团队的速度？”这个问题的意义是：首先，产品所有者可以根据它来构建发布规划；同时团队可以根据它来真正改进流程。他们希望知道自己的速度如何，这有助于他们进行更好的估算，同时帮助他们在继续后续工作时提升速度。最后，Scrum团队依赖自组织的过程，这就意味着团队负责挑选工作、职责分配，并要找出最快交付工作的途径。诺基亚有一条规则：在迭代中，项目经理不能干涉团队工作，因为这会停止自组织的过程，并且得到解决方案的过程将不再是最优化的了。

译注：Burndown图(burn down chart)，用来展示剩余待完成工作与时间关系的图形化表达方式。未完成工作（或称为backlog）标识在纵坐标轴上，时间标识在横坐标轴上。可用其协助预测项目所有的工作何时完成。常常使用在诸如Scrum这样的敏捷开发过程中。更加详细的说明请参见：http://www.controlchaos.com/about/burndown.php。

为什么这些规则这么重要？

通常意义上的敏捷过程和Scrum，都是希望可以让开发团队与将会使用产品的客户坐在一起工作，来真正改进软件产品的质量，并更快地提交软件。要达到这个目的，需要所有的人和过程能够一起配合。在设计Scrum、XP和其他敏捷流程时，我们刚找到进行面向对象开发的最佳方式。这些流程是基于一些互相紧密关联的方面构建而成的。公司经常会提及的一句话是：“那好，我们用这种敏捷流程吧，因为其他的都不太好实施。我们一定会有所改进的。”可是改进的效果却并不能如他们所愿，就像你在了解过面向对象技术之后这样说道：“嗯，我们的开发人员可以使用面向对象开发任何东西，只不过他们不太会使用继承；而且公司有编码标准，使用继承不符合公司的标准。所以我们除了继承之外可以使用任何编程技术。”最后产品出来了，它很脆弱，适应性很差，而且不灵活，原来期待的改进完全失去了踪影。管理层这时就会说：“你看，我们采取了面向对象的开发方式，投入了大量资源，可最终还是没有收到多少成效。”

那这种有选择的实现是怎么在Scrum中表现的呢？

Scrum设计的初衷，是希望他们进入这样的状态：以日常工作5到10倍的成效来提交软件，而且在很好的Scrum团队中是可以观察到这一点的。通常的Scrum实现，可以让公司的软件生产力提高到原来的两倍，而且质量上的提升不止两倍。这就是Scrum可以持续发展的原因。人们只要真正实施了Scrum，它确实可以给你带来上述的预期效果。如果一家公司不能像我这样，在一开始就认真研究并仔细回答诺基亚的问题列表，我几乎总是可以发现，他们没有达到实施Scrum的基本要求；而且他们也就不能得到预期的产出，除非可以满足这些基本要求。

那是不是最好不要只选择几个看起来有用的敏捷实践并将其带入到传统的软件开发团队中去？

是有很多公司就从若干实践开始，而且真的去做类似于每日立会这样的实践，并且取得了一定的成效。不过这样只能取得些微改进，无法取得最佳的效果。有一个有趣的例子：Google的AdWords项目。这是很吸引人的项目，因为如果你有Google的广告，AdWords软件可以将广告放到你的Gmail里面或是博客上。AdWords为Google赚取了绝大部分的利润。它必须与Google其他所有产品做集成，而且还要与Google外部的、将广告放到自己网站上的人做集成。AdWords项目团队的发布问题比绝大多数Google应用都要来得严重，他们试图在交付日期和集成上做得更好，一切必须顺利工作。产品所有者Mark Striebeck在2006的敏捷年会上演讲了他的研究成果，他将他们的方式称之为“google方式”，因为是在Google完成的。他们没有多少流程，而且也不希望有任何流程可以凌驾于他们之上。

他的策略是：他很清楚自己想要什么，他知道Scrum的全部要素，不过他这样询问开发团队：“我们最大的问题是什么？让我们列出这些问题，然后按照优先级排序。”团队回答到：“最大的问题是我们不能按时交付，而且有很多人都指着这一点来开展他们的后续工作。”Mark说：“那我们可不可以使用敏捷过程实践中的一种被称为Burndown图（实际上他用了一个版本Burndown图）的实践，然后看看效果如何？”

Mark完全了解Scrum，而且他知道这样不能解决实际问题，而且会导致更多问题。当更多问题浮出水面的时候，他开始提出问题：“OK，让我们假定使用发布Burndown图可以让我们按时交付，那你们现在的问题是什么？”团队开始回答：“呃，我们有许多问题，人们总在签出代码。AdWords项目有5个团队分布在世界各地，所以会发生大家都签出代码，然后修改同样的代码，做重复的事情；导致代码互相冲突从而带来bug，这是个很大的问题。”Mark说：“那我们是不是可以尝试另外一个敏捷实践，称为‘每日立会’。大家聚在一起讨论彼此昨天做了哪些工作，今天要做哪些工作，以及面临哪些障碍。我想这可以解决你们的问题。”于是团队开始每日立会。这样做确实解决了不少问题，但是又让更多问题浮出水面，因为在每日立会中，人们开始构建更大的障碍列表，并针对其排定优先级。

不过Mark此后逐渐以系统的方式将Scrum的整个流程带入进来，最后，所有的工作都完成了，他对大家说：“你们猜怎么着？这就是Scrum。”他实施了Scrum，而且没有告诉别人他在实施Scrum，而且最终取得了很好的成效。所以我推荐：如果人们试图采纳敏捷的部分实践，可以去看看Google的研究文章，web地址是：http://doi.ieeecomputersociety.org/10.1109/AGILE.2006.48，他们同样运用了类似于Mark的智慧：有系统地将Scrum流程带入开发过程。

那什么样的经验才能带领一个组织完成这种增量式的变化呢（就像Google AdWords项目这样）？

要有敏捷的经验，必须要有曾经与敏捷团队一起完成某项工作的经历，与能够通过诺基亚的测试，而且曾经成功使用Scrum或其他敏捷过程提交软件的团队一起工作。还要理解成功的因素都是哪些，来自何方。这样，你就可以到其他的公司或团队，去指导他们完成采纳敏捷实践的过程，就像AdWords团队那样。

如今，每个人都努力改进软件开发流程，希望提升产品的质量，产生更好的产品。那么，如果人们只是部分使用Scrum的话，他们应该怎么称呼他们的流程呢？

人们都在观察敏捷流程，特别是Scrum，而且他们注意到有人已经取得了成功，他们知道必须要改变现有的流程了，希望更早交付质量更好的软件。同时，还要提升开发人员的生活质量，这样他们就可以招聘到更好的开发人员，而且保留现有的已有良好工作经验的人员。以增量式的方式引入敏捷实践，这样做很正常。不过他们要明白，除非使用一种完整的流程，否则他们不可能得到全部的成效。他们应该有实施规划，其中要有意识的定义具体实施步骤；而且他们必须明白：当采取某个实践不能解决问题的时候，是因为这个实践让其他问题更加明显了，就像Google那样。他们应该确定这些问题并再次使用Scrum策略：按照优先级排定障碍列表，并开始考虑如何解决优先级最高的问题；接下来引入可以解决那个问题的下一个实践。如果像这样，一步步地有序进行，他们就可以达到目的，而且一路上他们都能够得到微小的改进。这是很好的做法，但在实施时要有意识地推进，而且应该接受一些Scrum培训，或者引入一些曾经在其他团队成功完成类似项目的人，因为他们明确知道在逐步引入敏捷开发的过程中应该做什么和怎么做。

那么团队还在持续地改进过程的时候，这时的流程是Scrum么？

我喜欢诺基亚的测试检查列表。诺基亚的人们说：这些年来，检查列表减轻了他们很多的痛苦和困惑，没有该列表就不能成就他们的今天。

Jeff，你提出的来自火星探测机器人的六度分隔理论（six degrees of separation）真的特别吸引我，能不能说一说这与Scrum有什么联系？

像昆虫一样有很多腿的机器人很有意思，制造这种机器人的公司也是如此。在Scrum过程创建之前，我曾经出租过房子给一家创业公司，这是一家由来自MIT的Rodney Brooks教授创办的机器人创业公司。他们制造的机器人有很多条腿，而且有红外探测器；这些机器人不断跑到我的办公室来试图“抓”我，所以我对它们很熟悉。当我们开始观察软件开发模型时，IBM发布了一项研究成果，其中表明：根据他们在IBM内部的观察，“外科手术团队（surgical team）”是开发软件生产力最高的团队。

在外科手术团队中，有一个人是“主刀医生”，他了解整个的设计和架构，并做全部编码工作，其他人围绕在他周围辅助他。在第一家应用Scrum的公司中，我们当时在开发一个产品，需要到福特汽车公司去和他们的IT开发人员一起工作。举个例子，我们的老产品有一千个客户，而且我们知道他们没有能够承担“主刀医生”职责的人，实际上绝大多数公司都没有具备这样能力的人才。这样的话，要怎么样构建一个流程，可以让团队亲密无间地工作，并达到像“主刀医生”那样的水准呢？

后来，我在办公室里看到机器人跑了进来，然后Brooks教授解释了它的工作原理，他把它称为“包容架构”，这是一种分层的架构。他说：“要知道，在人工智能领域，我们花了30年的时间来试图打造一个智能系统。我们试图创建世界上最大的数据库，然后把所有能够收集到的信息都放进去；我们试图打造世界上最强大的计算机，让其可以将天空作为白板，在上面完成无穷无尽的运算，可最终我们得到了什么？我们得到了一个智能国际象棋程序，这是一个彻彻底底的失败。”接下来他说：“我正在尝试一条完全不同的途径。我们要构建一个没有数据库的系统，它的数据来自外部世界，它将以传感器作为基础，并且不会有中心处理器。在它的每条腿上有一个处理器，知道如何行走。在它的背部有一个处理器知道如何协调这些腿。在它的脑部有一个神经中枢芯片，刚被植入时，这个芯片是完全空白的。”当机器人的开关被打开后，它的腿开始上下拍动，突然它的整体就可以上下摆动了，没多久，它就开始绕着房间到处乱跑，就像一个刚学走路的孩子。看到这些东西真的让人感觉非常惊讶。

所以，通过利用简单的事物协同工作来创建分层架构，就可以得到非常智能化的东西。要在火星上完成探测工作，需要的正是这样的机器人，而且它也被用在伊拉克去调查城区的状况。还基于它生产了真空吸尘器（也许你就有一个Roomba扫除机器人？）。这家公司现在名为IRobot，而且是当今世界上处于领军地位的机器人公司之一。创建一套简单的规则，帮助一个团队完成自组织的过程，因此团队可以得到卓越的成就。这个想法就是Scrum的基础理念，它来自于曾经在办公室里追着我的屁股跑个不停的机器人。

 

相关厂商内容

SOY Framework：Java富客户端快速开发框架

降低传统团队在敏捷旅程中的风险

活动：免费参加中国软件技术英雄会（上海站 9.5）

用数字沟通——来自敏捷精灵的忠告

免费迷你书下载：开源技术选型手册

相关赞助商

InfoQ中文站敏捷社区，关注敏捷软件开发和项目管理，通过新闻、深度文章、视频访谈和演讲以及迷你书等为中国技术社区提供一流资讯。

1. 返回顶部

   ScrumMaster认证课程（2008年5月9-10日 上海）

   2008年2月28日 上午1时22分 发表人 UPerform -

   ScrumMaster认证课程（2008年5月9-10日 上海） 在顺利完成该课程之后，每位学员将获得Scrum Alliance颁发的Certified ScrumMaster证书及一年的联盟会员资格，同时获得PMI的PDU学分。机会难得，欢迎大家踊跃参加！ 详情参见http://www.scrumalliance.org/courses/1915-certified-scrummaster 或http://www.uperform.cn/class.php

   回复

2. 返回顶部

   最新ScrumMaster认证课程（2008年7月18-19日—上海 2008年9月26-27日—北京）

   2008年5月19日 下午9时40分 发表人 UPerform -

   ScrumMaster认证课程（2008年7月上海 9月北京）在顺利完成该课程之后，每位学员将获得Scrum Alliance颁发的Certified ScrumMaster证书及一年的联盟会员资格，同时获得PMI的PDU学分。机会难得，欢迎大家踊跃参加！详情参见 http://www.scrumalliance.org/courses/2595-certified-scrummaster http://www.uperform.cn/class.php

   回复

3. 返回顶部

   Re: 最新ScrumMaster认证课程（2008年7月18-19日—上海 2008年9月26-27日—北京）

   2008年6月2日 上午3时22分 发表人 dong xie

   请问有没有在深圳教学的ScrumMaster认证课程？多谢！

   回复

4. 返回顶部

   Re: 最新ScrumMaster认证课程（2008年7月18-19日—上海 2008年9月26-27日—北京）

   2008年6月25日 上午9时24分 发表人 feng lei

   同问，有没有深圳的课程？

   回复

5. 返回顶部

   Re: 最新ScrumMaster认证课程（2008年7月18-19日—上海 2008年9月26-27日—北京）

   2008年7月25日 上午2时49分 发表人 UPerform -

   目前还没有深圳的课程安排！不过您们可以和UPerform（优普丰）公司取得联系（网址： www.uperform.cn 电话：021-63809913）进行课程需求登记，我们会根据学员的具体需求来安排课程！谢谢！

   回复

• 更早的 >