查看原文
其他

汇编:敏捷历史及十年反思

2017-08-03 Glen Wang 真北敏捷

本文汇编了三个内容:


一、敏捷历史 by Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi @APRIL 20, 2016

二、敏捷十年反思 by James Coplien, Mike Cohn, Stephen J. Mellor, 等 @2011

三、敏捷历史图谱 by Yasunobu Kawaguchi @2013


以下具体内容:


一、敏捷历史 by Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi @APRIL 20, 2016


Darrell K. Rigby是Bain公司的波士顿办公室合伙人。他领导公司的全球创新和零售业务。 他是《在动荡中取胜》一书的作者。


Jeff Sutherland是敏捷开发的scrum方式的联合创始人, Scrum之父,他也是Scrum 公司的CEO, 该公司是咨询和培训公司。


Hirotaka Takeuchi竹内弘高哈佛商学院战略分院的教授,Scrum的祖父。




敏捷的前身,戴明环与丰田:


敏捷方式可以追溯到1620年Francis Bacon科学方法的发源时期。更合理一点的起点可能是在20世纪30年代,那时候贝尔实验室的物理学家和统计学家 Walter Shewhart开始使用计划-执行-研究-检查(PDSA)循环对产品和过程进行改善。Shewhart把这种反复渐进的开发过程教给了他的学员戴明(W.Edwards Deming), 后者在二次大战后的日本大量使用了该方法。丰田公司雇用了戴明来培训公司中数百名经理。最后在他的经验之上创立了著名的丰田生产体系——这也是如今”精益“思想的最初由来。这种反复渐进的方式对于20世纪50年代的X-15 超音速飞机的制造也是贡献巨大。



Scrum的祖父野中郁次郎和竹内弘高的工作,接力赛vs整体式:


在1986年,我们中的一员(Takeuchi竹内弘高)和共同作者 Ikujiro Nanaka野中郁次郎在哈佛商业评论上发表了名为《新的新产品开发游戏》的文章。通过研究那些比竞争者更快发布新产品的制造商们,比如富士-施乐的复印机,本田的摩托车引擎,佳能的照相机,作者定义了以团队为基础的新的产品设计和研发过程。这种过程不是通常在产品开发中的“接力赛”——一组专家完成产品部分功能并将项目传递到下一组专家手中。 这种方式被Takeuchi和Nonaka称作为“橄榄球”方式,“团队试图作为一个整体完成所有任务,将球传来传去。”



Scrum之父Jeff Sutherland的工作,方法与团队熔于一炉:


在1993年,我们中的另一员(Sutherland)面临一项似乎是不可能完成的挑战:Easel是一家软件公司,需要在半年之内开发一款新产品来替代它的传统产品。Sutherland通晓很多方法,比如快速应用程序研发,面向对象设计,PDSA循环,专案工作等等。他希望在公司总部建立一个类似于专案工作的文化氛围,将组织分割和合并的好处结合起来。他开始学习任何和提高组织效率相关的知识。通过阅读上百篇研究报告和顶尖的产品管理专家面谈,他脑海中逐渐有了一些有煽动力的想法。



Scrum与贝尔实验室和两位日本教授,使命必达的方法:


