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。反过来,我们在技术实践中的不断学习和探索,也丰富着我们对生活的感悟。

posted @ 2011-04-21 13:09  wanghui  阅读(2512)  评论(9编辑  收藏  举报