RUP是如何输给敏捷Agile的？

RUP是Rational Unified Process的简称，曾经几乎一统天下的庞大理论和工具体系；即使是现在看来，客观的讲RUP的确是一套非常先进并完整的理论体系+工具集合；但是，他仍然无法挽回败给了敏捷Agile开发理论。

本文将简单回顾RUP和敏捷的发展历史，并试图从一个角度来解释其进行交替的原因。

上世纪80年代末90年代初，面向对象开发的田园时期。面向对象的编程语言机制刚刚兴起，当普通大众们（也包括我）还在理解消化基本语法规则的时候，先行者们已经开始思考与探究面向对象分析与设计的内在规律了。

比如神仙级别的Peter Coad和Yourdon。在当年，其撰写的《面向对象的分析》和《面向对象的设计》两本小册子就是我等能够找到的唯一的关于这方面的理论性阐述的书籍。基本上讲，当初就是用这两本书来开蒙的。（以后找时间聊聊关于Peter Coad的FDD和彩色UML）

而GoF已经对他们所经历过的项目中的“设计模式”进行总结与归纳了。

当然，对本文的题目来讲，必须要提的就是传说中的“三剑客”：不吃（Grady Booch），借考布森（Ivar Jacobson）和拉不服（James Rumbaugh）。

他们开始是分别对面向对象进行思考，并且形成了各自的理论体系，直到“桃园三结义”的那一幕发生。三巨头会面之后，发现对于对方的研究成果很感兴趣，并最终决定将三种理论体系进行统一！统一的结果就是UP（Unified Process）的诞生（UML仅仅是其附带的产物，当然最终人们发现UML还可以独立的使用并产生巨大价值）。

后来，三剑客为了更好的进行布道并顺带把研究成果变现，他们做了几件事。其一，分别撰写了几本经典的鸿篇巨著；其二，共同成立了Rational公司，并开发了用于承载其理论体系的软件过程管理平台与工具集Rational。UP基于Rational平台的具象化成果就是RUP。

大家喜闻乐见的开发管理和辅助工具，如Rational Rose, ClearCase, Robot, Requisite等等都是Rational平台中的组件。

再后来，就是Rational被IBM收入旗下。（那些年的IBM在软件工程领域真是叹为观止——GoF与三剑客都在为其效力）

RUP是一份雄心勃勃的宏大计划，包括行为规范、文档模板、流程说明、辅助工具等等，堪称包罗万象，力图覆盖所有的软件开发场景。而事实上它也在无限接近这个目标（我个人感觉）。

现实当中，RUP的确发挥了巨大的作用，对于仍在黑暗中摸索的广大项目经理、架构师以及开发人员来讲，他基本上就是迷雾中的灯塔。（我只讲讲国内的情况：高校计算机专业，软件工程课程的内容基本上都是面向过程的结构化开发为大背景的，因此大家对于传统的瀑布模式以及成为了思维定式。这时，面对新生的面向对象编程环境来讲，应该如何进行弹性设计、如何进行迭代模式的管理、如何进行测试和发布等等，一部分人已经在思考了，但是绝大多数人基本上还是在混沌状态，此时RUP的出现刚好填补了这个巨大的空白，又基于三剑客的声望的情况下，RUP很快便被奉为事实上的行业标准。）

然而随着时间的推移，RUP自身的问题也日渐明显：想在软件开发项目中正确的领悟并且运用RUP将意味着巨大的工具购买成本和学习成本！前者在国内来讲还暂时可以克服;-P，但是后者的确成为了最大的障碍。就我个人目睹，有多少大大小小的软件开发团队打着RUP之名而行瀑布开发之实。（其实国外的情况也好不到哪里去）

时间来到了世纪之交，一批开发和过程管理大师们（其实，几乎所有的大师最开始也就都是草根）对于僵化的流程和繁琐的文档实在忍不下去了，开始寻找新的方法进行突破。

（在这里需要着重强调一下：敏捷开发的真正靶子实际上是面向过程开发年代的软件工程规范，包括瀑布模型、ISO以及CMM等；因此严格上讲，在敏捷开发成长的过程中，实际上RUP被严重误伤了。）

在这个过程中，一批新的大师走到了前台：Kent Beck, Alistair Cookburn, Larman, Robot Martin, Martin Flower, Mike Cohn, Highsmith等等。当然，同时一批经典著作也随之出现

时间：2001年，坐标：犹他州。世界各地的大师们齐聚一堂，聊人生、谈理想、唱着歌、吃火锅……会后，发表了那一份著名的《敏捷宣言》。

