SCRUM之比喻
老子《道德经》云：“治大国，若烹小鲜。”用简单的贴近生活的例子做比喻，来论述复杂的事情和高深的道理，在古文中很常见。再如荀子《劝学》中满篇的比喻（估计读过中学语文的都能背上几句）：“青，取之于蓝，而胜于蓝；冰，水为之，而寒于水”，用来比喻人通过学习改造，可是胜过以前。SCRUM作为一种敏捷框架，也有很多比喻，这些比喻可以使我们更形象地理解其内涵与外延。
前一阵子正在拜读SCRUM联盟主席Mike Cohn的《SCRUM敏捷软件开发》（英文名：Succeeding with Agile: Software Development Using Scrum）一书。作者运用了很多形象的比喻，来解释SCRUM中的一些问题和概念。比如：
一. 火箭、重力
“我把Scrum比作火箭。火箭向前推进依靠的是它的发动机功率。但将其拉回来的是重力。如果火箭被推的足够远，它可以进入轨道。但如果它不能进入轨道，必定会被拉回到地面，回到起点。Scrum的影响必须推得足够远，使整个转型不会因为“企业重力”而被拉回起点。”
作者在论述企业进行敏捷转型和推广传递Scrum时用了以上比喻。开发团队只靠自己是不能够永久保持敏捷的。Scrum必须传递到其它部门，否则这些部门的“组织惯性”最终会使转型所作的努力化为灰烬。作者还专门辟了一章，讲述推进Scrum不能忽略开发团队之外的群体（包括人力资源、后勤和项目管理办公室PMO）的影响以及如何让其它部门能配合敏捷实践。笔者在前次参加Scrum中文网的敏捷沙龙活动中，演讲人李连华在演讲《Scrum实践中的困难、挑战与三级助力》中，也提到了这个比喻，他提到克服这个“企业重力”需要“三级助力”（就像火箭发射的三级助推），即敏捷意识、工程实践和实践社区。
二. 疼痛
对于任何变革，抵触都是不可避免的，Scrum转型也是如此。但对于“抵触”，企业的领导者应该采取什么样反应？是让“我们”战胜“他们”？还是分析原因，然后创造一种氛围，让大家感觉到转型势在必行？作者引用了一个比喻：
“社会组织中的抵触信号就像疼痛对身体的信号作用一样有用，疼痛表明某些身体机能失调。像疼痛一样，抵触并没有告诉我们什么出问题了，而仅仅只是觉得有一些不对劲。试图去克服这些抵触是没有意义的，这比不诊断病因而只吃止痛片更严重。”
所以，对策不应该是用绝对的权威完全忽略员工的情感和反应而把Scrum强势推给企业，也不能把抵触的员工视为要解决掉的问题。就像不能只用止痛药，而是应该对原因认真探究，对症下药。
三. 乐队指挥
Scrum创立者之一Ken Schwaber在1997年发明了单词ScrumMaster。为什么要发明这个新头衔？原因是提醒每个人，ScrumMaster不只是项目经理角色增加或减少某些附加的责任。那么ScrumMaster到底是个什么角色？Mike Cohn用了这样一个比喻：
“请把ScrumMaster想象成乐队指挥家。两者都必须实时引导一个团体，团体中的个人是为了某一创造性的目标走到一起，而这个目标是没有人能够单枪匹马实现的。波士顿流行音乐指挥家Keith Lockhart对其角色的评价：‘当你成为一名指挥家，人们就猜测你会是拿破仑式的人物——站在大箱子上行使权力。我不是权力迷，我是责任迷。’优秀的ScrumMaster以一种独一无二的方式成功地履行其责任——没有权力的、特殊的责任。”
乐队指挥，不像小提琴手、小号手等演奏员真正地去演奏乐曲，但他通过对乐曲的理解帮助乐团协调一致地完成演奏；ScrumMaster，不像团队成员真正地去产出软件，但他保护团队，迅速清除挡路石，保证团队一起顺利工作，使团队有效地朝着目标前进。类似的角色可能还有足球教练和电影导演。ScrumMaster懂得他的工作并不能给他带来公司配车或车库入口的好车位，他既不能对团队成员说：“你被解雇了”，也不能在遇到问题时说“让我来”。所以做好ScrumMaster本身就是一门艺术。
四. 体育团队
高效能Scrum团队，首要目标是接受团队责任制。只有PO对产品Backlog负责么？只有程序员才为整洁、优雅代码负责么？只有测试员才为质量负责么？不是。应该是整个团队要为产品的所有方面负责。这有点像体育团队。
“新赛季开始。我们会说团队中哪些成员要对夺取冠军负责？教练吗？老板吗？明星选手？……整个团队都在为通过某种方式赢得比赛而负责。如果团队输了，可能很容易责怪这个人或那个人，但团队知道他们中的每个人都要为失败负责。这个从来不是一个人的错。实际上，没有单独承担失败责任的人。”
Scrum软件研发团队，可能有Architect、UE Designer、Developer、Tester、DBA，还有Scrum Master和PO，这就像是足球队中的不同位置的人，他们的职责有所不同，但他们都在为比赛的输赢负责。进攻中，后卫可以进球，防守时，前锋可以是第一道防守线。
五. 三明治商店
在“依赖专家但需谨慎”一节，说到Scrum团队成员应该是“通才”还是“专才”时，Mike用了三明治商店的例子。Scrum专家们也经常会引用这个例子，来给Scrum新手讲解Scrum团队中通才和专才的关系。
“一个普遍的误解是Scrum团队的每个成员都必须是通才而不是专才。这是不对的。我对此感到吃惊的是世界上每个三明治商店都已知道如何对待专家，而在软件行业的我们还在为这个问题苦苦挣扎。……他们（指三明治商店）有三种类型的雇员：订餐员（order taker）、三明治厨师（sandwich maker）和流动工（floater）。订餐员在柜台上工作，写好每个三明治订单然后传递给后台的厨师。厨师在订餐员后面工作，接到订单后就准备三明治。订餐员和厨师是专家。流动工则是多面手——能干两种工作，不过可能没有专家那么好。……这对Scrum团队的启示是我们总要尝试拥有一些多面手。正是多面手让专家们显得更专业。”
常有人说，公司里有些代码只由一个人（专家）来写，只有他明白，一旦他离职，没人能接手。所以，尝试培养“流动工”，也许可以避免这种问题的发生。
六. 持续胎压侦测
“……我特别满意的一个改进是用来自动侦测轮胎胎压是否过低的感应器。有时候很难分辨清楚轮胎压力是否变低了，人工检测胎压这活儿显然很脏，所以我很少做。我认为持续检测轮胎压力是一个伟大的发明。在同一时期，汽车制造商发明了持续测试轮胎压力的新方法，而软件开发团队则认识到不断测试产品也是一个好主意。”
传统开发方法中，测试要等到开发完成并交付到测试环节才开始。即使是有些声称使用了Scrum的企业也在每个Sprint中使用微瀑布的开发方法（包括我原来的公司，也曾走入这样的误区），即：等一个功能完全开发完成后，再开始测试。其实，Scrum把测试作为一个主要的实践，并把测试作为开发过程的一部分，而不是作为开发工作“完成”后才发生的某些事情。不是等产品构建好了之后才尽力测试产品的质量，而是在流程中、产品制造过程中持续地构建质量。
书中还有许多比喻，比如：
“我把敏捷过程比喻为一个漩涡，随时间的推移，漩涡逐渐形成，吸引新的人和团体进来，作为它的基础。”
“所有人都知道你在做敏捷，所以你更容易坚持下去。……不管你是开始减肥、戒烟或启动一个锻炼计划，把这个计划告诉你的朋友总是一个不错的想法。你也许会感到有一种心照不宣的压力去获得成功，因为你已经宣布你的打算。”
“我不提倡这样做（轮流担任ScrumMaster）。……在家里，我们轮流擦桌子和洗碗，我们谁都可以做这份工作。但是，我们不轮流做饭。我妻子烹饪的本事远远强过家里其他人，我们希望吃到的饭菜时能做出来的最好的饭菜。”
“一个集体所有权的团队会写出更干净的代码，而且可能因此减少缺陷。没有人愿意在同事面前丢脸。……再考虑一下你给客人用的浴室。哪一个会保持得更干净？只有你自己会用的，还是客人可能看到的那个？”
“观看网球比赛时，你可能注意到选手接发球时注意力很集中，而不是毫无准备的站着。企业Scrum转型的领导者和变革推动者希望企业可以时刻准备好向左、向右或者任何方向行进。”
“产品Backlog呈现出冰山形状。在该产品Backlog冰山的顶部是团队在最近一个Sprint中能完整实现的那些小功能需求；当我们从该冰山进一步往下看（也就是更远的将来）时，Backlog条目会变得越来越大，一直到水平面为止。团队还不知道有什么藏在它下面，那些实际上是还没有进入讨论流程的需求。”
“美国作家E. L. Doctorow曾写过‘写小说就像在夜晚的迷雾中开车，你只能看到前灯灯光所及的地方，但是你能以这样方式完成你的旅途。’软件开发也是一样。我的前灯不能照亮在我和灯光不能到达地方之间的所有东西。前灯照亮的那些地方，足够让我在车安全行使时看到东西并做出反应。”
“详细说明书的一个不足是它们很少保持更新。在写一份文档前，问问自己是否愿意一直更新该文档。如果不是，要么慎重考虑编写文档的必要性，要么给这个文档规定一个失效日期，类似牛奶盒子上‘最好在……之前饮用’的提示。”
除了这本书之外，我还看到听到过很多关于Scrum的比喻。
前几天看姜志辉的视频《软件博弈》，他也用到不少比喻，比如：他从“杀人游戏”讲述迭代的必要性，他把往Sprint里放待办项比作往篮子里放鸡蛋，他把Scrum软件开发比作像“魔兽世界”这样的合作沟通的团队游戏。把Scrum比作游戏的还有李国彪（Bill Li），他把Scrum比作围棋（入门容易，成为高手谈何容易），把实施Scrum比作下一盘围棋（一开始布局留白，到中盘会碰到很多疑惑、挑战和困境）。Scrum培训师Jens Ostergaard用日本剑道中的“守-破-离”来比喻学习Scrum的3个阶段（或境界）。等等等等……
我们通过这些比喻，能更深刻的理解和领悟Scrum。反过来，我们在技术实践中的不断学习和探索，也丰富着我们对生活的感悟。
