从Scrum之父探源敏捷方法论

 

 「Jeff Sutherland」Scrum之父，敏捷宣言（Agile Manifesto）起草人。萨瑟兰毕业于西点军校，越战期间是出色的战斗机飞行员，擅长低空飞越北越进行侦察任务。越战归来后，先在史丹佛大学取得统计硕士学位，后于科罗拉多大学医学院取得生物统计学博士学位，其指导教授John Bailar是医学暨统计学最知名的研究学者之一。现在为Scrum基金会总裁。他在空军训练中学到：观察（Observe）、导向（Orient）、决定（Decide）、行动（Act）的循环方法。

        Scrum是目前全球最为广泛采用的敏捷工作法(1,500万人正在天天使用中)，Amazon有3,300个Scrum开发团队，Intel则有500个Scrum teams，Tesla、Apple、BOSCH、J.P. Morgan、及日本的TRI-AD/Toyota、Docomo、KDDI ......

       911事件发生后，事件调查委员会试图找出事情发生的关键原因。该委员会指出，负责分析情报的人员未能取得一些原本应该要分析的情报。 「FBI的资讯系统效能不彰，」报告中写道，「这意谓着情报分析人员多半得仰赖与工作部门或工作小组成员间的私交， 才能从存放情报的单位取得情报。」 这是该委员会的结论:「FBI缺乏知道自己欠缺什么的能力:内部缺少一个能吸收或分享组织知识的有效机制。」 

        FBI「自动化案件支援」(Automated Case Support)系统架设于 1980年代曾经走在时代尖端的大型主机上。但是，很多干员根本不用这套系统，因为它实在太笨重又太迟缓。

     「你得在文书处理软体中打好内容，然后列印出三份。第一份是 要请上级层层核可的;第二份是要存放起来，以防第一份遗失的;第三份你得拿一枝红笔──我没开玩笑，真的是红笔，圈出关键字，输入 资料库中，因为你得为自己的报告做索引。」 这样的情景在官僚化系统里最为常见。

       这种管理方式实在太过时又松散，一度备受诟病:FBI明明早在九一一事件前几个星期就已得知，有多名激进组织的份子进入美国，却未能把种种迹象的关联性加以串连，有人认为部分的原因就出在档案系统上。当时FBI的某单位对某个目标起疑，另一个单位对于有这么多可疑的外国人在接受飞行训练感到事有蹊跷，还有一个单位则是把某盖达成员列入监视名单，却从未通知其他单位。在FBI 内部，没有人把这些事情全部拼凑在一起。

       当参议员们开始质询FBI一些难堪的问题时，FBI基本上都会回 答:「别担心，我们已经有一个正在进行中的现代化计划了。」该计划要发展的是一套名为「虚拟案件档案」(Virtual Case File, VCF) 的系统，照理说这应该可以让一切改观。FBI的官员很懂得利用每一 次面临的危机，他们向参议院表示，该计划除了原本已拨款的1亿美元经费以外，只需要再追加7,000万美元经费就够了。假如你回头去找当时媒体对VCF系统的报导，你会发现内文大量使用诸如「革命性 的」与「转型」之类的字眼。三年后，计划终止了，因为根本不管用，连一丝一毫的效果都没有。FBI已经花费纳税人1.7亿美元的辛苦钱，买到的却是一个永远不会有人使用的电脑系统──没有任何一行程式码、应用程式派得上用场，也不会有任何的滑鼠点击。整个计划根本是一场灾难。

       2005年，FBI展开名为「哨兵」(Sentinel)的新计划。这次一定要管用，这次一定要用对预防措施，一定要跑对预算流程，一定要做好控管。毕竟FBI已经得到教训。哨兵计划造价多少?只要4.51亿美元，而且2009年就能全面上线。 受雇建置哨兵系统的承包商Lockheed Martin已经用掉4.05亿美元的经费，却只完成一半的工作，而且这时候的进度还落后了一年。一项独立分析预估，这个专案可能还要六年到八年才能完成，而且纳税人为此至少必须再花3.5亿美元。FBI花费近十年的时间试图更新局里的电脑系统，但是专案看起来即将「再次」失败，成为史上最大的软体灾难。

      原因不在于这些人不够聪明，也不在于FBI所托非人，甚至不是选错技术的问题。问题无关乎职业道德，或是缺乏外来的竞争刺激。原因在于大家工作的方式不对，大多数人都用错了工作方法。我们都以为工作应该要那样完成，只因为别人教我们的就是那一套。

       Lockheed Martin的成员在投标前先开会检视系统需求（有1,100项需求，堆起来大概几吋厚），而后开始着手规划如何打造出一个满足所有需求的系统。他们会交由公司内部的大量人才处理，花费几个月的时间整理出必须完成的事项。接着，再花几个月的时间 规划如何完成。他们会划出许多美观的图表、解说每件必须完成的工 作，以及每件工作所需的时间。然后会小心挑选颜色，把计划的每一个部分以层层相接的形式呈现出来，看起来就像一道倾泻而下的瀑布。

        大多数的软体开发专案都还是采用瀑布法，专案分成多个阶段完成，一个又一个阶段发展出准备释出 给顾客或软体使用者的终极版。流程很缓慢，也无法预知成果，而且往往会做出使用者并不想要或不愿付费购买的产品。进度延迟几个月或几年是家常便饭。这种事前先把每一步都规划好的计划， 会把所有细节都画成甘特图，也让管理高层相信开发的过程完全在掌控中，但结果往往是进度很快就开始落后，而且预算严重超支。

        这类图表叫做甘特图(Gantt chart)，因为它是由亨利.甘特 (Henry Gantt)所发明的。1980年代，个人电脑的问世让大家能很容易就画出这种复杂的图表，但是也让图表变得极其复杂，甘特图于是成为一种艺术品。专案中的每一个阶段都巨细靡遗地设定好了，包括每一个里程碑、每一个交日期在内。这些图表看了真的会让人留 下深刻的印象，但唯一的问题却在于它们往往是错的。

       甘特大约在1910年发明这种知名图表，最早使用甘特图的是第一次世界大战时担任陆军军械部部长的William Crozier将军。任何研究过第一次世界大战的人都知道，有效的组织能力在那次大战中实在称不上是什么突出的特质。我一直都很纳闷， 为什么甘特图这种一次世界大战时的玩意儿会变成21世纪专案管理中的既定标准工具。我们现在已经不再打壕沟战，但是当年用于规划壕沟战的思维到现在却依然流行。艾森豪威尔曾说过，为战争拟定计划固然重要，但是等到开了第一枪后，计划就化为乌有了。他很有见地的没有使用甘特图。

       传统上，管理团队对于任何专案都会要求两个条件:控制和可预测性。这会带来为数众多的文件与图表，就像Lockheed Martin一样，会花好几个月的时间规划所有细节，以确保没有任何错误，没有任何成本超支，而每件事也都能按照时程完成。

       问题在于，这样美好情节从未真正发生。所有用于规划的心力、用于限制变化与厘清未知事项的努力全部都是白费。每个专案一定都会出现许多的问题，冒出许多新想法。试图把任何规模的人类行为限制在全彩图表里，不但愚蠢，而且注定会一败涂地。人不是这样做事的，专案不是这样进展的，想法也不是这样落实的，美好的成果更不是这样创造的。

        Scrum的固定仪式之一是询问大家很简单的三个问题:从我们上次交谈后到现在，你做了什么?在我们下次再讨论之前，你打算做什么?有什么事情干扰你吗?这可以促使 特派员们彼此讨论并分享资讯。在每次开会后，Scrum Master要负责确保任何干扰团队工作的因素在下一次开会前已经被排除，否则流程就无法“流动”。

      大野耐一提出的关键概念「流程」，意思是生产流程应该流畅平顺;管理团队的重要任务之一在于找出流程中的阻碍，并且予以排除。任何挡在路中央的东西都会造成浪费。他的经典著作《丰田生产方式:追求超脱规模的经营》(The Toyota Production System)中，评定「浪费」的道德价值及商业价值:在低成长时期，这样的浪费不但是商业损失，更是社会犯罪。排除浪费必须是企业的首要目标。想要让Scrum真正发挥功能，高阶管理团队中必须有人发自内心地把阻碍视为近乎罪犯。大野耐一谈到三种不同的浪费，他用的是日文字眼:Muri、 Mura、Muda。Muri指的是因为不合理、不恰当导致浪费;Mura指的 是因为缺乏一致性导致浪费;Muda指的是成果欠佳导致浪费。这些想法与PDCA循环高度契合，也就是规划、执 行、检核、行动。规划意谓着要避免Muri，执行意谓着要避免Mura， 检核意谓着要避免Muda，而行动意谓着我们要有意志、动机及决心把这些事做好。节奏是Scrum的核心，运作得宜的Scrum团队可望实现我们所称的「超生产力」。

      美国太空总署采用的「阶段-关卡」流程就是经典案例。美国太空总署在1960年代、1970年代及1980年代就是使用这套流程执行太空梭等计划。现在的流程已经大不相同了，这里讲述的是他们那套旧流程的运作方法。首先，从探索「阶段」着手，大家决定要设法完成的目标，比如说打造一艘登月火箭。一群策略人员坐在房里，想像着那幅场景。接着会有一个「关卡」，由一位或一群管理者签名，认可该专案有发展的价值。再来进入初步调查阶段，所有的「需求人员」 必须决定该做哪些事。接着会有另一个关卡，又要开好几次的会，产出的所有庞大文件要转交到下一个阶段──细步调查阶段，并拟定专案计划。再来，所有的计画又必须历经一连串的会议与核可，完毕之后再送到下一个阶段──开发阶段，到这时才会真的开始动手生产。接着又是一堆会议与文件，然后把产品交到另一群人手中，进入下一个阶 段──测试。测试人员先前从未看过产品，但他们还是照测不误，然后签名核可，再把产品放到另一个关卡前，也就是永无止尽的开会，这时会再产出一批根本没有人会阅读的文件。直到这里，产品总算要送到第六批人员的手中，由这些人实际推动上市。光是把这些过程写出来就累死人了，但这却是美国太空总署过去发展计划的过程。物理学家Richard Feynman:「无论是出于内部或外部所需的任何理由，看来美国太空总署的管理当局夸大产品的可靠度已经到了幻想的地步。」只要资料在不同团队间移交，就有发生灾难的可能。正如刊载在《美国联合部队季刊》(Joint Force Quarterly)上，一篇名为􏰀情报监侦之运用:特种部队最佳实务􏰀(Employing ISR: SOF Best Practices)的文章中所写的:跨部门团队在伊拉克让不同盟军团队之间更加合作无间，可以 「目不转睛地」紧盯重要目标......假如不同单位或组织间还得交接任务，恐怕将创造出「三不管地带」，不但会让行动的动能减缓，目标还可能趁机逃走。

      人类非常不善于预估事情，但是幸好我们倒是很擅长设定相对规模，也就是比较两件事之间的相对大小，像是在 一堆T恤中挑出S尺寸、M尺寸、L尺寸。这就是设定相对规模，只比较任务的大小。这些数字有种规则:1、3、5、8、13。8是前两个数字的总和，13也是前两个数字的总和，这种数列称为「费氏数列」(Fibonacci sequence)。研究显示，即便花费好几个月规划，预测值与实际值之间还是可能有上下四倍的落差。所以，我才会认为做事时若采用瀑布法规划真的是蠢得可以。

     「敏捷」一词要回溯到2001年的一场秘密会议，当时Jeff Sutherland和另外十六位软体开发的领导人物共同拟定后来大家所知道的「敏捷软体开发宣言」(Agile Manifesto)。宣言中明白指出以下几种价值: 人比流程重要;产品实际管用比在文件中列出产品应有规格重要;与顾客合作比和顾客谈判重要;因应变化比遵循计划重要。Scrum是一 个我用来落实这几项价值的