第1章

Scrum知易行难

Scrum简洁优雅，表面上看，是一个最容易理解的框架，但同时也是最难实施得好的框架。我说“实施得好”是因为Scrum固有的简单性容易诱导我们，让人觉得使用Scrum很容易。然而，在现实中可能需要很多年才能把它做好。Scrum似乎完全对立于我们过去多年来在瀑布式开发中所习得的方式。显而易见，我们需要一些时间来忘记老习惯，及时调整到新的现实中。在本书的附录中，我解释了Scrum的机制。如果你对Scrum以及如何使用它还不熟悉，我建议你从那里开始。如果了解Scrum的一些背景，你就知道它的机制非常简单直观。事实上，正因为它如此简单直观，才导致很多人误以为自己已经掌握了Scrum，可以立即根据现状着手修改Scrum。结果呢，他们却往往发现自己迷失方向或者受了伤而需要帮助，本书就是为此而设计的。下面这个故事阐述了一点：如果不理解或者缺乏这些使Scrum有效的核心敏捷概念中的坚实基础，应用Scrum很快就会陷入困境。

故事

◎ 出场人物：敏捷教练Jeff (杰夫)  项目集经理Suzy(苏西)  ScrumMaster教练Julie(朱莉)  首席测试Mike(迈克)  团队Wyatt(怀亚特)

Jeff是个敏捷教练，他在一家大型软件公司内部帮助团队应用Scrum。有一天，他收到部门项目集经理Suzy的一封电子邮件。

“Jeff，请帮个忙。我们已经做了6个月的Scrum，但代码质量并没有像预期的那样有所提高。我想我们需要你过来和我们讨论讨论结对编程。下周一就是我们计划周的开始，你能来一下吗？”

Jeff坐在椅子上想，讨论结对编程相对简单，他可以带上朋友Julie，一个优秀的开发人员和经验丰富的敏捷实践者，所以不会有什么问题。但电子邮件中有几个字一直浮现在他的脑海中，计划周？Scrum要求Sprint计划会议的两个部分都不得超过4个小时。这个团队居然要做1周？他隐隐觉得，不只是结对编程，还有其他更多的事情需要他做。下周一会比较有意思。

星期一，Jeff和Julie来到会议室，发现Suzy和她的8人团队已经在会议室各就各位了。在Suzy介绍完团队之后，Jeff和Julie简单谈了谈各自的经历，然后开始问Suzy代码质量问题。

团队很快七嘴八舌，开始回答。首席测试Mike首先说道：“我们的代码质量差是因为我们没有时间做测试。开发人员在4周Sprint的最后一天还在忙着写代码。本来嘛，‘编码与测试Sprint’应该既做编码，又做测试。但我们的测试不是被挤到Sprint末尾，就是溢出被放到‘集成Sprint’。”

Julie打断他：“抱歉，Mike，你刚才是说‘集成Sprint’？”她看着Suzy，Suzy点点头。

“哦，我还没有解释我们改了Scrum，是吧？”Suzy说，“我们知道Scrum要求每4周有一个发布，但对我们做的这种工作，是完全不可能的。我的意思是，在我们尝试Scrum之前，我们都在努力按季度发布，那完全是一场灾难！所以我们只能修改Scrum使其更好地贴近我们的流程和现实。”Suzy走到白板前开始在上面写。

“首先，我们有1周来做Sprint计划；然后在4周的实际Sprint中，开发人员写代码，测试人员写测试用例；在这之后，我们就做集成，然后部署。当然，我也常常增加1周作为缓冲应急，以防万一。”Suzy说。

话音刚落，她就已经在白板上写好了下图所示的内容。

Jeff和Julie相互看了看，然后又看着Suzy。团队的其他人则显得很无聊。Jeff问了一个很显然的问题：“Suzy，你们的Sprint真的是8周、9周的样子吗？”

“对，”Suzy回答道，“你觉得很意外吧。我知道这不是正宗的Scrum，但对我们很适用。我想我们可能还需要增加4周，你知道吗？写说明书和测试计划，把它加进去还有点儿麻烦。现在我们是在缓冲的那周做，但我真的讨厌占用我们的缓冲。”

“好，我们过会儿再讨论这个，”Julie说。她看着Jeff，Jeff举手好像在说：“我们该怎么办？”Julie继续问，“Mike，你说你们没有时间做测试？”

Wyatt抢在Mike前面说：“别听Mike的。他们有很多时间做测试。我们才是永远都没有足够多的时间呢。我们每个Sprint都全力以赴地赶着完成我们所能完成的代码。为什么我们需要整整4周？因为真的就需要那么长的时间。”Wyatt看着Mike接着说，“自从我们开始使用Scrum以来，你和所有测试人员就一直在抱怨没有时间做测试。也许，Scrum才是问题的根源。”

Jeff和Julie交换了一下眼神。

Suzy插话道：“各位，我们聚在这里不是来抱怨Scrum的。我们是来提高代码质量的。”她暂停了一下，深深地吸了一口气，“我这样说已经说了6个月了。”她对Jeff和Julie说道，无奈地翻了个白眼。

