自从2001年开始，“敏捷”一词在软件开发领域已经被赋予了一种新的意义。您真的明白敏捷一词的含义吗？这篇文章是由一名敏捷实践参与者所撰写。文章讨论了如今越来越重要的迭代和增量开发风格的基础方面，并用以文学评论的方式作了总结。

在 Princess Bride 这部电影中，Dread Pirate Roberts 正在攀爬 Vizzini 将要剪断的一条绳索。当 Roberts 并没有掉下来的

时候，Vizzini 说了一句"他没有掉下来？难以置信！" Inigo Montoya 回答道，"你经常使用的那个词，我并不认为他是你所认为的那个意思。"

当我和别人谈论敏捷一词的含义时，我的感觉和上面场景中 Montoya 的一样。我常常认为我们说的是同一件事。但是这不意味着我是正确的，他们是错误的。这只能说明敏捷一词的含义非常混乱。  软件行业中的人们有一个习惯，就是喜欢制造他们想要表达意思的词语，特别是在新技术领域。为了让这个新技术更易理解：我们的技术变化的太快，很多新的术语和简称几乎天天都会出现，我们很难跟上这个速度，因此我们试图对这些新术语产生麻痹的态度，并且希望我们更加的正确。

虽然敏捷一词已经出现很久了，但是仍然存在很多术语的滥用问题。

这个月，我将要公布一份关于敏捷前景的调查。我们首先要给这个术语做个定义。这并不是一件容易的事情。实际上，我并不确定能够胜任这项工作，不过我会努力的。首先，让我们从定义开始，来看看人们是如何曲解敏捷的意思。在我们达成定义的共识后，我会回顾一些有用的书籍和参考资料，他们能够为敏捷的前景指明方向。

最开始...

在2001年2月以前，"敏捷"一词意味着"标记快速的优雅的移动的能力"，或者是"拥有快速的机敏和适应能力的角色。"  从2001年开始，这个词对于软件开发人员来说拥有了更多的意义。由17个人组成的一组自称为无政府组织的团体出现了， 但他们实际上主要由软件开发领域的软件顾问和思想的领导人构成， 他们聚集在 Snowbird Utah 来定义敏捷的软件开发过程。虽然他们能在普通层面上对敏捷的理解达成一致，但是每一个与会者都有自己对于如何建立一个高质量软件的看法。

这种普通层面上的一致是在 Snowbird 举行的 Agile Manifesto 大会上面达成的。 我在之前已经讨论过这个宣言了，但是在这里我们仍然值得重复这四个条对于敏捷价值观的定义： 

 个体与交互 重于 过程和工具
 可用的软件 重于 完备的文档
 客户协作   重于 合同谈判
 响应变化   重于 遵循计划

这四个条对于敏捷价值观的定义看起来非常的简单明了。但是它引发的误解比任何一个词引发的误解都要多。这是为什么呢？我认为有三个原因。

首先，人们将 "敏捷" 一词理解为普通的用法。当我们谈到敏捷开发时，听众听到 "敏捷" 一词，正如我在介绍中提到的，会惯性的理解为我们在谈论一个很快速移动和变化的事物。当然，我们的软件项目变化是很快，但并不是所有的都是这种情况。如果在 Snowbird 大会上与会者没有事先定义描述软件开发过程的词汇，那么同样的问题也会发生。在当时，有很多人使用 轻量级 一词来将其和重量级过程区分，这些过程是由大型软件开发顾问公司强加给他们的。

其次，即使人们意识到敏捷一词的背后可能有其他含义，他们也会按照自己的想法来定义它。他们或许之前阅读过关于敏捷开发的书籍和文章，并尝试过使用这些方法来使他们的项目更加敏捷（根据他们自己的定义）。不幸的是，人们试图扭曲敏捷一词的含义，这些人中甚至包括一些专家和接触敏捷一段时间的人群。您所要做的就是参加一个敏捷讨论会，这样您就会明白我说的意思了。很多人都将敏捷概括为一种艺术："我看到它就会理解它，"或者是"它是一个非常个性化的定义。" 在去年的敏捷大会上，一些人说他们已经实现了"成熟的" 敏捷。当我问到他们这意味着什么的时候，他们的定义是，他们正在做单元测试和持续的集成。这些实践虽然可以用来支持四个值，但是它们本身并不是敏捷。

