想知道敏捷为什么叫敏捷吗？

原文作者：Jim Highsmith

译者：大卫张33

译者按

本文译自： http://www.agilemanifesto.org/history.html

要想了解敏捷软件开发，这篇文章是必读，对学习敏捷中的不少疑惑都给出了解释。感谢@AgileCoach和@徐毅-Kaveri的审校。

正文

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

由全体参会者签署的《敏捷软件开发宣言》（Manifesto for Agile Software Development）成为了重要标志，因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心，他认为多数美国人都不知道“敏捷”这个词如何发音。

Alistair Cockburn和很多参会者一样，最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后，他再次分享了自己的感受。“对我来说，很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心，因此我们的确达成了某种实质性共识。”

这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站（ http://www.agilemanifesto.org/ ）首页的《敏捷软件开发宣言》，他们称自己为“敏捷联盟”。

但多数人（如果不是所有的话）成为联盟成员的动力不仅仅是因为宣言上列出的那些理由，他们还有着更深层次的考虑。在长达两天的会议临近结束的时候，Bob Martin半开玩笑地说他打算谈点“虚的”，讲讲“空话”。Bob这话虽然有玩笑成分，却得到了几乎所有人的响应。因为我们都会非常乐于与一群拥有相似价值观的人一起共事，这些人会相互信任与尊重，会促成以人和协作为本的组织模式，能构建大家都愿意为之贡献的组织社区。本质上讲，我相信敏捷方法学家们确实要玩这些“虚的”东西。为了交付好产品给客户，他们会切实去做，不止是口头上说“人是我们最重要的资产”，还要从实际中体现出人本身就是最重要的，去掉“资产”这个提法。因此在最后的讨论过程中，敏捷方法学家们对价值观和文化这些“虚的”东西表现出了极大的兴趣，有时甚至会进行激烈的争论。

例如，我认为，极限编程呈现出强劲的发展势头，其根源不在于结对编程或重构等实践本身，而是从整体上看，极限编程能让开发人员们摆脱“呆伯特”组织中那些腐朽观念的束缚。Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候，经理临时换了另一个人和他一起工作，最后他们花了12个星期才完成项目。他的感觉很糟，因为在后面6个星期中间，经理一直喋喋不休，嫌他太慢。Kent有点沮丧，觉得自己作为一个 程序员 实在是太失败。到最后，他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败，是管理者的失败（指临时换人这件事），实际上是那些持续祸害着我们这个行业的，所谓标准化、流程化的“僵化”头脑的失败。

同样的事情每天都在重复发生。市场人员、经理、外部客户、内部客户，当然，也包括开发人员，谁都不想难为自己，去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人，甚至提出荒谬的要求。这不仅仅是软件开发的问题，在“呆伯特”组织中它无处不在。

想要在新经济环境下成功，并引领电子商务和网络时代，那么公司一定要去除“呆伯特”式的行为表现，不要没事找事做，不要搞出那些没人能搞懂的规章制度。敏捷是一种解放，让人不再虚度时光。这吸引了敏捷方法论的支持者们，却把传统主义者吓得屁滚尿流（抱歉，在专业文章中说脏话了）。坦率来讲，敏捷方法吓到了组织中的官僚们，尤其是那些乐于为过程而过程，却不全力为客户着想，不想履行承诺按时交付可见成果的官僚们，因为这（敏捷）会让他们无处藏身。

敏捷运动并不是反方法论的，事实上，我们中的大多数人正在试图恢复方法论的名声。我们希望能重归平衡。我们乐于建模，但目的不是给无人问津的企业资源库增加几篇图表存档。我们要写文档，但那些从不维护、并很少用到的长篇大论不算在内。我们得做计划，但同时也要认识到在剧烈变化的环境中计划的局限。有些人给XP、Scrum或任何一种敏捷方法论的支持者们打上“黑客”的标签，这只表示了他们对方法论和黑客本意的无知。

2000年春，Kent Beck组织了一次会议，地点在俄勒冈州的罗格里夫酒店，参会者包括极限编程的支持者们和一些“圈外人”，正是这次会议导致了后来在雪鸟的聚会。在罗格里夫会议上，参会者们宣称了对一系列“轻量”方法论的支持，但没有发表什么正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程，其中很多都提到“轻量级方法论，如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现，没人真正喜欢“轻”这个名号，但这似乎是当时约定俗成的称呼。

2000年9月，来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来，请告诉我。”Bob建立了一个Wiki网站，由此开始了热烈的讨论。

很快，Alistair Cockburn就用一封书信加入了讨论，他表达了对“轻”这种提法的不满：“我不介意用‘轻’来描述方法论的轻重程度，但我并不愿意因参加一个轻量级方法学家会议而被看作是轻量级的。这听起来有点像一群干瘦、低能、并无足轻重的人在试图回忆起某个特定的日子。”

关于会议地点的争论最为激烈。芝加哥让人不爽，既冷又无趣；犹他州的雪鸟，虽然也冷，但至少对那些想滑雪的人来说还挺有意思，像Martin Fowler在第一天滑雪就滑个头朝地；加勒比的安圭拉岛，暖和又好玩，但路途太远。最后还是可以滑雪的雪鸟胜出，不过有些人（例如Ron Jeffries）还是希望下次能去个暖和点的地方。

我们希望，一起组成的敏捷联盟能够帮助到其他同行，帮他们用新的更“敏捷”的方式去思考软件开发、方法论和组织。做到这一点，我们就得偿所愿了。

Jim Highsmith，来自敏捷联盟©2001 Jim Highsmith

参考

极限编程：敏捷软件开发方法的一种，缩写XP，英文全称Extreme Programming。

Scrum：敏捷软件开发方法的一种。

DSDM：敏捷软件开发方法的一种，英文全称Dynamic Systems Development Method。

自适应软件开发：敏捷软件开发方法的一种，缩写ASD，英文全称Adaptive Software Development。

水晶系列：敏捷软件开发方法的一个方法系列，都用Crystal开头。

特征驱动开发：敏捷软件开发方法的一种，缩写FDD，英文全称Feature-Driven Development

实效编程：不是一个方法论，是一个流派，英文全称Pragmatic Programming，

呆伯特（又名迪尔伯特）：Dilbert，美国 Scott Adams 的有名职场卡通人物。呆伯特法则： http://zh.wikipedia.org/wiki/%E5%91%86%E4%BC%AF%E7%89%B9%E6%B3%95%E5%89%87