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其实也是以其简单性才得到快速成长的机会的。

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

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