文/Ivar Jacobson

在支持软件工程（比如Rational统一过程RUP）与敏捷阵营（比如SCRUM或是XP）之间，人们一直存在着冲突。也不难理解，因为这两种方法间都是在用着彼此并不兼容的方式来描述的。其实大可不必，因为他们背后的观点全然是相辅相成的。关键在于该如何用对两者来说都公平的方式来融合它们。

在软件世界里，我们都喜欢跟风。我们从对一种开发方法的青睐转为对另一种开发方法的热衷，其实就是太过极端。有些人已经跟了一辈子的风，最后自己也受够了这种方式。

五年前，我在新加坡做了一场50人规模的演讲。演讲期间，有一位资深人士极其沮丧地站起身来，然后跟我说五念之内UML和RUP就会销声匿迹，而我也将风光不再。我喜欢这种挑衅，于是就温和地问他为什么会这么说。他告诉我说，他的一生都在从事软件开发：“在60年代，我们都是用汇编语言，然后过渡到了Cobol和Fortran，之后又做了数据库的设计。”接着，他又描述了采纳新技术所经历的每一个阶段：结构化编程、面向结构的分析与设计、面向对象、面向组件等等。当听说到一种新的标准建模语言时，他感到很不舒服。我就告诉他，我所经历的是与他不同的另一条技术路线：汇编、组件化汇编、组件化程序设计、面向结构的组件编程、面向对象的组件编程，而现在则是面向对象与面向方面的组件编程。这一路过来都是与组件有关的。而且我们一路过来都在使用某种可以用UML来描述的建模语言。

看来到如今我还在这个阵营之中，而且还打算再待上很多年。那个很不高兴的家伙第二天更加郁闷，因为他被他的老板炒掉了。不过，UML和RUP略显动力不足倒是不争的事实，只是离消亡还远着呢。它们只是在这个快速变化的世界里打了个小盹而已。

我们曾经处于一种极端，即做任何事情都使用UML，并像大多数人一样坚信它在软件开发过程上的强大描述能力；另一方面，我们又倒向了另一个被叫做敏捷的极端。年轻的一代人正在开始着他们的第一次跟风，目前来说就是敏捷了。非常有趣的是，那些稍稍年长的人们正在从软件工程的极端倒向敏捷。我们不停地追逐，而我们所在的公司也在跟随着我们的步伐。

   如今，每个人都敏捷了。可不，敏捷之外的就成了愚蠢的。我也要清楚而大声地喊出来：我是敏捷的大粉丝，我们在Ericsson的团队也是极其“敏捷”的。

可是，我所交谈过的大多数人对敏捷真正所讲述的东西并不十分清楚。去年三月，我参加了一场英国的敏捷“传教士”座谈会。组织者原本希望我是反对敏捷的，然而他们失望了。观众让我们为敏捷做出定义，台上那些声称是敏捷专家的“传教士”们开始畅谈起来。他们不停地强调敏捷最重要的要素就是迭代。那可是完全错误。迭代式开发是RUP的核心实践，而且它远在RUP出现以前就已经存在了。它原本被称作螺旋式开发，是由Barry Boehm在70年代末创建的。于是我不得不帮助他们来解读敏捷：

敏捷是关于三件事情的：

   1. 最重要的，敏捷是一门社会科学。这是敏捷最大的特点所在。它关注的是如何让大家像一个团队一样来工作，如何激励团队成员，如何相互合作等等。

   2. 敏捷是轻量级的。与RUP完全依赖“显式知识”不同，敏捷还依赖很多隐含的知识。在RUP中，我们努力把我们认为是最佳的实践写出来。不过，既然实际情况是人们根本不读关于开发过程的书，写下它们也就变得毫无意义。相反，敏捷认为要想开发出优秀的软件，有知识丰富的人就足够了。虽然这一点显然会遭受置疑，但事实的确如此。

   3. 敏捷也提供了一些技术性的实践。这实际上是敏捷中最不重要的一部分。这些技术性实践大多不是新生事物：就像我前面提到的，迭代与增量式开发都有悠久的历史；用户故事（user story）可以看作某种形式的简化版用例（use case）。最为有趣的新点子是测试驱动开发。我并不是说敏捷的实践技术没有价值，我只是要强调：如果仅有这些内容的话，我们是不会为敏捷如此痴狂的。

  

   就像你们所看到的，软件工程与敏捷抓住了软件开发的不同方面。软件工程的强处在于技术性实践；而敏捷的优势是社会工程。因此，它们是互补的。

软件工程就像是件紧身衣，而敏捷是轻巧的，并且更难于驾驭。问题在于，我们能否集合两个世界的优点。是的，我们能！

   最后，软件工程阵营有一系列的实践技术，对岸的敏捷方法也有另一些略带重复的实践。我们能找到一种共融之道吗？是的，我们能！

   要做到这些，我们必须用崭新的理念来看待“实践”。我们可以不再赘述过程了，实践取而代之成为了第一等公民。过程只不过是实践的组合。与其谈论第二代软件过程的被动与臃肿，我们不如展望第三代软件过程的灵活与面向实践。

   如果你打算看看第三代软件开发过程，可访问我的网站www.ivarjacobson.com。