Scrum实战：故事、模型与成功秘诀

短短几年时间，Scrum跃升为敏捷优选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书结合故事、模型和成功秘诀三大要素，透彻讲解确保Scrum取得成功的基本要素。全书4部分30章。在简单介绍Scrum知易行难之后，在第一部分中阐述导入Scrum之前的准备工作。接着，第二部分重点介绍实战基础。第三部分提出急救包的概念，讨论如何使每日站会富有成效，如何提出Scrum的第四个问题，如何让人们在结对编程时保持专注，增加团队新成员时应该怎么办，发生文化冲突时应该怎么办，冲刺应急过程等。第四部分则锁定八大主题，重点介绍高级生存指南。最后在附录中概述Scrum框架，以帮助读者快速入门。
针对如何用好、用巧这个看似简单的框架，本书结合故事、模型和成功秘诀三大要素，透彻讲解确保Scrum取得成功的基本要素。本书适合打算实现敏捷转型并导入Scrum的所有人员阅读，比如开发人员、架构师、测试人员、经理和项目负责人，是帮助他们顺利度过Scrum第一年的理想参考书。

Mitch Lacey，敏捷实践者和培训师，Mitch Lacey & Associates公司创始人。他拥有16年项目管理经验，现在的主要身份为敏捷讲师和敏捷教练，指导过许多计划性项目和敏捷项目。在微软工作期间，Mitch曾运用敏捷相关知识成功发布了Windows Live里的核心企业级服务。Mitch在微软的第一个敏捷团队由Ward Cunningham（维基之父、极限编程的创始人之一）、Jim Newkirk（nUnit创始人）和David Anderson（看板倡导者）所指导。他是认证Scrum讲师(CST)和PMI项目管理专家(PMP)，也经常出席全球大会发表主题演讲。他是Scrum联盟和敏捷联盟的委员会成员，曾经担任Agile 2012大会的主席。

傅勃，瀑布和敏捷的见证者和实践者。从事多年软件开发工作之后，在一个CMMI五级的组织里开始承担项目管理工作。经历过混乱到依赖严格流程来控制软件开发过程的转变，有成功，也有失败，因而也对传统软件开发与项目管理的过程与方法有诸多存疑和困惑。到2007年，初次接触Scrum之后，感觉曙光乍现，尽管最初有些难受，但另一扇希望之门已经缓缓开启。到2009年年初，组织内部已经全面推广学习、尝试敏捷开发实践（Scrum与XP）。

第1章 Scrum：知易行难
故事
Scrum
什么是Scrum
实施Scrum
Scrum适合我吗
变化是困难的
实践与集成
新的现状
成功秘诀
引用
第Ⅰ部分 战 前 准 备

