第一章
世界的运作方式已经打破

对杰夫·约翰逊（Jeff Johnson）来说，2010年3月3日绝不是个好日子。那天，联邦调查局取消了其最大的、最雄心勃勃的计算机系统现代化改造项目。联邦调查局本来期待着通过这个项目防止“9·11”事件的重演，但它却变成了软件开发史上最大的灾难。联邦调查局花费了将近10年的时间去更新它的计算机系统，但这个项目似乎将以失败而告终，而这要归咎于约翰逊。

约翰逊在7个月前来到了联邦调查局。吸引他的人是联邦调查局新任首席信息官查德·弗格汉姆（Chad Fulgham）。约翰逊与弗格汉姆曾经一起供职于雷曼兄弟。约翰逊在雷曼兄弟工作期间担任信息技术工程部门的总监助理，在华盛顿市区的胡佛大厦（J. Edgar Hoover Building）顶层拥有一间很大的办公室，甚至能够一眼看到华盛顿纪念碑。当时，约翰逊万万没想到他在之后的两年时间里要在一个没有窗户、用煤渣砖建成的地下室里办公，去完成一项每个人都认为无法完成的任务。

“那绝不是一个轻松的决定。”约翰逊说。他和他的上司已经决定宣告项目失败，并终止开发。那个项目已经耗费了将近10年的时间和上亿美元的资金。此时，收回项目、自行开发是比较合理的决定，但约翰逊表示：“这个项目应该做下去，而且还要做好。”

这个项目的目标是开发出一个备受期待的计算机系统，以便推动联邦调查局迈入现代化。2010年，脸谱网、推特、亚马逊和谷歌正在蓬勃发展之际，联邦调查局大部分报告的存档却还要依靠纸张。联邦调查局一直以来使用的系统是“自动化案件支援系统”（Automated Case Support System），但这个系统赖以运作的基础是在20世纪80年代还算先进的大型计算机。而当前这个系统过于笨重烦琐，运行缓慢，因此，在这个恐怖袭击频发、犯罪分子行动迅速的时代，很多特工都不愿意使用它。

当联邦调查局的特工想要做某件事情的时候，其实是做任何事情的时候，比如，为了追捕恐怖分子而向线人购买消息，或者把一份关于银行劫案的报告归档，那么他要经历的工作流程与30年前相比没有多大区别。约翰逊是这样描述的：“你要先在文字处理器中把内容敲出来，然后打印3份。第一份进入审批环节；第二份要存放起来，以防第一份丢失；第三份你要拿一支红笔——我不是在开玩笑，的确是一支红笔——把关键词圈出来，输入数据库中。你必须为你自己的报告做索引。”

上级核准请求之后，文件就会从楼上回到楼下，上面会多出一个编号。这个编号就是联邦调查局用来追踪所有文档的依据。这种管理方式的确太落后、太松散了，当初联邦调查局之所以没有及时制止“9·11”事件，这种管理方式负有很大一部分责任：联邦调查局明明在“9·11”事件爆发之前的几个星期就知道有多名基地组织的激进分子入境美国，但没有把各种迹象关联在一起加以考虑，有人认为部分原因就出在档案管理系统上。当时联邦调查局的某个部门对某个目标产生怀疑，另一个部门对于有这么多外国人在接受飞行训练感到蹊跷，还有一个部门则把基地组织的某个成员列进了监视名单，但从没有通知其他部门。在联邦调查局内部，没有人把这些琐碎的片段拼接在一起加以思考。

“9·11”独立调查委员会在恐怖袭击后深入追查，试图找出事情发生的关键原因。该委员会表示，情报分析人员没有精准地获取他们应该分析的情报。报告中写道：“联邦调查局的情报系统效率较差，这就意味着情报分析人员要从某个部门或工作组那里取得情报，在很大程度上取决于他同有关人员的个人关系。”

在“9·11”事件爆发之前，联邦调查局之所以没有对美国面临的恐怖主义威胁做过完整的评估，原因固然有很多，比如工作人员过于注重个人的晋升、彼此之间缺乏信息分享等，但调查委员会的报告却特别指出，先进信息技术的缺乏可能是联邦调查局出现严重失职的一个关键原因。报告得出的结论认为：“联邦调查局的情报系统存在令人悲哀的缺陷。”同时还指出：“联邦调查局根本不知道自己缺少什么，它缺少的是一个能够有效捕捉或分享信息的机制。”