最后的理由来自于这些值的声明。很多人都会考虑这些值是如何规定的，但是许多人只是了解一下它们是怎样划分的。例如，"全面的文档"和"工作的软件"相对立吗？这些值好像暗示了这种可能，但是这两个方面是对立的，但是实际上并不存在合理的理由。因此我们拥有的四对值，每一个都被 Agile Manifesto 创造者放置在了和其他四个相对立的位置。我的目的并不是争论选择的正确性，而是简单的说明您只有在接受了成对值，并评价每一对中的第一个和第二个值。如果您决定了全面的文档化比单独和交互更加合适，那么我可以严肃的告诉您，您没有使用比较的方式来谈论 敏捷。这就是我们在谈论敏捷时容易产生混乱的第三个原因。我们很多人都不同意初始化配对。

一个科学的方法

接触一个学科的最好的方法，不管它是新的或者已经很好的制定的科目，我们都应该从定义开始，然后是严格的分析与质问，看它能引导我们做什么。让我们对敏捷这么做吧。

如果我们把 Agile Manifesto 作为资源文档，那么我们可以确定所有的组织或者项目都希望敏捷必须能够显示四个值中标识为第一位的特性（例如"客户协作"），要比标识为第二位的特性（"合约商议"）更能够评估它。Alistair Cockburn 曾经告诉我，敏捷是宇宙中16个可能存在的位置中的一个。他的意思是如果您考虑每一对值，您就拥有评估第一个和第二个值的选择。这是一个二择其一的问题。因为现在有四对值，所以有16种配置的可能性。我想这是理解敏捷的最简单，最清晰的方式。这就避免了我们试图区分敏捷的程度而产生的问题。使用 Cockburn 的描述，我们可以决定组织或者项目是否是敏捷的。如果组织具备这些评估数值，并按照执行方法应用它们，那么它就是敏捷的。如果不是则相反。

我们还可以从相反的观点来了解敏捷，这种思想是 Jeff Foxworthy 提出的。 5 如果您尽可能多或者超过使用单独交互这个值所规定的过程和工具，那么您也不是敏捷的。如果您评估的结果是完全文档化过多或者超过工作软件，那么您就不是敏捷的。如果您评估的结果是合约商议过多或者超过客户协作，那么您就不是敏捷的。如果您的评估的结果是计划过多或者超过相应变化，那么您就不是敏捷的。

上面的措辞中需要强调的是您不需要更多的评价非敏捷的特性。相对于敏捷来说，您最好尽量少的评价它们。如果您是一名项目的系统工程师，我猜想您的评估更多的是考虑到您的计划，而不是响应改变。您会涉及到硬件和软件问题，并且需要努力的将它们根据时间表整合起来。相对于硬件来说，改变软件更加的容易。

因此，如果我说我们不需要敏捷，那么我相信敏捷团体会严厉的抨击我。我们选择敏捷，是因为它对我们的项目和组织有重要的意义，而不是它本身有什么意义。当您和敏捷团体的成员对话时，他们都很明白这个道理并且在这一点上有共识。但是，像能够看到光，并想要分享它的福音传道者一样，他们强烈的热诚可能会压制您的想法。

您拥有确定的价值，并将这些价值转化为实践。宣言的作者为想要遵循敏捷的人提供了一系列原则。 6 如果您按照这些原则进行您的工作，那么您就是一个敏捷执行者。

文章的剩余部分将会介绍您使用敏捷和敏捷的一些定义。敏捷是按照 Agile Manifesto 大会上的定义，以及一系列相应的原则定义的。

哪里出了问题？

我刚提到的定义非常简单。在组织和项目是否是敏捷这个问题上面，为什么还存在着这么多混乱和冲突的意见？部分的问题是由于原则的制定方式引起的，它为这些实践留出了解释和执行的空间。让我们看看一对问题。

我们的原则规定"根据个别的动机构建项目。为它们提供环境和所需的支持，并信任它们能够完成任务。"您如何执行这个实践？首先，您需要知道什么是一个个别的动机？一些人是出于简单的商业利润动机。另外一些人的动机来自于庞大的团队。一个团队的个别动机可能会干扰到另一个团队的动机。当您拥有一个组织事先挑选的人才时，您可能不需要适合您的项目小组定义的动机的个人。您还能继续敏捷么？

另一个原则规定 "敏捷过程促进开发的维持。项目出资方、开发人员和用户应该可以长期的维持一种不变得步调。"很明显的，如果我们将标志杆设低，并少做工作，这也是我们能够长期维持的一种步调。还有一点也很明确，就是意图不一定就在原则之后。

