敏捷开发的历史

编者按：“敏捷”（Agile）这个对于开发真来说不在陌生的概念，已经提出了近17年了，其背后的哲学理念也慢慢进入到了各行各业。它背后有什么故事？与“瀑布模型”相比又有什么不同？又遇到了哪些问题？近日，《大西洋月刊》发表了一篇文章详细介绍了“敏捷”背后的故事，及其带来的影响。

犹他州（Utah）的雪鸟城（Snowbird）是一个不太可能发生软件革命的地方，它位于盐湖城外约25英里的地方，一点都不像硅谷：既不以阳光和温和的气候闻名，也不是什么科技创新中心，更没有那么多充满热情的企业家。但就在这里，一个滑雪胜地，一群具有反叛性的软件开发人员于2001年聚集在一起，制定并签署了行业历史上最重要的文件之一：关于编码集的独立宣言。这个为期三天的小型会议塑造出了许多关于软件的构想、开发和交付的方式，甚至是世界是如何运作的方式。

不管你是否承认它的名字，你可能已经或多或少使用过“敏捷”方法，或者是接触到过那些正在使用它的公司。来自Spotify和eBay的代表证实，这两家公司目前都在使用敏捷方法，而且在Twitter的网站上有一份招聘“敏捷教练”的工作。互联网上的“面包屑”足迹表明，许多其他知名的科技公司过去也曾尝试过这种做法。而且不仅仅是硅谷：据报道，沃尔玛早在几年前就开始尝试敏捷方法了。敏捷联盟是一个提倡使用敏捷方法的非营利组织，它的公司成员包括洛克希德马丁公司、埃克森美孚公司和威讯公司在内的各种巨头。

敏捷方法的追随者似乎无处不在，带着一整套工具和技巧让工作场所变得更有效率。从表面上看，它可能看起来像项目管理类型使用的另一种毫无意义的企业流行语。但它实际上是一种非常具体的哲学，在雪鸟城签署的一份68字的文件中对其进行了概述。

在软件能够吞噬世界之前，人们需要从洪流中抽身出来。硅谷可能是世界上唯一一个“瀑布”（Waterfall）一词带有些许负面含义的地方。在编程中，“瀑布”被用来描述一种构建软件的方式——思考一个缓慢的、逐步的、分阶段的过程。在“瀑布”模型下，软件项目的设计非常严格，就像人们制造腕表的方式一样。

它的工作原理是这样的：有人会提出一个他们想要开发的软件。在写完一行代码之前，需求者/产品经理们会写出他们想要构建的内容，以及一系列冗长而详细的计划。他们制作所谓的“需求文档”，在上面列出他们想要软件做的所有事情。然后项目会流向下游，从一个阶段到下一个阶段，从一个团队到另一个团队，直到完成。最后，整个新软件都经过了测试，反馈给了客户，然后就交付出去了。

 

许多人把这种模式的起源归功于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年代是“软件工程发展的一个非常丰富的时期，当时你有几十个，甚至几百个，对软件开发提出了新想法的人。”他说，所有这些，都雪鸟城得到了汇总。

 

与“瀑布”不同的是，“敏捷”强调迭代开发，或以碎片构建软件。“敏捷”团队通常在较短的周期内工作——被人称为“冲刺”——今天是最广泛使用的“敏捷”形式之一——通常持续两周。Booch认为，“敏捷”和“瀑布”都是有效的方法，但不同的项目需要不同的方法——重要的是权衡项目的风险和正在执行的团队的文化。他说，“如果我在建造一座核电站，相信我，我不想使用增量和迭代的方法，因为测试失败永远都不是一件好事，它是不可逆转的。另一方面，如果我要开发一款一次性应用，不管它是什么，那么我肯定会把一些人放在一个房间里，然后去搭建这个应用。”

也许“敏捷”，或者类似的东西，是不可避免的：如果软件项目能够在灵活的、数字化的未来取得成功，那么他们需要能够像科技术语一样，能够对变化做出反应。网络深刻地改变了软件的交付方式，今天的软件一般不会被录制到光盘上，放在商店的货架上;更新可以被推送到你的笔记本电脑或智能手机上。这使得在发布产品后添加功能或修复错误变得更加容易。

“为了在新经济中取得成功，”Highsmith在他2001年的著作总结中写道，“要积极地进入电子商务、电子社区和网络时代，企业必须摆脱他们的Dilbert式的工作和晦涩的政策。”这种来自企业生活的不友好的自由吸引了“敏捷”方法论的支持者，让传统主义者感到害怕（你不能在专业论文中使用“屎”这个词）。

Cockburn认为，这是因为“敏捷”成功破译了纯粹的精神和团队活动——而且“这只是历史的偶然，是程序员破译了这一点。”

Fowler说，与“更主流、更像瀑布式的想法”相比，“每个人都在做的事情非常详细”，而“敏捷”让从事这项工作的人更有力量。而且，由于它已经被各种各样的职业所采用，Arie van Bennekum甚至建议将“软件”这个词改为“解决方案”，以向所有人开放“敏捷”。

尽管就宣言本身是否应该进行修订进行了讨论，但许多最初的签署者认为这份文件是一份历史文件，而不是一份活生生的文件。Cockburn说：“这就像美国历史上的独立宣言。”“你不会回去重写它。”

Grenning说：“我认为这四个核心要素仍然是有效的。”“我不认为它们会改变。”

随着公开签名的结束，“敏捷”宣言似乎不太可能再有什么改变，但这并不意味着“敏捷”没有问题。在我们的谈话过程中，许多起草者表达了对当下“敏捷”的失望。紧跟“敏捷”之后，“敏捷软件”、“敏捷教练”、“敏捷培训”和“敏捷会议”都成为了“敏捷开发”的理念。你可以花钱尝试让你的企业或团队变得“敏捷”，这是不可或缺的。

但这里有一个特别的讽刺：“敏捷”是一种哲学，而不是一套商业惯例。用四颗“子弹”勾勒出一种思维方式，一种将项目的所有复杂部分进行优先排序的框架。他们不会告诉你该买什么软件，也不会告诉你如何安排每天的团队会议。

Van Bennekum现在是Wemanity的一名思想领袖，他说：“我认为那些敏捷教练，绝对不知道他们在说什么，这是令人不安的。”

除了“敏捷”的商业化之外，非技术用户的大量涌入也造成了一些冲突。Martin坚持认为，“现在最令人讨厌的方面”是，“‘敏捷’已经被项目管理人员接管了”，而撇下了“技术人员和技术思想”。

Jeff Sutherland是Scrum的联合创始人，也是Scrum公司的首席执行官。他对软件社区内部的文档错误解读感到沮丧。Sutherland说，他认为硅谷的团队声称自己是“敏捷”的，但“在短迭代结束时没有交付工作产品”。他说，这让他们“违反了宣言的第二个价值”。他指出：“大多数人都在做的事情是，他们无法在任何合理的时间获得任何工作——他们声称自己是‘敏捷’的，因为任何人都可以做他们想做的任何事情——但这与‘敏捷宣言’不一致。”

有一些人甚至宣称‘敏捷’已经死了。但Cockburn认为，尝试“敏捷”总是有一些好处，即使它并不完美：“即使做得很糟糕，‘敏捷’也比其他所有的选择都要出色，或者至少是替代‘瀑布’，它就在那里。”

编译组出品。

作者为CAROLINE MIMBS NYCE

文章由36氪编译自https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/。

编辑：郝鹏程