每当有参议员向联邦调查局提出一些令人感觉不舒服的问题，联邦调查局基本上都回应说：“别着急，我们已经上马了一个现代化项目。”该项目要开发一套“虚拟案件档案系统”（Virtual Case File System），人们期待它能改变一切。联邦调查局官员会不失时机地利用每一次危机去要钱，说除了原来的1亿美元之外，再拨付7000万美元就足够了。如果你翻出之前媒体对于“虚拟案件档案系统”的报道，就会发现字里行间充斥着诸如“革命性”“变革”等字眼。

过了3年，这个项目却被毙掉了，因为行不通，毫无作用。联邦调查局花掉了1.7亿美元的税金，换来的计算机系统却没有人使用，所有代码、应用程序都没有发挥作用，也没有人用鼠标去点击它。整个项目就是一个不折不扣的灾难。要知道，联邦调查局的这场灾难还不能简单地等同于IBM公司或微软公司在研发过程中出现的错误，因为联邦调查局的错误涉及民众的生命安全。民主党人、来自佛蒙特州的资深联邦参议员帕特里克·莱希（Patrick Leahy）当时担任参议院司法委员会主席。他曾经对《华盛顿邮报》表示：

我们掌握的信息本来可以阻止“9·11”事件，但这些信息却一动不动地搁置了起来，没有人根据这些信息采取行动……我还没有看到联邦调查局的人改正问题……要他们掌握21世纪的技术，我们可能要等到22世纪了。

当“虚拟案件档案系统”遭遇灾难时，很多曾经供职于联邦调查局的人已经都不在那里工作了，这种现象更加令人相信莱希所言不虚。

2005年，联邦调查局宣布了一个名为“哨兵”（Sentinel）的新项目。他们认为，这次一定行得通。他们这次一定会做好预防措施，一定会做好预算流程，一定会控制好整个过程，毕竟他们已经得到了教训。那么，这个项目耗费几许呢？寥寥4.5亿美元而已，而且2009年就能全面投入使用。

还有哪些地方可能出错呢？2010年3月，答案落在了约翰逊的办公桌上。到那个时候，被雇来开发“哨兵”系统的洛克希德·马丁公司已经花掉了4.05亿美元的经费，但开发进度只完成了一半，而且比原计划延误了一年。根据一项独立分析的评估，要完成整个项目的开发工作还需要6~8年，而且纳税人将不得不再砸进去3.5亿美元。

找到某个解决办法，就成了约翰逊面临的一个难题。

本书分析了问题出在哪里以及约翰逊是如何解决问题的。之所以出这些问题，原因并不是这些人不聪明，不是因为联邦调查局用错了人或技术，也不是因为这些人缺乏职业道德或外部竞争。

问题出在工作方式上，也就是大多数人的工作方式。我们之所以都认为工作应该通过某种方式去完成，只是因为别人就是那样教我们的。

初次听到他们的工作方式，你会觉得很有道理：洛克希德·马丁公司的人在投标前先坐下来审视所有的需求，然后开始规划如何开发一套能够满足所有需求的系统。他们拥有很多才华横溢的员工，连续工作好几个月去规划要做哪些事情。他们绘制出很多美观的图表，解释每一件必须做的事情，然后小心挑选颜色，以环环相扣的方式展示整个项目的各个部分，整个示意图就像一道瀑布一样倾泻而下。

这种图被称为“甘特图”，这个名字是为了纪念它的发明者亨利·甘特（Henry Gantt）。随着个人计算机在20世纪80年代的出现，人们很容易就绘制出了这种看起来错综复杂的图表，而且复杂程度越来越高。甘特图甚至变成了一种艺术品。整个项目中的每一个步骤、每一个里程碑式的事件以及每一个交付日期都详细地列了出来。人们看了这种图之后，确确实实会产生深刻的印象，但这种图唯一的问题就是它们往往是错误的，无法真正得到落实。

甘特是在1910年左右发明这种图的。甘特图最初由时任美国陆军军械部部长的威廉·克洛泽（William Crozier）将军应用于第一次世界大战。任何研究过那场战争的人都知道高效的组织能力并不是它的一个鲜明特色。我一直不是很明白为什么“一战”时期的东西会变成21世纪项目管理中的实用工具，而且我们现在已经不再进行壕沟战了，但用于组织壕沟战的一些思维方式依然非常流行。

这种甘特图的确具有一些令人难以抗拒的优点。比如，在一个庞大的项目中，所有需要做的工作都会被清晰地列出来，让每一个人看清楚。我拜访过的很多企业都指派专人负责每天更新甘特图。问题在于，这种制作美观的甘特图在现实中往往行不通。但管理者非但没有废止这种规划，反而雇用一些人去掩盖现实，假装甘特图很有用。从本质上来讲，他们这种做法无异于雇人对自己撒谎。

