从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)上，一篇名为

从Scrum之父探源敏捷方法论相关推荐

敏捷方法论—scrum
敏捷方法论-scrum 敏捷方法scrum,相对于传统的瀑布式开发,的核心观念除了增量和迭代两个核心词外,核心的观念差异基本就是敏捷宣言的理念: 1.通过迭代式增量应对产品需求变化和开发技术变化. 2 ...
敏捷管理（4）- 常见的敏捷问题、其他敏捷方法论
常见的问题敏捷是如何解决的? 敏捷痛点及解决方式问题解决方式团队目标或任务不明确敏捷章程愿景.使命和使命测试团队工作协议不明确敏捷章程价值观.原则.工作协议团队环境不明确敏捷章程边界. ...
敏捷方法论的前世今生- 敏捷历史，敏捷宣言与敏捷12条原则
敏捷方法论的前世今生敏捷方法的历史: 敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会. 迭代和增量开发方法最早可以追溯到二十世纪三十年代 ...
什么是敏捷方法论？What is Agile Methodologies?
我们经常被问到这个问题:什么是敏捷方法论 (Methodologies)?很简单,敏捷是IT行业用来描述项目管理的替代方法的炒作词. 敏捷是一个过程,可以帮助团队快速,不可预测地响应他们在项目中收到的 ...
敏捷软件开发方法论_什么是敏捷方法论？现代软件开发讲解
敏捷软件开发方法论如今,每个技术组织似乎都在为软件开发或它的一种版本实践敏捷方法. 或者至少他们相信他们这样做. 无论您是敏捷应用程序开发的新手还是几十年前使用瀑布式软件开发方法学过的软件开发,如今 ...
敏捷方法论：理解敏捷测试的完整指南
在过去几年中,一种创建软件的新方式已经风靡软件开发和测试世界:敏捷. 事实上,根据VersionOne的敏捷状态报告,截至2018年,97%的组织以某种形式实践敏捷. 然而,受访者表示,这种采用在其组 ...
敏捷方法论_敏捷方法论完整指南
敏捷方法论故事点和复杂点 (Story Points and Complexity Points) In Scrum/Agile, the functionality of a product in ...
我不信奉Scrum，我信奉敏捷
Scrum一直以来争论不断.虽然创始人Ken在演讲中曾说过即使是白痴也可以用Scrum,但是依然有很多人认为Scrum对团队成员的素质要求非常高.另据统计,75%以上的Scrum都可以称得上失败. 去 ...
将炙手可热的敏捷方法论应用到市场营销团队当中
如果你进入市场营销这个行业有一段时间的话,你应该对敏捷市场营销这个概念并不陌生. 每个人都在说敏捷营销将会是"市场营销的下一件大事".它甚至有着自己的敏捷宣言.尽管已经传的沸沸扬扬 ...
Scrum Alliance国际Scrum中文认证和敏捷教练职业发展体系
Transform your world of work 改变你的工作方式欢迎来到Scrum联盟® 交流和学习Scrum 无论你是Scrum新手,或是已经实践了Scrum多年,成为Scrum联盟会员 ...

从Scrum之父探源敏捷方法论

从Scrum之父探源敏捷方法论相关推荐

最新文章

热门文章