够创造最大价值的软件，能够随时让——就像故事中提到的——这种有价值的想法得以实现，这就是一个成功的项目。
所以，亲爱的读者，请你忘记本文标题上出现的“敏捷”二字，我们在这里所说的不是别的，就是一种为客户创造最大化价值的软件开发方法。这样的方法有很多种，但它们有一个共同的特点：尽快、尽可能频繁地交付可以工作的软件，让客户尽快开始使用软件，从使用中创造价值、厘清思路、提出反馈。仍然以 ThoughtWorks 的项目为例，这些项目通常在启动开发阶段之后一个月内就会发布第一个版本，随后每一周或每两周发布一个新版本——每个版本都是一个可以工作的软件，每个版本都比前一个版本具有更丰富的功能，并且每个版本都包含客户认为迄今为止最有价值的那些功能。用软件开发的“黑话”，“开发下一个版本”的过程叫做“迭代”，这些开发方法最大的共同点就是“迭代式开发”——不是一股脑地交付全部功能，而是每次增加一点、渐进地交付最有价值的功能。
2、软件开发的梦想与真实
回到文章开始处的两个故事。我曾经说过，对于很多软件企业而言，项目 A 是一个“理想的”成功项目。那么，是什么让情况变得不那么理想?
答案是一个所有软件开发者耳熟能详的词：需求变更。在真实的项目中，客户通常不会等到最后一天再照单全收整个项目，因为他知道自己的业务正在发生变化。这时需求变更就出现了，伴随着来回的扯皮和讨价还价。更糟的是，大量的需求变更发生在项目晚期——因为直到这时客户才真正看到、使用到这个软件，他的很多想法才真正浮现成型。随着这种“最后一分钟的需求变更”，项目超期、超出预算也就成了家常便饭。能够像项目A这样完工交付的，实在是凤毛麟角的幸运儿。
为了对付需求变更这个噩梦，软件开发者们还发明了另一个词：变更控制。这个有趣的词暗示着：需求变更是一种“不好”的东西，是需要“控制”的东西。然而站在客户的角度上想想，他在亲身使用了软件之后提出的要求，难道不是最有价值的东西吗?把这种真正创造业务价值的要求“控制”起来，难道是合理的吗?
既然有这么好的软件开发方法，既然它能够为我们创造更大的价值，那还等什么呢，我们马上就动手吧。事情不会那么简单。为了让迭代式开发能够成为现实，为了确保尽快、尽可能频繁地交付，为了确保每次交付的都是最有价值的功能，我们——包括软件开发者、软件企业和客户——需要很多的改变。这里既有职责与权利的划分，也有开发过程和团队的重组，还有技术层面的实践指导。这些正是敏捷方法学所涵盖的内容。缺少了这些东西，“为客户创造最大价值”就只能成为一句空话。在后续的文章里，我们将结合 ThoughtWorks 的实践经验，逐步介绍敏捷方法的方方面面。
在前面我也暗示过，并非所有的客户都一定青睐迭代式开发。不过，如果读者认真思考的话，这样的例子也许并不多——也许比你最初认为的要少得多。一个很好的例子是“神州六号”火箭使用的计算机控制系统。还有多少这样的例子?读者不妨试着自己想想。从整篇文章的内容不难看出，如果客户的业务绝对不会变化，如果客户的需求巨细靡遗非常明确，如果客户不需要尽快开始使用软件以便收回成本，那么迭代式开发对他的帮助就会小得多。