这种不幸的模式与苏联政治局在20世纪80年代收到的报告具有一定的相似性。当时，苏联已经走到了崩溃的边缘，那些报告充斥着虚假信息，脱离现实。如同过去一样，现在报告本身的重要性竟然超越了所描述事实的重要性，而且如果存在冲突，人们往往认为问题出在现实上，认为图表是正确的。

当我在西点军校读书时，曾经住过艾森豪威尔原来住过的宿舍。夜里，街灯的亮光照在壁炉台的金属板上，有时候会把我弄醒。那块金属板上写着：“德怀特·艾森豪威尔曾经在此睡过。”我记得艾森豪威尔曾经说过，战斗规划是很重要的，但一旦第一枪打响之后，你的规划就会烟消云散。至少他很聪明，没有使用过甘特图。

因此，当洛克希德·马丁公司向联邦调查局出示那些精美的甘特图时，联邦调查局就在上面签字同意了。按理讲，任务规划得非常完美，不会出现什么差错。“看，一切都绘制到这份彩色的、标明了时间、绘着条形图的规划里了。”

然而，到了2010年春季，当约翰逊与他的上司、联邦调查局首席信息官查德·弗格汉姆回头审视规划的时候，他们终于明白这些图纯属虚构。当这两个人开始查看真实进展和成果时，他们意识到问题已经超出了他们的解决能力。软件缺陷的出现速度远远超出了修复速度，根本补救不过来。

查德·弗格汉姆告诉美国司法部总检察长，只要收回来自行开发，减少开发人员的数量，就能完成“哨兵”项目，但这种做法意味着必须在剩下不到20%的时间内、用不到1/10的预算，完成最富挑战的另一半工作。总检察长向国会提交的报告直截了当地表示对弗格汉姆的说法持有怀疑态度。2010年10月的报告中，司法部针对弗格汉姆的提议列出了9点关切之后，得出的结论认为：“总而言之，对于这种新方法能否在预算范围内及时研发出具有类似功能的系统，我们表示严重忧虑和质疑。”

一种新思维

我在这里要讲的新思维叫作Scrum，是我在20多年前发明出来的。现在，事实表明，它是唯一经过实践检验的、能够挽救上述项目的办法。开发项目的方式有两种：一种是瀑布法，一种是Scrum法。前者耗费数亿美元，却常常无法交付成果；后者则能够用较少的人和较少的成本在较短的时间内交出更多更好的成果。我知道，这听起来似乎有点不真实，但实践表明这种方法的确行得通。

20年前，我曾经陷入一种绝望的境地。我迫切需要一种新的工作思维。通过不计其数的研究与实验，并回顾过去的数据，我意识到我们都需要一套新思维来组织人力资源的活动。这种新思维并不像火箭科学那样高深莫测，难以理解，而是我们之前曾经讨论过的。有些研究试图找出“二战”时期一些较为优越的工作方式，但不知道由于什么原因，人们从来没有真正地把碎片化的发现成果整合到一起加以分析。过去20年间，我一直努力地做这件事，现在这种方法已经开发出来，我最先将其应用于软件开发领域。谷歌、亚马逊以及Salesforce.com等大型公司以及其他许多你从未听说过的小型初创公司都采用这套架构来革新自己的工作方式。

这种架构之所以奏效，原因很简单，因为我看到的是人们实际上怎么工作的，而不是他们嘴上宣称自己是如何工作的。我审视了数十年来的有关研究以及全球企业的最佳做法，也深入了解这些企业内部的最佳团队如何运作。是什么让出色的企业在激烈的市场竞争中脱颖而出？这些出色企业的与众不同之处有哪些？为什么有的企业做得红红火火，而有的却平平庸庸？

我将这种有助于改善团队业绩的方法称为Scrum，具体原因我会在之后的章节中详细叙述。这个词语原本是橄榄球运动的一个专业术语，原意为团队通力合作，在场地内传球。这个过程需要认真配合、信念一致和目标明确。这个过程完美地体现了我对一个团队的所有要求。因此，我把这种敏捷开发流程命名为Scrum，其实就意味着这种流程就像大家在一起打橄榄球，敏捷的动作、彭拜的激情、力争上游的拼搏精神，无一不是现在软件开发中迫切需要的元素。

传统上，任何项目的管理都需要实现两个目标：可控性与可预测性。这样一来，就会出现大量的文件与图表，就像洛克希德·马丁公司的情况那样，花费长达数月的时间去规划所有的细节，确保不会出现任何疏漏，不会超出预算，每件事情都能按照计划完成。