我们可能单独的采用大部分原则，并将它歪曲为背离敏捷的精神。当完成整个工作时，它们确实会相互支持。但是仍然存在很多执行原则的空间。这为敏捷训练，顾问、方法学家和其他想要帮助组织成为敏捷和提供顾问的敏捷组织提供了有利的市场。它同时还促成很多组织采用新的实践，并声明他们已经根据方法学家的解释获得了敏捷。

获得一个敏捷的解释很容易。达到一个有效的解释程度却非常难。没有圣贤准确的告诉我们的项目或者组织是否是敏捷的。您必须要问的问题就是，这很重要吗？如果有效的生产出符合投资人所有需求的软件，那么您就非常的成功。您应该不断改进，但是您真的需要适应所以得需求吗？这是在您试图使用 CMM 和 CMMI、RUP 和其他方法学时会遇到的问题。个人和组织会"被鉴定"处于哪个层级，而不是简单的集中在最后的目标身上——软件的交付使用。方法学和实践意味着它们不是结束。

好的，如果它就是这么简单的话...

在2006年明尼阿波利斯举行的敏捷大会上出现了一个问题："如果敏捷这么简单的话，那为什么会有这么多的教科书教我们应该怎样去做？"当然这种说法有些开玩笑的意味，但是确实存在这样的问题。坐在学校的办公室里，我几乎有一整个书架的关于敏捷的书籍。至少有30本。另外我的家里还有10几本这样的书。关于敏捷的书籍太多了，为什么会有这么多种类的书呢？

对于这个问题最简单的回答就是，书籍可以让那些顾问们更好的推销自己。书籍同样可以让那些理论学习者和从业者更好的扩展他们的视野。书籍可以在艺术级和实践级别上都给人以影响。不论何时当有新的观念被发现时，书籍，期刊论文和各种文章将会很自然地发布消息。那些具有很大影响力的观念一般会在讨论会上面形成。关于技术方面的话题是那些书刊所要报道的重点，因为，正如我在文章的开始所提到的，对于那些整天投身于 IT 行业——不断变更的项目，最终期限的到来，控制在预算之内，所有这些需要满足客户需求的事情——的人来说，随时关注能够帮助他们完成任务的最新方法，没有这些商品和帮助的指导是不可能的。

第二种解释就是，很多作者都在他们出版的书中声明自己有了关于某个热点话题的一种新方法。这就导致几乎每一本书都宣称自己介绍了一些作者关于价值和原则的新的有趣的想法。其中很多书重复的介绍了执行原则和价值的一种方法。比如一些自助书籍，它们声称只要按照他们的程序做，您就会成为敏捷的。如果您曾经尝试过不同的饮食习惯，娱乐节目，阅读改进程序等等，那么您应该很清楚的知道，有些事情对于一个人来说很成功，但是对于另一个人来说可能没有任何效果。同样的道理在敏捷方面的书籍上面也适用。一种方法在项目 A 上适用，但是到了项目 B 上可能会惨败。每一个项目和组织都要找到适合它们自己的那个敏捷，当然前提是您的项目和组织适合使用敏捷。

无处不在的敏捷

敏捷现在可以说无处不在。它不仅存在于软件开发领域。如果一个实践值得我们花时间和努力去学习和应用，那么它就是敏捷的。如果一个工具值得在我们的项目上学习和使用，那么它必须支持敏捷。这不仅是满足实际需要的问题，更是一个市场营销问题。敏捷就像一个新品牌的运动鞋，我们买来是想让它帮助我们的开发小组跳得更高，跑得更快。

有一天我在一个书店中挑选了一本关于 Ruby 程序设计的书籍。在这本书的封底上印着："Ruby　是一种敏捷的面向对象程序设计语言。"虽然他们没有将敏捷一词的字母 'a' 大写，但是我并不确定普通的读者是否能够意识到这个问题。Ruby 真的是 Agile Manifesto 上包含的价值观吗？这显然是一个荒谬的问题。但是我们现在谈论的是市场问题，逻辑上的问题并不是最重要的事情。使用 "敏捷" 一词去吸引客户的注意力，让您可以进入门槛。（我真希望有一天我们的顾客也能够变得聪明起来，他们可以提出正确的问题，并重视敏捷。）

我并不反对敏捷。但我也不是一个敏捷主义者。我希望被认为是一个实用主义者，我只使用那些可以帮我的东西，忽略那些对我没有用处的东西。有时候敏捷可以在工作上帮助我。但有时候我需要一些其他的帮助。

敏捷起源以及敏捷创始人的传记-第一部分