当时进入敏捷联盟中，比较有代表性的方法体系有如下几种：

• 极限编程（XP）
• SCRUM
• Crystal过程
• 自适应软件开发
• FDD
• DSDM等

它们当中有些比较相似或者相互兼容，有些则不，甚至可以讲有比较大的差异，但是最起码，价值观是相同的。

敏捷理论大规模进入中国大约是2003年以后的事儿了。同样的，在这个过程中，有先行者（我大概也算一个吧B-) ），有误解者，有观望者，也有诋毁者。

随着时间的推移，狂热慢慢冷却，同时一切也会慢慢变得成熟。现在的情况大家都清楚了：敏捷过程是基本配置（虽然我仍然觉得有相当一部分团队并未真正掌握敏捷开发过程），UML已经很少有人再提了，RUP更是成为了古董般的存在。

历史回顾完毕，下面聊聊我对RUP的看法以及对其失败原因的理解。

有几点先需要澄清一下：

1. RUP绝不等于瀑布模型，RUP是典型的迭代开发模式；
2. RUP是面向各种类型软件开发项目的指导原则、流程定义、行为规范以及辅助工具的集合，因此，显然根据不同的项目类型和项目规模是可以进行裁剪的。

下面是我个人对于RUP的总结：RUP从理论体系上来讲，逻辑是严密的，体系是完整的，显然是学院派风格的产物。同时，其理论体系的执行难度以及工具的易用性上面都存在一些问题。

又大又全的RUP在实际的场景中，遇到了巨大的逻辑陷阱：面对五花八门的中小规模软件开发项目来讲，完整的RUP体系显然过于笨重了，需要进行裁剪；但是！越是中小规模的软件开发团队越是缺乏有能力对RUP进行正确裁剪的人员！

也许是出于经济利益上的考量，也许是由于其他的原因，Rational在此方面从未给出有足够声势或者足够明确的标准和指导。(第三方倒是有出现过简化版本的RUP，但是人微言轻，这个以后有机会再聊。)

尤其随着互联网的兴起以及丰富多彩的Web开发模式&框架的快速发展，Rational的反应明显迟钝了。

在这方面，更加接近一线工作人员的敏捷联盟成员们显然做的更加出色。

先说说可执行性。

敏捷宣言仅有4条比较抽象的价值观外加十几条工作准则，既简单又明确。拿其中名气最大的极限编程（XP）来说，明确的给出了几款供开发人员模仿的最佳实践：

1. 结对编程
2. 测试驱动
3. 客户驻场
4. 快速设计
5. 计划游戏
6. 隐喻
7. ……

开发人员执行起来门槛更低，见效更快。更加夸张的SCRUM甚至一张图就能完整的描绘整个管理过程。

而同时，敏捷联盟中，理论更加抽象自适应软件开发过程使用的人就少很多。由此我们可以看到，其实现实的逻辑就是：谁更接地气，谁生存的机会就越大。

其次，我们在看看对于“变更”的态度。

大家都知道，“变更”其实是软件开发这个行业中根本性的痛点。RUP（包括传统的软件工程理论和项目管理理论）其实并非完全的抵触“变更”，而是用了一个比较柔和的说法：管理变更。但是，现实中这个痛点已经痛到了即便如此模糊的用词也无法调和客户与开发团队之间的矛盾了。

对此，敏捷联盟体系则表现的绝不拖泥带水，非常干脆的表达：拥抱变更！（当然，也同时给出了各种辅助手段）这个响亮的口号在人们的心智中彻底的解决了上述根本性的问题，人们当然会对此趋之若鹜。

至此，虽然并非每个敏捷方法的理论体系都是完备的（例如极限编程就属于非常侧重于工程实践的技术过程，而SCRUM则明显是管理过程，所以曾经一度XP+SCRUM变为了标准配置），但是这些已经都不是重点了，大的趋势一旦形成，无法逆转。

由此我们需要意识到，在某种情况下，事物的简单性就是压倒一切的力量！

我们可以类比一下，J2EE框架 vs Ruby on Rails框架的情形与RUP vs Agile的情形是多么的类似啊。再早一些，Java其实也是以其简单性才获得快速成长的机会的。

事物都是具有两面性的，在拥抱敏捷软件开发过程的同时，我们也应该意识到敏捷过程其实也是有一些自身的问题的。并且，即使已经发展了很多年，在开发人员中仍然存在着对敏捷过程的各种误解。

我希望能在下一篇文章中，专门针对敏捷软件开发的过程逻辑聊一聊。