但问题是这种美好的设想往往不会变成现实。虽然付出了大量努力去规划细节，限制潜在变化，并预测未知因素，但到最后这些努力终将徒劳无功。每一个项目在开发过程中都需要人们去发现新问题，去激发自己的灵感。试图把人类行为限制在充满彩色编码的图形和曲线里，是一种愚蠢的、注定要失败的做法。人们不应该以这种方式工作，不应该用这种方式去管理程序、开发项目，也不应该用这种方式去落实好点子或者做伟大的事情。

这种传统方法只会导致人们因为无法达到目标而产生挫败感。项目延期，费用超支，甚至完全惨败的例子都是很常见的。对于那些从事创造性工作的团队而言，这种情况尤其常见。管理者往往要等到已经投入数百万美元，辛苦了数千个小时之后才意识到自己原来走上了一条通向失败的下坡路。

掌握Scrum方法之后，我们就不禁会问：为什么人们做一件事情要投入那么多时间和精力？为什么人们就那么不善于预测一件事情需要耗费的时间和精力？法国沙特尔大教堂用了57年才建成。我可以百分之百地确定，当建造教堂的项目刚刚开始启动时，石匠肯定对主教说：“最多用25年，可能15年就建好了。”

Scrum方法充分考虑到了可能出现的不确定性因素，同时具有鲜明的创造性。它的结构是围绕着学习过程建立的，这样一来，团队既可以评估已经取得的成果，同样重要的是，也可以评估取得这些成果的方法。这种架构能够为团队提供更加高效的工作方式，帮助他们更好地自我组织，提高工作速度，改进工作质量。

究其本质而言，Scrum方法很简单：无论你什么时候启动一个项目，为什么不经常检验一下自己正在做的事情，看看是否朝着正确的方向前进？结果是不是大家真正希望看到的？是否有什么办法能改善目前正在做的事情？如何才能做得更快更好？存在哪些潜在的障碍？

这就是我所说的“检查与调整”循环。每过一小段时间就停一停手头的工作，检查一下已经取得了哪些成果，看看这些成果是不是自己期待的，想想有没有更好的方法。这一点看似容易，做起来并非易事，需要有思想，善于自省，有实事求是的精神和自我约束的意识。我之所以写这本书，就是要教你如何做到这一点。Scrum方法除了应用于软件公司之外，我还见识过它在其他方面的成功应用，比如制造汽车、经营干洗店、在教室里为学生教课、制造太空飞船、规划婚礼等，甚至我的妻子也曾经运用这个方法确保我每周末完成她交办的家务活儿。

Scrum的最终结果（如果你愿意，也可以将这种结果称为利用Scrum方法进行制度设计的最终目标）就是大大提高团队的工作效率。过去20年间，我先后多次打造出了这样的团队。我曾经在十多家公司中担任过首席执行官、首席技术官或工程部门主管，其中既有几名员工挤在一间办公室里的初创小公司，也有办公室遍布全球各地的大公司。此外，我还为其他数百家公司提供了咨询和培训服务。

Scrum的效果非常引人注目，一些主流的研究分析公司，比如高德纳咨询公司（Gartner）、弗雷斯特研究公司（Forrester Research）、斯坦迪什集团（Standish Group）等，现在都纷纷表示原有的那种注重“命令与控制”、刻意追求可预测性的工作方式已经落伍了，如果竞争对手采用了Scrum，那么那些故步自封、因循守旧的公司注定要失败。新旧两种工作方法之间的差别太大了。比如，位于波士顿的OpenView（我在该公司担任高级顾问）等多家风投公司都表示，Scrum带来的竞争优势简直太大了，你不得不用它。他们个个都是目光犀利、追求利润的投资者，他们简明扼要地表示：“结果是不容置疑的。公司只有两个选择：要么改变，要么倒闭。”

联邦调查局：“哨兵”项目的新生

在联邦调查局，“哨兵”项目团队面临的第一个问题就是合同。要做出每一个改变，都要与洛克希德·马丁公司重新谈判。因此，约翰逊与弗格汉姆花了好几个月才解除了所有合同，将这个项目收了回来，改为内部研发，团队成员的数量从数百人削减到了不足50人，核心团队的规模更小。

在第一周里，他们做的事情与其他处于相同境地的人做的事情一样：把所有需求列好，并打印出来。你可能没有见过在大项目中打印出来的这类文件，多达好几百页，甚至好几千页。我还看到过堆起来高达好几英尺的。我先后在多个项目中看到过这种情景：人们剪剪贴贴，复制到样板文件中，但实际上谁也没有认真读过这些成百上千页的文件。他们不可能读下去。结果，问题就来了，他们建立的这种制度无异于强迫自己一味地空想。