第1章
Scrum：知易行难
Scrum优雅得具有欺骗性。它是最容易理解的框架之一，同时也是最难以实施好的框架之一。我说“实施好”是因为Scrum固有的简单性容易诱导我们认为使用Scrum很容易，然而在现实中可能需要很多年才能把它做好。Scrum似乎与我们过去多年以来瀑布式开发中所习得的完全对立。显而易见，我们需要一些时间来忘记我们的旧习惯，并调整到一个新的现实中。
在本书的附录中，我解释了Scrum的机制。如果你对Scrum以及如何使用它还不熟悉的话，我建议你从那里开始。如果已经了解Scrum的一些背景，你就知道它的机制是十分简单直接的。事实上正因为它如此简单直接，才导致很多人误以为自己已经掌握了Scrum，可以立即开始修改Scrum以更好地适应他们的现状。太过寻常的是，他们反而发现自己迷失了方向或者受了伤而需要帮助，这就是这本书的作用。后面的故事阐述一点：如果不能理解或者缺乏这些使Scrum有效的核心敏捷概念中的坚实基础，应用Scrum会很快陷入困境。
故事
Jeff是一名敏捷教练，他在一家大型软件公司内部帮助团队应用Scrum。一天，他收到部门的项目群经理Suzy的一封电子邮件。
“Jeff，请帮个忙。我们已经做了六个月的Scrum，但是我们的代码质量还是没有像我希望的那样提高。我想我们需要你过来和我们讨论结对编程。下周一就是我们计划周的开始，你能来吗？”
Jeff坐在椅子上。讨论结对编程相对简单，他可以带上他的朋友Julie，一个优秀的开发人员和经验丰富的敏捷实践者，没有问题。但是电子邮件中的两个字一直浮现在他的脑海中，计划周？Scrum要求有两个Sprint计划会议，每个不超过四个小时。这个团队要做一周？他感到不仅是结对编程，还有其他更多的事情需要他去做。下周一会比较有趣。
星期一，Jeff和Julie到达会议现场，发现Suzy和她的八人团队一起已经在会议室里就位了。Suzy做了一个简短的介绍以后，Jeff和Julie进行自我介绍，然后开始就Suzy告诉他们的代码质量问题进行询问。
团队很快就开始回答。首席测试员Mike首先说道：“我们的代码质量差是因为我们没有时间做测试。开发人员直到我们四周Sprint的最后一天还在写代码。‘编码与测试Sprint’应该既做编码，也要做测试。但是我们的测试要么被挤到Sprint的末尾，要么就演变为‘集成Sprint’。”
Julie打断他说道：“抱歉，Mike，你刚才说‘集成Sprint’？”她看着Suzy，Suzy点点头。
“哦，我还没有解释我们的修改，是吧？”Suzy说道，“我们知道Scrum要求每四周有一个发布，但是对于我们做的这种工作，这是不可能的。我的意思是，在我们尝试Scrum之前，我们努力按照季度来发布，这完全是一场灾难！所以我们所做的就是修改Scrum使其更好地融入我们的流程和现实。”Suzy走到白板前开始在上面写。
“首先，我们有一周来做Sprint计划；然后在四周的实际Sprint中，开发人员写代码，测试人员写测试用例；在这之后，我们就做集成，然后部署。当然，我也常常增加一周作为缓冲应急，以防万一。”Suzy说道。
她话音刚落就已经在白板上写好了以下内容。
Jeff和Julie相互看了一眼，然后又看着Suzy。团队的其他人则显得很无聊。Jeff问了一个很显然的问题：“Suzy，你们的Sprint真的是八九周吗？”
“对，”Suzy回答道，“你觉得很意外。我知道这不是正宗的Scrum，但这对我们是适用的。我想我们可能还需要增加一周，你知道吗，写规范和测试计划，把它加进去还有点麻烦。现在我们是在缓冲的那周来做，但是我真的讨厌占用我们的缓冲。”
“好，我们过会儿再讨论这个，”Julie说道。她看着Jeff，Jeff举着手好像在说：“我们该怎么办？”Julie继续问道：“Mike，你说你们没有时间做测试？”
Wyatt抢在Mike前面说：“别听Mike的。他们有很多的时间来做测试。我们才永远没有足够的时间。我们每个Sprint都费尽力气尽可能完成我们所能完成的代码。为什么我们需要整整四周？真的就需要这么长时间。”Wyatt看着Mike接着说，“自从我们开始使用Scrum以来，你和所有测试人员就一直做抱怨你们没有时间做测试。也许Scrum才是问题根源。”
Jeff和Julie交换了一下眼神。
Suzy插话说：“各位，我们在这里不是抱怨Scrum的。我们是来提高代码质量的。”她暂停了一下，深深吸了一口气，“我说这个已经有六个月了。”她对Jeff和Julie说并很快无奈地翻了翻眼珠。
Jeff点点头说：“我知道你很沮丧，我也知道Mike和Wyatt也很沮丧。我能够和团队深入一点讨论这个问题吗？看看我能不能找到问题的根源？”Suzy热切地点点头。
Jeff以他标准的第一个评估问题开始：“好的，Scrum和极限编程（XP）都要求每日有检查点。在Scrum中，就是每日Scrum站会。你们怎么评价你们的每日Scrum站会？”Jeff对团队提问。
Mike笑道：“每日会议？你开玩笑吗？我们没有时间做这些。我们每周开两次会，一共一个小时，这已经很花时间了。”
“好的，Mike，给我讲讲你们是怎么开这些会议的。”Jeff问道。
“首先，我们每次开会都说同样的事情，开发人员说他们在完成任务，我们说我们在写测试用例，这是大新闻吧。然后我们大概花20分钟左右的时间对缺陷列表进行分类，总结来说就是把缺陷列表挨个过一遍，分为‘设计造成的’和‘在下一个Sprint修改’。当然，我们从来就没有修改这些缺陷。这纯粹就是功能失调所引起的混乱。”Mike说道。
看得出，Suzy很生气，所以Jeff也给机会让她来说。
“谢谢Mike。Suzy，你的看法是什么呢？”
“Mike说对了一件事情。每日站会的确对我们不适用。我们只有每两天开一次会。我的日程太忙了，没有办法每天开会；而有些团队成员还在其他的项目上。我知道这不是理想的状况，但是我们只能这样做。让我头疼的是，即使我们每周开两次会议，团队仍然和我争论，他们认为负担太重。你听见了刚才Mike是怎么说的。他们都抱怨这些会议、时间安排以及没有足够时间！但是我也无法拒绝管理层要求我们更快发布。更何况，就像我一直告诉他们的那样，这是我的项目。我制定计划，我组织团队。告诉他们，Jeff，我是ScrumMaster。他们应该按照我说的去做，对吧？”Suzy迫切期待着Jeff的肯定。
Jeff不置可否地耸耸肩，保持沉默。他开始意识到他们对Scrum的了解是多么的贫乏。他看了一下Julie，给她一个表示他们还不懂的表情。Julie轻轻点头回答。Jeff继续他的评估。
“好的，我听见了。我们先讨论我们现在的问题。看上去一个潜在的问题是你们的每日站会没有每天都开，没有生产力，持续时间太长。我们可以纠正它。让我们先把这个问题放一放，把我们的思考过程提高一个水平。告诉我，你们为什么会采用8周的Sprint？”
Wyatt发话了：“我在这里已经有十年了，我见过这里所有流行过的东西，它们瞬息即逝。但是这次我是一个盲从者，我真的认为Scrum可能不一样，这是不是有点不可思议！整个事情起源于管理层要求我们更快发布。我们已经做到了按季度发布。让我告诉你，从年度发布到季度发布，真的很困难，但是我们实现了。但是对于管理层，这还不够快，是吧？”Wyatt会儿停了一会儿，环视了一下会议室，希望得到回应。
他继续说道：“所以，有一天我和Suzy坐在一起吃午饭，刚好遇到在另外一个部门工作的我的一个同事。他告诉我们他的团队正在使用Scrum，他们如何每四周就交付一次，而且他们如何高兴。他说他们突破了质量的天花板，管理层已经很多年没有这样满意过，客户也很欣喜。你知道吗，这个人和我一样是个怀疑论者。所以我想如果他都说Scrum有效果，就肯定有效果。Suzy和我就花了一个下午的时间向他学习Scrum。Scrum看上去非常简单，但是也有一些问题。首先就是那些每日站会，谁有这么多时间呢？我们就简单改为每周两次。然后四周为一个周期显然对我们不适用，毕竟我们几乎不能做到以季度为周期，所以我们决定加倍成为八周为一个周期。以此为基础，我们就把我们的工作流分解到八周里面，就是把所有的事情都压缩下来。毕竟，Scrum只是另外一种增量开发的流程而已。”
Jeff和Julie又相互看了一眼。
Wyatt继续说：“我看见你们的表情了。但是我告诉你们，我们了解自己的团队和产品。原汁原味的Scrum我们可能用不上，所以我们做了任何一个软件团队都会做的事情，那就是根据我们自己的需要对Scrum进行修改，按照最符合我们过去做事方法进行组织。”
“对，”Suzy确认道：“我的意思是，Scrum是项目经理管理工作的一种方法，只不过周期更短而已。”
Jeff往后坐了一下，他准备的评估问题不是为这种情况而设计的，他还不确定现在该说什么。Julie挺身帮助他：“你们有一个通用的‘完成定义’吗，Wyatt？”
“我们当然有啊。第一周后，我们有设计评审会；然后在第五周结束的时候，我们有代码完成的里程碑；在集成结束的时候，我们有完成测试和集成。一旦我们完成这些里程碑，我们就发布上线。这真的不难理解。”Wyatt说道。
“对，这很简单，我明白。”Julie安慰道，“团队，刚才Wyatt、Mike和Suzy解释了你们的流程。我的理解是你们有每周两次的站会，八周（有时候九周）的Sprint，而且在特定的关键时期也有检查点，这样你们就知道你们完成了。这样的工作方式你们感觉怎么样？你们感觉工作有乐趣吗？代码质量提高很多了吗？”Julie问道。
“嗯，还不错，”Wyatt回答道。
“不错？！”Suzy问道，“简直糟糕透了。”
“这样糟糕不是我们的过错！我们试图做测试，但是就像我讲的那样，我们没有时间做！”Mike高声叫道。团队的其他人盯着桌子，没有参与这个争论。
“Mike，虽然我可以，但是我没有指责你，没有。真正的问题是Scrum，”Wyatt说道，“这是一个愚蠢的流程，它根本就不适用。”
“不要又讲这个，”Suzy说道，“这个问题我们要争论多少次？每次回顾会议我们都在争论这个问题。”
“回顾会议？”Wyatt插话说：“这只是一个名字听着好听的两天一次的垃圾会议。回顾会议不能改变任何事情。Scrum不能改变任何事情。我收回这句话。Scrum的确改变了一件事情，就是使得我们都很悲摧。”
“Wyatt，使用Scrum也是你的主意。既然你所做的就是破坏这个流程，当初你为什么要首先发起呢？”Suzy激动地问道。
Jeff站出来了。现在应该是停止提问并开始让团队面对真相的时候了。
“瞧，这不是那一个人的过错，也不是Scrum的过错。对于我来说，我相信Julie也会同意，看上去你们并没有真正在做Scrum。你们所做的和过去做的是一样的，只是压缩到八周的一个周期中。你们把这个就称为Scrum。”
Wyatt和Suzy准备开始争辩，但是Julie举手制止了他们。“让我问一个问题，是问团队的。Wyatt、Suzy和Mike，请你们不要回答。”Julie在先看了看会议桌团队的每一个人，然后继续说道，“这种新的工作方式使得你们的工作更糟糕呢，还是一直就是这样，可能只是没有这么明显？”Julie问道。
每个人都低着头，看得出他们陷入了沉思。
“过去也很糟糕。”会议室后面传来了一个声音。
“对，”另外一个团队成员说：“我只是没有意识到过去有这么的糟糕。”
随着团队的自我觉醒开始萌芽，会议室陷入一阵沉寂。
Wyatt叹气一声说道：“你说的对。过去也没有比现在好多少，只是没有现在这么明显。我们原来是每个季度感受一次痛苦，现在是每八周感受一次。”
Mike插话说：“知道吗？看看过去的六个月，我们发现了很多应该而且能够解决的问题，但是我们什么也没有做，真的没有。”
Suzy打断了他。
“伙计们，我真的累了。我们能够推迟几天再来讨论吗，下周？”她问道。
团队点头同意，他们也累了。
Suzy离开会议，意识到事情很糟糕。她花了一个周末以及下一周的前半段来思考如何推进工作。她召开了另外一个会议并把Jeff和Julie也邀请回来，她希望以此为团队确定一个新的基调。
“各位，我感到很抱歉。”她以此开始会议，“我知道事情有些糟糕，但是我不知道是那么糟糕。我原来是请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说道。
“肯定的。我会从基础开始并随着问题的出现逐个解决。肯定会经常出现困难，但是他们能够做到。没有痛苦，就没有收获，对吧？”
Scrum
Scrum看上去很基本，但是很多人不能明白的是，要做好Scrum，就必须从根本上改变原来开发软件的方式，而这并不容易做到。你会挣扎，你会遇到障碍。我们故事中的团队以其所经历的艰难历程发现了这一点。如果你拿起这本书，你可能也已经意识到了这个问题。为了理解为什么这么简单的事情做起来居然可以这么困难，让我们深入探究一下Scrum。
什么是Scrum
《危险边缘》（Jeopardy） 是我最喜欢的电视游戏节目之一。我一直希望有一个类似的关于软件开发的版本，其中有这样一些类别：方法和框架、导致软件故障的常见原因、著名的软件架构师以及聪明人说的傻话。我可以想出一大堆符合这些类别的问题，比如，“说出是谁，据说他说过‘对书呆子要友善’；‘你可能到头来会为我工作’。”我设想在“方法与框架”这个类别里面，可以有这样一个问题：“说出一个美式橄榄球的术语，这个项目管理框架可以每两到四周就交付可工作的软件。”一个可以接受的答案，当然是以问题的形式，就是“什么是Scrum？”
那么究竟什么是Scrum？Scrum不是一个方法或者一套工程实践。它其实是一个轻量级的框架，设计初衷是管理软件和产品开发。Ken Schwaber和Jeff Sutherland [Schwaber 01]是这样描述的：
Scrum是一个框架，在这个框架中人们可以解决复杂的适应性问题，同时以高效生产力、创造性方式交付价值最大化的产品。Scrum有以下三大属性：
？ 轻量的
？ 简单易懂的
？ 十分难以掌握的
Scrum是一个流程框架，从二十世纪九十年代早期就被用来管理复杂产品的开发。Scrum不是产品制造流程或者技术；相反，它是一个框架，在这个框架里面，你可以使用各种流程与技术。Scrum把产品管理和开发实践的效率清楚展现出来，以便于后期持续改进。
Scrum依赖于固定节奏的迭代周期，称为Sprint。每个Sprint以计划会议开始，以对潜在可交付产品的演示而结束。Scrum的特征是团队内外的反馈和透明。它的短周期和协同的本质使其相当适用于快速变化或者有紧急需求的项目。
Scrum建立在五个核心价值之上，它有三个不同的角色、三个工件以及三四个会议。关于Scrum机制的更多细节，可以参见附录“Scrum框架”。
实施Scrum
尽管Scrum看上去可能很容易实施，它实际上很有挑战性。为什么？因为它的实施不仅局限于设置好正确的机制，然后按一下按钮。正确实施Scrum需要团队愿意做出以下改变。
？ 理解Scrum的价值观。
？ 往往要经历巨大的思维方式的转变。
？ 准备变化的发生并适应变化。
？ 处理新暴露出来或新冒出来的问题。
？ 引入敏捷工程实践。
Scrum的基本价值观
任何有使用价值的框架都是建立在一些原则与价值之上的。每一个原始的敏捷实践：XP、Scrum、DSDM、Crystal、FDD以及看板和精益，都有一套核心价值。这些价值给我们指明方向；在我们困惑的时候进行澄清；最重要的是，帮助我们理解我们为什么要这样做。就像你从前面开篇故事中读到的那样，这个团队试图使用Scrum，但是他们不理解为什么要这么做。他们不理解Scrum框架的基本价值观：专注、尊重、承诺、勇气以及开放[Schwaber 02]。
专注。专注的意思是将注意力转移并集中到某件事情上。在Scrum中，为了交付潜在可发布的功能增量，团队必须专注于为此所需要完成的所有事情上。专注意味着在一段时间内只做一个项目。这也意味着有专门的“团队时间”，在此期间，整个团队屏蔽任何电子邮件、即时通信、手机以及会议干扰。专注就是团队在所有Sprint的整个周期里面使团队集中精力做手中的交付任务。
尊重。我们都知道尊重是靠赢得的，而不是赋予的。这一点在Scrum中特别正确。尊重团队同事或者缺乏这种尊重，可以成就项目或者导致项目的失败。高效率Scrum团队成员之间彼此信任，足以做到坦诚自己碰到的障碍。当某个团队成员承诺了一项任务，他们相信这个团队成员会自始至终完成这项任务。在一个真正的Scrum团队里面，没有你我之分。在本章开篇的故事里面，测试人员与开发人员明显有争执而且相互之间没有足够的尊重。幸运的是，他们相互之间还没有完全失去尊重，他们最终团结在一起便是明证。
承诺。承诺是对交付的保证、誓言与义务。团队不能轻许诺言，他们必须根据大量信息来做出承诺。在每个Sprint计划会议上，团队对组织以及成员相互之间做出承诺。在Sprint计划会议结束的时候，团队的每一个成员必须对团队承诺在Sprint中需要实现的目标达成共识。
勇气。勇气是克服恐惧面对困难的能力。克服恐惧是团队和组织帮助团队成员鼓起勇气最好的方法之一。团队可以做到开诚布公以建立共识，组织能够证明它会客观听取坏消息，这都有助于团队成员勇于表达自己的想法。记住，如果团队缺乏勇气做自己认为正确的事情，就极有可能做不好事情。
开放。开放使我们能够善于接受新的想法。在Sprint回顾会议中，团队的开放是最明显的。愿意接受新的想法、观念与思考方式可以帮助我们成为学习型组织和高效率团队。
Scrum需要转变思维方式
爱因斯坦说过：“我们不能用产生问题时使用的思维方式来解决问题。”成功应用Scrum（或者就此而言，任何敏捷方法），最大的障碍就是不具备转变思维方式的能力，或者说不具备使用新的思考方式来解决问题的能力。因此至少在最初的三到六个月以内，Scrum和所有的敏捷实践都需要某种程度的开放心态。在我工作的第一个Scrum项目中，我几乎花了一年的时间才真正理解什么是Scrum。
在那一年中，我明白了Scrum是一个强大的但同时也是一个危险的工具。你看过情景喜剧《家居装饰》（Home Improvement）吗？剧中的主角“工具人”Tim Taylor在使用崭新发亮的新工具时，常常因为没有采取安全性防卫措施而惹上麻烦，比如没有按照原来的设计用途来使用，或者咬掉了他不该去掉的东西。Scrum也是一样。如果没有按照它的指令来使用，特别是在最初的时候，Scrum可以使你的项目很快变得很糟糕。很多团队浅尝辄止，自以为懂得更多了，认为他们的实际情况有所不同，于是按照自己的方式来应用。
听我一句忠告：在决定定制Scrum之前，一定要先理解Scrum。按照它本来的意图，不做修改直接拿来就用。花一些时间尽你所能好好学习它。在你的大脑中留下一些空间，让这种知识生根发芽，就像泡茶一样。对于从事软件开发的读者来说，大脑中留出一些内存地址空间给这种知识。不要，我重复一次，不要在这个时候尝试把Scrum和你熟悉的其他一些工具组合使用，现在还不是时候。只有掌握了一种工具之后，你才能够学会把它和其他工具成功结合在一起使用。最重要的是，你要有能力与纪律给Scrum一个公平的机会，特别是Scrum本来就有挑战与困难。你会惊讶地发现，几乎不需要修改Scrum，最终也能实现思维形式的巨大改变。你也许会认为这有悖于敏捷宣言的第一条价值：“个体与交互胜于流程与工具。”相反，正是个体与交互才使你能够学习使用Scrum（或者其他任何敏捷实践），坚持这一点有助于你对判断什么才是最有效的。
Scrum采用最短路径，而不是预设路径
项目中最长的路径被称为“关键路径”或者“限速路径”。我们依据关键路径制定并执行计划，从A点到B点。沿着关键路径执行项目，问题开始出现：比如在制定计划的时候，项目干系人并不知道他们究竟需要什么；在产品的生命周期中业务目标发生了变化；项目响应内部与外部的因素，比如竞争对手的产品发布以及其他各种在开发过程中经常出现的问题。几乎每个项目都可能发生这些状况，并不局限于软件项目。
使用传统的项目计划方法，即使出现这些问题，我们也仍然被迫从A点执行到B点，在此过程中牺牲质量、功能以及客户满意度。一旦终于到达B点，我们才开始检查积累的问题并开始制定到达C点的计划。C点是我们发现需要到达但仅仅因为计划不容许而未到达的地方（参见图1-1）。
图1-1 传统的计划方法
在Scrum中，我们承认前面提到的各种问题都可能发生，它们是无法改变的现实。不同于制定一个完美的计划来全面应对各种问题，我们接受这些问题会发生的事实，并建立一个机制使得我们可以处理项目过程中出现的问题，以便我们可以直接到达C点，而不必经过B点。
......

