引发全球软件革命的“敏捷宣言”是如何诞生的?
编者按:“敏捷”(Agile)这个对于开发真来说不在陌生的概念,已经提出了近17年了,其背后的哲学理念也慢慢进入到了各行各业。它背后有什么故事?与“瀑布模型”相比又有什么不同?又遇到了哪些问题?近日,《大西洋月刊》发表了一篇文章详细介绍了“敏捷”背后的故事,及其带来的影响。作者为CAROLINE MIMBS NYCE,文章由36氪编译。
image一、
犹他州(Utah)的雪鸟城(Snowbird)是一个不太可能发生软件革命的地方,它位于盐湖城外约25英里的地方,一点都不像硅谷:既不以阳光和温和的气候闻名,也不是什么科技创新中心,更没有那么多充满热情的企业家。但就在这里,一个滑雪胜地,一群具有反叛性的软件开发人员于2001年聚集在一起,制定并签署了行业历史上最重要的文件之一:关于编码集的独立宣言。这个为期三天的小型会议塑造出了许多关于软件的构想、开发和交付的方式,甚至是世界是如何运作的方式。
不管你是否承认它的名字,你可能已经或多或少使用过“敏捷”方法,或者是接触到过那些正在使用它的公司。来自Spotify和eBay的代表证实,这两家公司目前都在使用敏捷方法,而且在Twitter的网站上有一份招聘“敏捷教练”的工作。互联网上的“面包屑”足迹表明,许多其他知名的科技公司过去也曾尝试过这种做法。而且不仅仅是硅谷:据报道,沃尔玛早在几年前就开始尝试敏捷方法了。敏捷联盟是一个提倡使用敏捷方法的非营利组织,它的公司成员包括洛克希德马丁公司、埃克森美孚公司和威讯公司在内的各种巨头。
译注:敏捷方法也被称为轻量级方法,它是一组开发方法的统称。 随着技术的迅速发展和经济的全球化,软件开发出现了新的特点,即在需求和技术不断变化的情况下实现快节奏的软件开发,这就对生产率提出了很高的要求。
敏捷方法的追随者似乎无处不在,带着一整套工具和技巧让工作场所变得更有效率。从表面上看,它可能看起来像项目管理类型使用的另一种毫无意义的企业流行语。但它实际上是一种非常具体的哲学,在雪鸟城签署的一份68字的文件中对其进行了概述。
二、
在软件能够吞噬世界之前,人们需要从洪流中抽身出来。硅谷可能是世界上唯一一个“瀑布”(Waterfall)一词带有些许负面含义的地方。在编程中,“瀑布”被用来描述一种构建软件的方式——思考一个缓慢的、逐步的、分阶段的过程。在“瀑布”模型下,软件项目的设计非常严格,就像人们制造腕表的方式一样。
它的工作原理是这样的:有人会提出一个他们想要开发的软件。在写完一行代码之前,需求者/产品经理们会写出他们想要构建的内容,以及一系列冗长而详细的计划。他们制作所谓的“需求文档”,在上面列出他们想要软件做的所有事情。然后项目会流向下游,从一个阶段到下一个阶段,从一个团队到另一个团队,直到完成。最后,整个新软件都经过了测试,反馈给了客户,然后就交付出去了。
image“瀑布”模型示意图
许多人把这种模式的起源归功于Winston W. Royce 1970年的一篇论文,但有一个很大的问题:尽管在论文的第二页出现了一个类似“瀑布”的图表,但Winston W.Royce的论文实际上并不支持以这种方式构建软件。
当你确切地知道你想要构建什么东西时,线性方法可能会奏效,但对于一些项目来说,它可能会有太大的限制——正如麻省理工学院斯隆管理评论的杰出教授Michael A.Cusumano所言,软件开发是“真正的发明过程”。Cusumano说:“软件工程师或程序员喜欢在不同的步骤之间来回切换。它们并不是按照顺序来排的。”
Cusumano指出:在一个项目的最后阶段,要测试整个项目,就会有这么一个问题:如果你在最后一个阶段发现了一个bug,那么尝试回去修复它可能会很混乱,甚至是致命的。一些软件项目会陷入困境,根本不可能去交付了。
“人们会拿出详细的清单,列出应该做什么、他们应该怎么做,以及应该完成哪些任务,”曾参加过“雪鸟城会议”的ThoughtWorks首席科学家Martin Fowler回忆道。“一个软件和另一个项目之间的差异如此之大,以至于你无法按照那样的标准提前规划出所有的事情。”在某些情况下,文档本身也会变得笨拙起来。我采访过的人中,有几个人都有过类似的“恐怖”故事:书架上放着装订好的书或一份长达800页的文件,而且被翻译成了三种不同的语言。
另一位雪鸟城会议的参与者,Ken Schwaber——Scrum的联合创始人和Scrum.org创始人——说瀑布模型“简直毁了我们的职业”。“它使得人们被视为资源,而不是有价值的参与者。”由于事先做了这么多的计划,员工们就变成了机器上的一个齿轮。
在上世纪80年代和90年代初,纯粹的顺序模式出现了动摇,一些公司开始尝试不同的方法来完成项目,创建流程。
在1997年一篇微软的论文中,Cusumano和他的合著者Richard W.Selby描述了“瀑布”是“如何逐渐失去了青睐……因为企业通常会开发更好的产品,如果他们能够改变规格和设计,从客户那里获得反馈,并在产品不断发展时不断测试组件。”
在这个世纪交替之际,软件行业的一些人开始了真正地反击。他们想要创造一些流程,让他们有更多的灵活性,并允许他们按时交付。其中诞生了一些过程,如Scrum和极限编程(XP),被称为“轻级”或“轻量级”过程。但没有一个真正流行起来。因此,在2001年,这些倡导轻量级的人决定联合起来。
“我认为,在这一点上,我们都在寻求合法性,我们自己也在做类似的事情,但它并没有在社区中真正取得成功,”Jim Highsmith说,他是ThoughtWorks的一名执行顾问。
目前还不清楚是谁想出了这个最终会在雪鸟城举行会议的想法。许多参与者都是软件社区的领导者,一些人还记得在行业聚会上被抛出的想法。当邀请函最终到达时,它是通过一封电子邮件发来的,邮件来自Bob Martin。Martin是一名业界资深人士,也是Uncle Bob咨询公司的创始人。他经营着“Clean Code”博客,具有一种书呆子式幽默:在他的网站上嵌入了一段YouTube视频,其中包括Martin,以及其他的一些东西,比如在小行星上爆炸。Martin说,他和Fowler是在芝加哥的一家咖啡店相识的,他们在那里编辑并发送了电子邮件。
在斟酌了几个选择之后——比如芝加哥(“寒冷,没有什么好玩的事”,2001年Highsmith写道)和安圭拉(“温暖而有趣,但却很费时间”)——这群人在犹他州(“寒冷但有趣的事情”),规划了一场在雪鸟城的旅行。在那里,从2001年2月11日开始,这些人——他们都是男性——会去山坡上谈论怎样开发软件程序。
三、
我采访了17名与会者中的16人。(Facebook的技术教练Kent Beck拒绝就本文接受采访。)十多年后的今天,他们回忆了自己的参会过程。“你会想,‘你知道,让一群人待在一个房间里,他们会聊天,什么事也不会发生。’”马丁说。但事实并非如此。这群人安排好了会议,组织了活动,并发表了这个宣言。这真的是一种令人惊异的观察。”
他们在雪鸟城安顿下来,开始说出他们的共同之处。Schwaber回忆说:“当我们比较我们如何做我们的工作时,我们对同样的事情感到惊讶。”
与其他历史文献不同的是,“敏捷宣言”并没有宣称真理是不言而喻的。相反,我们更看重这一点。一些起草者说,这种建设性是该文件的重要特征之一。当然,目前还不清楚谁提出了这个问题,尽管文件的几位起草者都有自己的理论。
那么,什么是“敏捷宣言”呢?序言中写道,“我们正在发现更好的方法来开发软件,并帮助其他人做到这一点。”然后,它列出了四个核心价值观:
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
这份文件的结论是:“虽然右边的产品更有价值,但我们更看重左边的产品。”与任何优秀的原始文件一样,这些词语也会有不同的解读版本,但其基本要点是:将人们置于流程之上。专注于开发可以工作的软件,而不是软件的文档。和你的客户一起工作,而不是为一份合同而争吵。在此过程中,要对改变持开放态度。
这些人在会议期间完成了宣言。剩下的时间里,他们都在研究新文件背后的12条原则,以及滑雪。(一些人认为,这些原则被认为是宣言的正式组成部分,其他人则认为宣言本身就是一种价值观。)
这种新理念需要一个名字,并不是每个人都对“轻量级”名称感到满意。最后由一个英国人Martin Fowler提出了“敏捷”这个词。
当这些人离开雪鸟城时,没有人预料到接下来会发生什么。“当我下山的时候,我和其他一些宣言起草者一起,我在想,我不确定有人会注意到这一点,”Mike Beedle回忆道,他是企业Scrum的首席执行官。“我的感觉是,这就像是一场赌博。这就像一个问号。谁知道呢?我的意思是,也许人们会去我们提议的这个网站。或者,他们可能不会。”
四、
他们做到了。与独立宣言不同的是,“敏捷宣言”诞生于互联网时代。最后一份文件发布到了一个简单的网站上。Cunningham & Cunningham的联合创始人Ward Cunningham主持这个网站,他说他打算让人们打印这份文件,并把它作为海报挂起来。但在过去的15年里,这个网站提供一种虚拟的、集体的战斗口号。网站访客被邀请签署宣言,并公开在文件中添加他们的名字。
“我们把它放上去,然后它就爆发了,”Dave Thomas,他是《The Pragmatic Programmer》一书的合著者,同时也是南卫理公会大学的兼职教授。“那个网站实际上是一个焦点,如果你愿意的话,对于那些想说‘是的,我同意这个观点’的人。”我认为这是它取得快速发展的原因之一。”
Marick同意这一观点。他说:“我认为,人们之所以能够发泄他们的不满,是因为他们引用了Martin Luther的论文,他们也可以在上面签名。这才是真正的动力。”
签署这份文件截至到2016年7月。(Cunningham重新配置了托管服务,并开始像对待历史文件一样对待宣言。)但他表示,自首次发布以来的15年里,已有超过2万人签署了敏捷宣言。
五、
当然,宣言只是一个开始。“我的天,我希望我能去那里,”Grady Booch告诉我。Booch是IBM研究软件工程的首席科学家,他被邀请到雪鸟城的度假胜地,但他说,为了对付一个“讨厌的客户”,他在最后一刻爆发了。Booch并不怀疑“敏捷”的开创性起源,以及随后的影响。他告诉我,上世纪90年代是“软件工程发展的一个非常丰富的时期,当时你有几十个,甚至几百个,对软件开发提出了新想法的人。”他说,所有这些,都雪鸟城得到了汇总。
image.png敏捷开发过程
与“瀑布”不同的是,“敏捷”强调迭代开发,或以碎片构建软件。“敏捷”团队通常在较短的周期内工作——被人称为“冲刺”——今天是最广泛使用的“敏捷”形式之一——通常持续两周。Booch认为,“敏捷”和“瀑布”都是有效的方法,但不同的项目需要不同的方法——重要的是权衡项目的风险和正在执行的团队的文化。他说,“如果我在建造一座核电站,相信我,我不想使用增量和迭代的方法,因为测试失败永远都不是一件好事,它是不可逆转的。另一方面,如果我要开发一款一次性应用,不管它是什么,那么我肯定会把一些人放在一个房间里,然后去搭建这个应用。”
也许“敏捷”,或者类似的东西,是不可避免的:如果软件项目能够在灵活的、数字化的未来取得成功,那么他们需要能够像科技术语一样,能够对变化做出反应。网络深刻地改变了软件的交付方式,今天的软件一般不会被录制到光盘上,放在商店的货架上;更新可以被推送到你的笔记本电脑或智能手机上。这使得在发布产品后添加功能或修复错误变得更加容易。
“为了在新经济中取得成功,”Highsmith在他2001年的著作总结中写道,“要积极地进入电子商务、电子社区和网络时代,企业必须摆脱他们的Dilbert式的工作和晦涩的政策。”这种来自企业生活的不友好的自由吸引了“敏捷”方法论的支持者,让传统主义者感到害怕(你不能在专业论文中使用“屎”这个词)。
但这不仅仅是一个软件故事。如今,各行各业和世界各地的团队都在走向“敏捷”——或者,至少是使用“敏捷”哲学的零碎部分。这份文件本身已经被翻译成60多种语言。
Cockburn认为,这是因为“敏捷”成功破译了纯粹的精神和团队活动——而且“这只是历史的偶然,是程序员破译了这一点。”
Fowler说,与“更主流、更像瀑布式的想法”相比,“每个人都在做的事情非常详细”,而“敏捷”让从事这项工作的人更有力量。而且,由于它已经被各种各样的职业所采用,Arie van Bennekum甚至建议将“软件”这个词改为“解决方案”,以向所有人开放“敏捷”。
尽管就宣言本身是否应该进行修订进行了讨论,但许多最初的签署者认为这份文件是一份历史文件,而不是一份活生生的文件。Cockburn说:“这就像美国历史上的独立宣言。”“你不会回去重写它。”
Grenning说:“我认为这四个核心要素仍然是有效的。”“我不认为它们会改变。”
六、
随着公开签名的结束,“敏捷”宣言似乎不太可能再有什么改变,但这并不意味着“敏捷”没有问题。在我们的谈话过程中,许多起草者表达了对当下“敏捷”的失望。紧跟“敏捷”之后,“敏捷软件”、“敏捷教练”、“敏捷培训”和“敏捷会议”都成为了“敏捷开发”的理念。你可以花钱尝试让你的企业或团队变得“敏捷”,这是不可或缺的。
但这里有一个特别的讽刺:“敏捷”是一种哲学,而不是一套商业惯例。用四颗“子弹”勾勒出一种思维方式,一种将项目的所有复杂部分进行优先排序的框架。他们不会告诉你该买什么软件,也不会告诉你如何安排每天的团队会议。
Van Bennekum现在是Wemanity的一名思想领袖,他说:“我认为那些敏捷教练,绝对不知道他们在说什么,这是令人不安的。”
除了“敏捷”的商业化之外,非技术用户的大量涌入也造成了一些冲突。Martin坚持认为,“现在最令人讨厌的方面”是,“‘敏捷’已经被项目管理人员接管了”,而撇下了“技术人员和技术思想”。
Jeff Sutherland是Scrum的联合创始人,也是Scrum公司的首席执行官。他对软件社区内部的文档错误解读感到沮丧。Sutherland说,他认为硅谷的团队声称自己是“敏捷”的,但“在短迭代结束时没有交付工作产品”。他说,这让他们“违反了宣言的第二个价值”。他指出:“大多数人都在做的事情是,他们无法在任何合理的时间获得任何工作——他们声称自己是‘敏捷’的,因为任何人都可以做他们想做的任何事情——但这与‘敏捷宣言’不一致。”
有一些人甚至宣称‘敏捷’已经死了。但Cockburn认为,尝试“敏捷”总是有一些好处,即使它并不完美:“即使做得很糟糕,‘敏捷’也比其他所有的选择都要出色,或者至少是替代‘瀑布’,它就在那里。”
编译组出品。编辑:郝鹏程