约翰逊说：“光需求就有1100项，文件堆起来高达几英寸。”只要想象一下那些文件，我就为那些人感到可怜，他们花费了好几个星期的时间去弄了一堆没有用处的文件。存在这种现象的公司绝不仅仅局限于IBM公司和洛克希德·马丁公司，我合作过的几乎每一家公司都曾经上演过这一幕。正是因为这种徒劳无益的现象非常普遍，所以，Scrum能够为人们带来显著的改观。任何人都不应该将生命浪费到没有意义的工作上，因为这不仅没有价值，还会扼杀心智。

他们把需求逐一列出之后，就开始梳理一遍，然后确定下来每项需求的优先顺序。这一步比我们所想的更为重要，也更为困难。通常，人们索性会说每个需求都是重要的，但他们需要问一下自己，究竟哪一项任务能够给整个项目带来最大的价值？“哨兵”项目开发团队就给自己提出了这样一个问题。哪些任务能够带来最大价值，哪些就应该优先完成。在软件开发领域，有一条根据数十年研究工作总结出来的原则，即在任何一款软件中，80%的价值来自20%的功能。请想一想：你上一次使用微软Word软件的Visual Basic编辑器功能是什么时候？可能你根本不知道Visual Basic是什么，更不用提为什么要使用它了。但这项功能确确实实就在那里，而且肯定有人花了不少时间才开发出来，不过我敢向你打包票，这项功能不会给Word软件增添多少价值。

如果人们按照价值高低对各项任务进行排序，那么就能促使人们优先完成最有价值的那20%。等到这些任务完成之际，他们就会意识到他们其实并非真正需要另外那80%，甚至一开始显得重要的任务可能到最后已经显得不重要了。

对于“哨兵”团队而言，问题就变成了：“好吧，我们这个至关重要的大项目已经耗费了上亿美元，接下来怎么收场呢？”经过一番斟酌，他们承诺在2011年秋季交付产品。2010年秋季，总检察长的报告提到这个承诺时，充满了质疑的语气：

联邦调查局说它将采取一套所谓的“敏捷方法论”（agile methodology）去完成“哨兵”项目，而且从联邦调查局、洛克希德·马丁公司以及零件供应商那里调用的人员数量更少。总体来看，联邦调查局预计把“哨兵”项目的用人数量从220人左右削减到40人。同时，联邦调查局说，指派到这个项目的联邦调查局雇员的数量将从30人减少到12人……联邦调查局告诉我们，它相信只利用“哨兵”项目预算中剩余的2000万美元，并且只需要12个月就能完成这个项目。

“敏捷方法论”这个词语的运用显示出总检察长对Scrum的了解很少。“敏捷”这个词语可以追溯到2001年的一场秘密会议，在那次会议上，我与另外16位软件开发领域内的领军人物共同拟定了众所周知的《敏捷软件开发宣言》，宣布了以下几种价值：人胜过流程、可以使用的软件胜过面面俱到的文件、客户合作胜过合同谈判、应对变化胜过遵循计划。Scrum只是我用来实现这些价值的一个架构，算不上“方法论”。

当然，约翰逊“12个月交付”的承诺具有一定的误导性，因为在现实中，他们并不知道自己何时能完工，而且他们也不可能知道。联邦调查局不知道他们团队的真实进度。我经常对公司的高管们说：“我只能在看到团队的进度之后才能知道完工时间，才能知道他们能做得多快，才能知道他们的进度能加快多少。”

当然，另外还有一件至关重要的事情，即开发团队必须明确哪些障碍会拖累进度。约翰逊说：“我负责消除障碍。”“障碍”这个概念来自日本丰田汽车公司的生产系统。该公司的很多想法后来都成为Scrum架构的理论源泉。如果说得再明确一些，那就是Scrum的很多理念都受到了大野耐一（Taiichi Ohno）建立的丰田生产系统的启发。

我在这里不会详细阐述所有细节，只是着重提一下大野耐一提出的一个关键概念，即流畅（flow）。他认为，整个生产流程之内的各个环节应该做到无缝衔接、迅速流畅地接续下去，管理团队的一个重要任务就在于确定并消除生产流程中的障碍，任何障碍都是一种浪费。他在经典著作《丰田生产方式》一书中从道德与商业角度给出了自己对于浪费现象的评价。他指出：

可以毫不夸张地说，在一个低速增长的时期，这种浪费现象是企业的损失，更是对社会的犯罪。消除浪费必须成为一个企业的首要目标。