我的女儿Emma（爱玛）出生于2004年末，我感到力不从心，我们在医生办公室的时间似乎多于与其他孩子在一起的时间。我一直问我妻子：“这是正常的吗？”一个晚上，我在枕头边上发现我妻子那本书《新生儿父母手册》，里面有她写的一张小纸条：“读读这本书，你会好受一点。”
我读了。由此我知道了我们所经历的每件事情对于我的孩子都是正常的，即使对我或我以前观察到的来说不常见。这使我感到更有信心与安全感。这也正好是我开始试验Scrum与敏捷的时间。随着我开始遇到障碍与面临不熟悉的情况，我开始认识到，在做Scrum与敏捷的第一年，我真正需要一本指导手册。
问题在于，不像一本指导手册，我不可能准确告诉你，在第1～3月或者9～12月，你的团队应该做什么或者是应该担心什么。团队并不像小孩那样，不会以一个可以预测的速度发展。相反，在他们第一年的实践中，随着他们学习团队合作、采用敏捷工程实践、与他们的客户建立信任、以增量迭代方式工作的过程中，他们常常摔倒、蹒跚、犯错误，前进两步就倒退一步。
有鉴于此，我更倾向于以这种方式“我遇到了一个问题，该怎么办”来组织这本书。我收集了我参与过或者见证过的、在他们第一年敏捷旅途中的那些团队的故事。随着我继续我的敏捷旅途，我注意到各个公司中这些故事、模式通常都很相似。我在一个公司中实现一个想法，稍微调整一下就可以应用在下一个公司中。重复这个过程，我得以收集了这些现实世界的解决方案，并把它们加入我随身携带的虚拟工具带。在这本书中，我将与你分享一些最常见的痛苦与解决方法。当你的团队遇到麻烦或者是受伤的时候，你可以找到最接近你的症状的那一章，然后你可以发现，即使不能解决你的问题，至少也有一个办法可以减轻你的痛苦。
《Scrum实战》旨在帮助你精心调试你自己的实践，在一些你不熟悉的领域提供指南，以及在前进的道路上更轻松地克服我们都遇到过的困难。