敏捷究竟是什么？

在软件世界里，我们都很喜欢跟风。我们从对一种工作方式的热衷转换为对另一种工作方式的喜爱——从一个极端走到另一极端。有些人就这样，一生都在跟风，最终让自己疲惫不堪。

大约五年前，我在新加坡做了一场50人规模的演讲，期间，一位资深人士非常沮丧的走上前来，告诉我说UML和RUP在未来的五年内便会消亡，而且我也风光不再。我喜欢这种挑衅，于是很镇静地问他这样说的依据是什么。他告诉了我们，他的一生都是在进行软件开发。“在60年代，我们都是在和汇编程序打交道，然后发展到了Cobol和FORTRAN语言，之后又做了数据库设计。”接着，他描述了应用新技术所经历的曲折步骤：结构化编程、面向结构的分析与设计、面向对象、面向组件等等。当听说一种新的标准建模语言出现时，他就会感到局促不安。我告诉了他，我所遵循的是另外一条与他不同的技术路线：汇编程序、组件化汇编、组件化程序设计、面向结构的组件编程、面向对象的组件编程，以及现在的面向对象和面向方面的组件编程——这一条与组件密不可分的道路。而且，我们一直使用某种可以用UML来描述的建模语言。

我现在仍在这个领域中，而且我还打算再待上几年。。。祝我好运吧。那个不开心的人第二天变得更加怏怏不乐，因为被他的上司解雇。然而，UML和RUP的确有些丧失动力，但离消亡还远着呢。它们仅仅是在日新月异的世界中休息一下罢了。

我们曾经处于一种极端——做一切事情都必须使用UML，并象大多数人一样坚信它能够规范软件工程过程。同时，我们又倒向了另一个称为敏捷的极端。年轻人正在开始他们的第一次跟风，目前而言就是敏捷。有趣的是，中年人现在从使用软件工程的极端倒向敏捷这一极端。我们在不停的跟风，而我们所在的公司也与我们一起追逐。

现在，每一个人都是敏捷的。这当然啦，敏捷之外的其他事情都是愚蠢的。让我大声而清楚地喊出来：我是敏捷的一大爱好者。我在Ericsson的团队就是极其敏捷的。

然而，我所交谈过的许多人对敏捷真正讲述的内容却仅有模糊的理解。去年三月，我在英国参加了一场敏捷“传教士”的公开座谈会。组织者原本希望我是反对敏捷的。但是他们失望了。观众请求我们为敏捷做出定义，这些声称自己是敏捷专家的人们变开始畅谈起来。他们不断强调，敏捷最重要的属性就是迭代。那绝对是错误的。迭代开发是RUP的核心实践之一，而且早于RUP的出现。70年代末期，Barry Boehm创建了该开发方法，称其为螺旋式开发。于是，我必须帮助他们来解释敏捷到底是什么：

敏捷是关于以下三件事情的：

1.        最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的形式开展工作，如何激励团队成员，如何相互合作等等。

2.        敏捷是轻量级的。RUP完全依赖显性知识，与此不同，敏捷还依赖隐性知识。在RUP中，我们设法把我们认为是最佳的实践记录下来。然而，人们根本不阅读关于开发过程方面的书，写下这些书也就毫无意义了。相反，敏捷认为，只要有掌握足够知识的人，就可以开发出优秀的软件。当然，这个观点倍受质疑，但是事实的确如此。

3.        敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。它所提供的技术实践几乎没有包括新技术。迭代与增量式开发，都是存在很久的观点。用户故事，则是某种特殊类型的简化版用例。最为有趣的新想法就是测试驱动的开发。我并不是说敏捷技术实践毫无价值，而只是强调，如果它仅仅就是这些内容的话，我们就不会为敏捷如此痴迷了。

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

软件工程就像是件紧身衣，束手束脚，而敏捷则十分轻巧，但更难驾驭。问题在于，我们能否从两个世界中取其精华。当然，我们能！

最终，软件工程阵营有一系列技术实践，不同的敏捷方法也有另一些略带重复的实践。那么，我们能找到两者共存的方式么？当然，我们能!

要做到这些，我们必须用新的观念来看待实践。我们不再谈论过程，实践已经取而代之，成为一等公民。过程仅仅是实践的组合。与其继续讨论第二代过程的被动与臃肿 (大过程)，不如谈论灵活与面向实践的第三代过程。如果您现在就想一览第三代过程的风采，请访问我的网站www.ivarjacobson.com。