Jeff点点头：“我知道你很沮丧，我也知道Mike和Wyatt也很沮丧。我能够和团队深入讨论这个问题吗？看看我能不能找到问题的根源？”Suzy热切地点点头。

Jeff以他标准的第一个评估问题开始：“好的，Scrum和极限编程(XP)都要求每天都有检查点。在Scrum中，就是Scrum每日站会。你们怎么评价你们的每日站会？”Jeff对团队提问。

Mike笑道：“每日站会？你是在开玩笑吧！我们没有时间做这些。我们每周开两次会，一共1个小时，这已经很花时间了。”

“好的，Mike，给我讲讲你们是怎么开这些会议的。”Jeff说。

“首先，我们每次开会都说同样的事情，开发人员说他们在完成任务，我们说我们在写测试用例，这是大新闻吧。然后我们大概花20分钟左右的时间对缺陷列表进行分类，总的来说就是把缺陷列表挨个儿过一遍，分为‘设计造成的’和‘在下一个Sprint修改’。当然，我们从来没有改过这些缺陷。这纯粹就是功能失调所引起的混乱。”Mike说道。

看得出来，Suzy很生气，所以Jeff也留出机会让她发发声。

“谢谢Mike。Suzy，你的看法是什么呢？”

“Mike说对了一件事情。每日站会的确对我们不适用。我们每两天才开一次会。我的日程太忙了，没有办法每天开会，而有些团队成员还在其他的项目上。我知道这不是理想的状况，但是我们只能这样做。让我头疼的是，即使我们每周开两次会议，团队仍然和我吵，说什么负担太重。你听见Mike刚才是怎么说的吧。他们都抱怨这些会议、时间安排以及时间不够用！但是我也无法拒绝管理层要求我们更快发布。更何况，就像我一直告诉他们的那样，这是我的项目。我制定计划，我组织团队。告诉他们，Jeff，我是ScrumMaster。他们都应该照我说的做，对吧？”Suzy迫切地期待着Jeff的肯定。

Jeff不置可否地耸耸肩，保持沉默。他开始意识到他们对Scrum的了解不是一般的贫乏。他看了一眼Julie，给她一个表情，表示他们还不懂。Julie轻轻点头回应。Jeff继续他的评估。

“好的，我听见了。我们不要操之过急。看上去一个潜在的问题是你们的每日站会没有每天都开，没有成效，持续时间太长。这个我们可以纠正。让我们先把这个问题放一放，把思考过程提高一个水平。告诉我，你们为什么会采用8周的Sprint？”

Wyatt发话了：“我在这里已经有10年了，我见过这里流行过的所有东西，它们来得快，去得也快。但这次我是个盲从者，我真的认为Scrum可能不一样，这是不是有点儿不可思议？！整个事情起源于管理层要求我们更快发布。之前，我们已经做到了按季度发布。让我告诉你，从年度发布到季度发布，真的很难，但是我们做到了。但是对管理层，这还不够快，是吧？”Wyatt停了一会儿，环视了一下会议室，希望有人响应。

他继续说：“所以，有一天我和Suzy坐在一起吃午饭，刚好遇到在另外一个部门的同事。他告诉我们他的团队正在使用Scrum，他们每4周就交付一次，而且他们都很开心。他说他们突破了质量的天花板，管理层已经很多年没有这样满意过，客户也很开心。你知道吗，这个人和我一样是个怀疑论者。所以我想如果他都说Scrum有效，就肯定有效。于是，Suzy和我就花了一个下午的时间向他学习Scrum。Scrum看上去非常简单，但是也有一些问题。首先是那些每日站会，谁有这么多时间呢？所以我们就简单改为每周两次。然后，4周为一个周期显然不适合我们，我们几乎只能做到以季度为周期，所以我们决定加倍，改为8周为一个周期。以此为基础，我们就把我们的工作流分解到8周里面，所有的都要压缩。毕竟，Scrum只不过是另外一种增量开发的流程而已。”

Jeff和Julie又相互看了一眼。

Wyatt继续说：“我看见你们的表情了。但是我告诉你们，我们了解自己的团队和产品。原汁原味的Scrum我们可能用不上，所以我们做了任何一个软件团队都会做的事情，那就是根据我们自己的需要对Scrum进行修改，按最接近我们以往做事的方法来。”

“对，”Suzy确认，“我的意思是，Scrum是项目经理管理工作的一种方法，只不过周期更短而已。”

Jeff往后坐了一下，他准备的评估问题不是为这种情况而设计的，他还不确定现在该说些什么。Julie挺身而出，说道：“你们有一个通用的‘完成的定义’吗，Wyatt？”

“我们当然有啊。第1周后，我们有设计评审会；然后在第5周结束的时候，我们有代码完成的里程碑；在集成结束的时候，我们有完成测试和集成。一旦完成这些里程碑，我们就发布上线。这真的不难理解。”Wyatt说道。