这中间有一个想法来自于贝尔实验室的关于Borland Quattro Pro团队的文章(http://1pn8a8ult4o2bls5f2jxuel1.wpengine.netdna-cdn.com/wp- content/uploads/2013/07/borland-process.pdf)。该文章主张,每天短的团队会议能显著增加团队效率。而Sutherland的核心概念则来自于Takeuchi和Nonaka的“橄榄球”方式, 虽然该方法更关注制造过程而不是软件开发过程。通过借鉴HBR文章中的关键想法和进行一些特别的试验,Sutherland创建了一种新的软件开发方法;归功于橄榄球带来的灵感,Sutherland将这种方法称为“争球”(Scrum)。Scrum方式最后确保了他准时完成了似乎不可能的任务,也没有超出预算,程序漏洞比之前版本还要少很多。Sutherland随后就长时间和同事Ken Schwaber对该方法进行长期研究,并在1995年两人首次在公众面前发布scrum的方法。



敏捷宣言的起草人,17位新方法论的先驱:


在2001年,17位自称“有组织的无政府主义者”在Utah的Snowbird会面,分享他们的想法。Sutherland 和其它scrum的先驱也在其中。参与者们分享了互相竞争的几种方式:极限编程(XP);透明化;自适应软件开发(ASD);特征驱动开发(FDD);动态系统开发方法(DSDM)。所有这些方式都是“轻量版”的框架,因为这些方法使用更少,更简单的规则来适应快速变化的环境。 不少与会者都觉得“轻量”这个术语挺适用的。



敏捷宣言,4价值观,12原则:


虽然与会者不能在方法上达成一致,但是他们还是为这个运动取了个名字:敏捷。这个词是一位参与者提出的,他当时正在读《敏捷竞争者和虚拟组织:给客户更多的策略》一书(http://www.amazon.com/Agile-Competitors-Virtual- Organizations-Strategies/dp/0471286508)。书中列举了100家公司的例子——包括ABB, 联邦快递,波音,博士和哈雷戴维森,这些公司正在创建适应动荡市场的新方法。有了这个名字,参与者达成一致,发布了“敏捷软件开发宣言”,该宣言中突出了每个人都同意的4个关键价值。稍后在会议中,以及之后的几个月中,他们发展了12个操作原则,被称为“敏捷宣言背后原则”。 从2011年开始,所有的开发框架,以及与之匹配的价值观和原则就被称作为敏捷技术。



精益与敏捷,父子?兄弟?相得益彰:


同时,敏捷方法继续演化。在20世纪80年代后期和90年代前期,MIT的研究学者们开始研究日本的制造体系,特别是丰田生产体系。他们借用了名词“精益”来描述改善效率的这套体系,包括消除浪费(muda), 减少波动(mura)和降低负荷(muri)。虽然精益方法并没有在Snowbird会议上被表述成敏捷方法,但是精益和看板软件开发系统在2000年被并入敏捷系统。在开始时候,一些纯粹的敏捷主义者拒绝承认精益方法。 但是精益宣传该方法能关注客户协作,最终更多的敏捷践行者开始接受精益,看板,还有混合产品(比如scrumban和lean scrum), 作为敏捷价值和原则合法的应用。



二、敏捷十年反思 by James Coplien, Mike Cohn, Stephen J. Mellor, 等 @2011



十年发展,彰显成效:


自从编程界的领袖们发表旨在通过接受需求变更,加强同用户合作,缩短软件提交周期来改善软件开发过程的敏捷软件开发宣言至今已近10年之久了。

敏捷宣言制定2001年2月,当时一群软件开发者聚集在犹他州,他们希望能找到一种可以替代那些由文档驱动的、“重型”的软件开发模式(如当时的被当作金牌标准的瀑布模型方法)的新方法。

尽管早在犹他州会议之前,敏捷开发方法就已经出现,但这次会议却被当作这种方法论推广进程中的一次分水岭事件。十年以来,敏捷开发已被众所周知,很多软件公司采纳了Scrum和XP(极限编程)等敏捷开发实施方案。尽管还存在着不可预知的问题,敏捷方法领域里的专家都认为,总的来说,敏捷方法的实施会给软件开发活动带来益处。


模式大师James Coplien:


也许敏捷宣言的关键价值不在于它的洞察力、独创性,当然也不是它的预见性,而是它与编程平民主义间的联系。敏捷成了应用广泛的主要工具和主流变化。它用库恩式的范式转变击溃了不时出现的缺乏想象力的、不合理的抵制。从这个意义上说,它确实是个宣言。它是一个危险的文件。敏捷宣言的每一条都是一分为二的,提炼一下那四条宣言,它们只涉及两个原则:自组织及支持自组织的反馈。自组织确实与二十世纪六十年代流行的商业文化产生了摩擦。



敏捷影响力第一人Mike Cohn:


在宣言出现前几年,我正在为一个大型企业集团某个分部的软件开发组主持Scrum开发。当时所有分部与开发相关的VP聚在一起,讨论在所有的分部中共同采纳一种通用的开发流程,我无法说服其他VP认真考虑Scrum。尽管我所在的分部取得的成果最为显著,而且我们将之归功于我们在数十个项目中使用的Scrum方法,我还是无法让其他人产生即使是尝试Scrum的想法。



OO方法学大师Stephen J. Mellor:





三、敏捷历史图谱 by Yasunobu Kawaguchi @2013


Yasunobu Kawaguchi is an Software Engineer focused on Usability and Agile Software Development Process. He has over 15 years experience in development of various information editing and display applications. He 's also acting in-house consultant role about agile software production and agile computer infrastructure.







阅读原文,补充修订扩展备用页。



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存