大野耐一谈到了妨碍生产流程的各种浪费和障碍。要让Scrum真正迅速发挥作用，高级管理层中必须有人深切意识到障碍造成的浪费是近乎犯罪的行为。在本书中，我稍后将告诉你如何消除浪费，在这里，我只要说一句话就足够了，即消除浪费会产生戏剧性的效果。但人们通常不会这么做，因为这需要诚实地面对自己与他人。

约翰逊知道这是他的工作职责所在。

“哨兵”团队花了大约三个月的时间才确定下来真正需要花费多长时间。为什么呢？这可以归因于我们之前谈到的“检查与调整”循环。Scrum之所以能发挥作用，就是先确定了各项任务的优先顺序，然后必须在规定期限内完成。在联邦调查局的案例中，他们以每两周为一个周期。他们明白，Scrum是一种迭代式增量软件开发过程。所谓迭代，是指把一个复杂且开发周期很长的开发任务分解为很多短期可完成的任务，这样的一个周期就是一次迭代的过程；同时，每一次迭代都可以生产或开发出一款可以交付的产品。这样可以展示给那些关心研发成果的人，当然，如果能够将阶段性成果展示给产品的利益相关者或终端用户，则肯定是最为理想的。

这种方法允许研发团队近乎实时地收到反馈。他们可以根据在上一个循环中的发现来判断自己的前进方向是否正确，以及判断他们下一步打算做的事情是不是恰当的。

在Scrum中，我们把这些循环称为“冲刺”。在每次冲刺之初，都会举行一次会议，产品负责人讲解需求，并由开发团队规划冲刺内容，即在未来两周内能完成多少工作。

在每一次冲刺结束之前，研发团队成员还要聚在一起开个评估会，给产品负责人演示他们在这个合作阶段之内取得的成果，并接受评估意见。他们会评估一下列表上的工作任务已经完成了多少，自己是在这个阶段的冲刺中认领了太多任务，以至于没有做完，还是工作任务认领得太少了。这样做的重要性在于大家对于自己完成任务的速度有了基本的认识。

他们在展示现阶段的冲刺成果时，不只讨论过去做了什么，还会思考下列问题：如何在接下来的冲刺阶段更好地合作？上阶段出现了什么障碍？哪些障碍拖累了工作速度？关于Scrum的运作过程，你可以在附录中找到更多的细节。

这就是为什么约翰逊要花费几个月的时间才能真正确定下来项目需要多久才能完成。他希望通过多次冲刺来评估各个团队的工作效率和进度，看看能做出多少改善。他知道各团队在每个冲刺阶段完成的任务量之后，再对比项目结束前需要完成的任务量，就能评估出交付日期。

除了明确团队的速度以外，他还想知道哪些障碍拖累了进度。他之所以这样做，就是想找到一种更好、更聪明的工作方式，而不是靠延长工作时间，帮助团队提升工作效率和进度。（我稍后会讨论为什么延长工作时间的做法是徒劳无益的，最后只会拖累进度。）约翰逊表示，他的团队的工作效率提高到了原来的3倍，因为团队成员能够更好地合作了。最重要的是，他们已经明白了哪些障碍会拖累工作进度，而且会在每一个循环，也就是每一个冲刺中努力地消除这些因素。

最终，“哨兵”项目组用了18个月的时间写代码，才完成了数据库系统的部署，又用了两个月才为整个联邦调查局安装完毕。约翰逊坐下来接受采访时说道：“时间压力太大了。你必须明白，这个系统要用来做所有事情，包括给线人付款、储存证据、储存文档、储存日程表等。所有这些都要纳入‘哨兵’系统中。”

根据他的观点，Scrum最强大之处是什么呢？他认为，答案就是“展示，即定期展示成果”。每两周，“哨兵”项目团队都会展示他们的成果，并不只是在他们内部展示，而是把成果交给使用者去实际操作。每一个利益相关者都会派人参加成果展示，以至于满满一屋子都是人，包括档案、情报、特工、总检察长办公室等部门的人。其他政府机构也会派代表参加。通常，联邦调查局的局长和副局长也到场，甚至当时那位代理检察长本人也亲自到场。这群人可是不容易对付的！

这就是让Scrum发挥作用的秘诀。约翰逊说：“Scrum关注的内容不是开发者，而是客户和利益相关者。其实，这是一个组织性的变革。展示真实产品是Scrum最强大的地方。”