“对，这很简单，我明白。”Julie安慰道，“伙伴们，刚才Wyatt、Mike和Suzy解释了你们的流程。我的理解是你们有每周两次的站会，8 周(有时候 9 周)的Sprint，而且在特定的关键时期也有检查点让你们知道你们完成了。这样的工作方式你们感觉怎么样？你们觉得这样工作有乐趣吗？代码质量提高很多了吗？”Julie问道。

“嗯，还不错，”Wyatt回答道。

“不错？！”Suzy问道，“简直糟透了。”

“这样糟糕不是我们的错！我们试图做测试，但是就像我讲的那样，我们没有时间做！”Mike提高了嗓门儿。团队的其他人盯着桌子，不说话。

“Mike，虽然我可以，但是我没有指责你，没有。真正的问题是Scrum，”Wyatt说，“这是一个愚蠢的流程，它根本就不适用。”

“不要又讲这个，”Suzy说，“这个问题我们要争论多少次？每次回顾会议我们都在争论这个问题。”

“回顾会议？”Wyatt插话说，“这只是一个名字听着好听的为期两天的垃圾会议。回顾会议不能改变任何事情。Scrum不能改变任何事情。OK，我要收回这句话。Scrum的确改变了一件事情，就是使得我们大家的处境都很悲摧。”

“Wyatt，使用Scrum也是你的主意。既然你所做的就是破坏这个流程，当初你为什么要首先发起呢？”Suzy激动地问。

Jeff站出来了。现在应该是时候停止提问并让团队开始面对真相了。

“瞧，这不是哪一个人的过错，也不是Scrum的过错。对于我来说，我相信Julie也会同意，看上去你们并没有真正在做Scrum。你们所做的和过去做的是一样的，只是压缩到8周的一个周期中。你们把这个就称为Scrum。”

Wyatt和Suzy准备开始争辩，但是Julie举手制止了他们。“让我问一个问题，是问团队的。Wyatt、Suzy和Mike，请你们不要回答。”Julie在先看了看会议桌团队的每一个人，然后继续说，“这种新的工作方式使你们工作痛苦呢，还是一直就是这样，只不过可能没有这么明显？”Julie问。

每个人都低着头，看得出他们是在思考。

“过去也很糟糕。”会议室后面传来一个声音。

“对，”另一个团队成员说，“我只是没有意识到过去有这么糟糕。”

随着团队的自我意识开始觉醒，会议室陷入一片沉寂。

Wyatt叹了一口气，说：“你说得对。过去也不比现在好多少，只是没有现在这么明显。我们原来是每个季度感受一次痛苦，现在是每8周感受一次。”

Mike插话说：“知道吗？看看过去的6个月，我们发现了很多应该而且能够解决的问题，但是我们什么也没有做，真的没有。”

Suzy打断了他。“伙计们，我真的累了。我们能够推迟几天再来讨论吗，下周？”她问。

团队点头表示同意，他们也累了。

会后，Suzy意识到事情很糟糕。她花了一个周末以及下一周的前半段时间来思考如何推进工作。她召开另外一个会议并把Jeff和Julie也邀请回来，她希望以此为团队确定一个新的基调。

“各位，我感到很抱歉。”Suzy以此开始会议，“我知道事情有些糟糕，但不知道有那么糟糕。我原来只是想请Jeff和Julie来帮助我们做结对编程，我以为那样可以解决我们的质量问题。显然，我没有意识到我们真正的需求，为此我向大家道歉。我们把一切都搞错了，不是Scrum失败了，而是我们错误使用了Scrum。我想问问你们所有人，我们是不是可以重新开始，我觉得Jeff和Julie可以帮助我们具体实施。”

Wyatt点点头看着团队说：“我知道我有时候有点儿犯浑。我在这里的时间太长了，以至于有时候都觉得自己是主人，但其实不然。我知道我可以做得更好，我会停止抱怨，真正尝试Scrum。但我有个条件。”

“什么条件？”Jeff问。

“就是我们要做就做真正的Scrum，”Wyatt说，“不要再修改Scrum。而且我们需要有教练来告诉我们应该怎么做，这并不像表面上那么容易。”

Mike抬头说：“我也有个条件。我们要修复那些缺陷，真的修复它们，而且不能为此相互指责。”他把手伸向Wyatt，“我们能做到吗？”

Wyatt看着Mike，看着他的手，然后握手说：“我觉得我们可以迎接挑战了。如果Jeff还会帮助我们，就行了。”Wyatt玩笑式地朝着Jeff挤眉弄眼。

团队都笑了，他们作为一个团队很久没有这样开怀大笑了。这是一个好的开始。他们围绕着会议桌，各自口头承诺使用Scrum，真正使用Scrum。过了一会，Jeff和Julie离开会议室，他们感觉完成了很多工作，但还有更多的事情等着他们去做。

“你准备怎么做，Jeff？”Julie问。

“首先是教他们Scrum是什么，包括它的价值观、框架以及他们需要经历的思维方式的转变。”Jeff回答道。

“不要忘记告诉他们Scrum是怎么管理风险和如何帮助发现问题的。”Julie说。

“肯定的。我会从基础开始并随着问题的出现逐个解决。肯定会经常出现困难，但是他们能够做到。没有痛苦，就没有收获，对吧？”