事实上，展示成果的影响真的非常大，因为平心而论，人们对于他们报告的进度有所怀疑，他们无法相信“哨兵”项目的进展速度会越来越快。约翰逊说：“我告诉国会，我们只要5%的预算和20个月的时间就能完成洛克希德·马丁公司用90%的预算和10年都完不成的任务。房间里充满不信任感。”我们还必须向副总检察长提交报告。我们努力提高项目的透明度，但那些观众仍然觉得我们有什么见不得光的地方。类似这样的迹象，他们过去看得多了，毕竟我们当时的报告不是那么详细，而且我们的确做了很多他们不知道的事情。

这种怀疑气氛感染了联邦调查局的其他人，以至于大家都心想：“地下室那帮人这次又搞砸了。”他们觉得这只是一个暂时的系统，以后肯定会失败，导致他们不得不回到用纸办公的年代。

约翰逊当年在马里兰州首府安纳波利斯市的一所海军学校学习时，必须背诵泰迪·罗斯福1910年在巴黎索邦大学发表的一篇题为“一个共和国的公民”（Citizenship in a Republic）的演说词。约翰逊为他的团队讲述了其中一段。这一段经常被人引用，你可能已经非常熟悉了：

重要的从不是那些在一旁指手画脚的人，不是那些对别人的失败品头论足的人，更不是那些指责别人如何可以做得更好的人。荣耀属于那些真正站在竞技场里打拼的人：他们满面灰尘，浸透着汗渍和血迹；他们英勇无畏；他们一遍又一遍地犯错跌倒，因为这路上一定伴随着打击，即便如此他们依然奋力向前；他们理解何为执着和专注；他们献身于崇高的事业；在最好的情况下，他们最终品尝了伟大的胜利和成就；在最坏的情况下，即使他们失败了，至少他们也是伟大地倒下，因为那些自始至终从不知道胜利或者失败的、冷漠和胆怯的灵魂远远不能与他们相提并论。

约翰逊的团队精确评估了开发小组的进度和项目难度。最后，交付时间的确有些延误。到2012年7月，他们终于研发出了“哨兵”系统。之后，他们必须立即教每个人使用这套系统。约翰逊说：“洛杉矶某个刑事案件或反恐案件可能与芝加哥的某个案件具有一定的相关性，这种事情正在日复一日地上演着。我们绝不能失去先机。在任何时候，我们都要清楚准确地了解整体状况。”

但整体状况还要清楚准确到能够经得住法庭考验的程度。“哨兵”系统中的资料会被用来作为起诉别人的证据，它的完善性不能存在一丝一毫令人质疑的地方。

系统上线的第一天，约翰逊心情紧张，焦躁不安。他走进办公室，打开“哨兵”系统。系统自动加载，这是好事。然后，他试图用电子签名核准一份文件，这是联邦调查局数万名职员每天都要做的一个基本工作。突然，屏幕上显示了出错的提示。系统运行不下去了。约翰逊记得，当时他开始恐慌，各种灾难性的画面瞬间涌进了他的脑海。接下来，他认真看了一眼屏幕上的错误代码，才发现究竟是怎么回事。原来，他没有把自己的身份证件插入机器里验证身份。他把卡插进去，点击鼠标，“哨兵”系统就开始顺利运行了。

“哨兵”系统为联邦调查局带来的影响是巨大的。情报沟通与分享能力的提升给联邦调查局的工作能力带来了彻底的改观。2013年1月，一家小公司的账号遭到黑客攻击。美国银行还没来得及采取拦截措施，上百万美元的资金就被转到其他国家了。联邦调查局介入调查。借助“哨兵”系统，联邦调查局与对方国家驻美使馆的法律专员取得联系，后者通知其国内的执法部门，然后执法部门在资金汇入黑客账户之前就拦截了下来。所有这一切只用了几个小时。在过去那种一份文件打印三份，还要用到红笔的日子里，根本做不到这些。这两种工作方式直接关系到是将坏人绳之以法，还是让坏人逃之夭夭。

“哨兵”项目开发小组目前仍然待在联邦调查局的地下室里。办公桌上的隔板都移除了，以便大家能够相互看见对方。墙上贴的一张海报大小的文件上列出了我参与拟订并致力于向全球推广的“敏捷原则”。令人惊讶的是，虽然地下室没有窗户，但你一进门就会看到一盆薰衣草在日光灯下茁壮成长。

在Scrum领域，有一个老笑话。一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行，”猪说，“我把自己全搭进去了，而你只是参与而已。”这则故事应用在敏捷开发上，用来说明不同角色的职责。在Scrum过程中，“猪”在Scrum过程中全身投入项目，对结果负责。“鸡”需要了解项目进程，是利益相关方。在“哨兵”项目开发小组的办公室墙上挂着一个形状如猪的铃，每当它响起，这些实际参与研发过程的“猪”就知道有人在召唤自己了。另一个铃是门铃，但那是为“鸡”准备的。

我们的世界日趋复杂，相应的，我们工作的复杂性也越来越强。以汽车为例。30年前，我自己都可以制造出汽车里用的水箱。现在，我打开引擎盖，跟打开电脑看里面的零部件一样，基本上什么也看不懂。如今，制造一辆福特汽车所需的代码，可能比脸谱网和推特所需的代码总和都要多。要创造一个如此复杂的东西，需要人类付出极大的努力。对于任何一项具有复杂性和创新性的活动而言，无论是把火箭送入太空，还是制造更好的电灯开关，或是抓捕一名犯罪分子，传统的管理方法都已经失效了。

我们都知道这一点，个人知道，整个社会也知道。漫画《呆伯特》（Dilbert）或电影《上班一条虫》（Office Spac）等虚构类职场作品都能够引起我们情感上的共鸣。我们回到家之后，可能会跟伴侣说起现代公司的疯狂。我们也听别人说过填对进度跟踪表格比做工作更重要，或者需要为了某个会议而提前开一个筹备会。这是疯狂的、错误的做法。但我们却一而再、再而三地这样做，即便面对绝对的、彻底的失败，也照做不误。

美国医改网站Healthcare.gov就是一个例子。该网站旨在帮助美国人申请医保，但自开通之后，该网站一直备受各种问题的困扰，比如性能问题、数据问题等。它的前端做得非常美观，一切都是那么精巧和清晰，这是利用Scrum在三个月的时间里做出来的。但它的后端却是彻头彻尾的败笔，根本无法正常运行。它原本应该将美国国税局的数据库与各州数据库、保险公司数据库和美国卫生与人力资源服务部的数据库连接起来。这是一件非常复杂的工作，开发工作交给了20多个分布在各个领域的承包商，但这些承包商的设计人员普遍采用瀑布法进行设计。他们只是在研发工作接近尾声之际做了几天的非增量式测试，而非增量式测试。

具有悲剧色彩的一点是，每个人其实都明白这种测试方法不好，也都知道如何做得更好，那些为承包商效力的人也不可能蠢到这种地步。但问题在于，每个人都说这不是自己的职责所在，所以自己的任务完成之后就不再过问其他环节了。他们只是从自己的角度去审视网站，而从来不从用户的角度去看问题。造成这种现象的原因是他们没有密切合作，没有团结一致地去实现一个共同的目标。作为一个鲜明的对照，Scrum所做的事情就是把不同的团队凝聚在一起共创伟业，这需要每个人不仅看到最终目标，还要渐进式地提交自己的成果，逐渐向着目标迈进。在美国医改网Healthcare.gov这个网站的设计过程中，谁都没有坚持要求每项功能在完成设计后接受测试。类似于这个网站的失败案例十分常见。这是非常遗憾的。

一些大项目耗费上亿美元之后却以失败而告终，不仅实际花费超出预算，而且产品根本无法使用。你听说过多少这类项目？每年有多少亿美元花出去却得不到什么成果？你把多少光阴浪费在了你和上司觉得没有价值的工作上？你的做法可能就像在地上挖几下又把土填回去那样徒劳无功。

事情可以不必这么做，真的不必。即便每个人都对你说全世界都是这样做的，也不一定意味着这种方法就是正确的。肯定有一种不同的做事方法，一种不同的工作方法。

如果你不追求创新，你的工作就会被外包出去，或者你的公司就会倒闭。21世纪的职场竞争是超级激烈的，根本容不得浪费和愚蠢之举。

另外一个重要的问题是：Scrum这种效率最大化的方式不应该仅仅局限于商业领域。难道我们不能用这个方法去应对人类正在面临的石油依存度高、教育质量低、犯罪猖獗以及部分贫困地区缺乏清洁用水等问题吗？难道不能用它来寻找更好的工作方式、生活方式和解决问题之道吗？答案是肯定的。一些人正在利用Scrum解决我提到的这些问题，而且他们产生的影响越来越大。

在本书里，你将了解到一些人赖以实现最佳工作效率的根本途径，将了解到为什么我们非常不擅长做评估，以及为什么超时工作反而会拖累项目进度。我将带你了解一些科学家和一些组织在很多年里做出的研究成果和应用程序，教你如何用Scrum方法统筹一切，让你做到今天学，明天就能派上用场。

我会告诉你怎么做，但首先，我想先告诉你我是如何在这方面取得成功的。