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的看法以及對其失敗原因的理解。
有幾點先需要澄清一下：
- RUP絕不等於瀑布模型，RUP是典型的迭代開發模式；
- RUP是面向各種型別軟體開發專案的指導原則、流程定義、行為規範以及輔助工具的集合，因此，顯然根據不同的專案型別和專案規模是可以進行裁剪的。
下面是我個人對於RUP的總結：RUP從理論體系上來講，邏輯是嚴密的，體系是完整的，顯然是學院派風格的產物。同時，其理論體系的執行難度以及工具的易用性上面都存在一些問題。
又大又全的RUP在實際的場景中，遇到了巨大的邏輯陷阱：面對五花八門的中小規模軟體開發專案來講，完整的RUP體系顯然過於笨重了，需要進行裁剪；但是！越是中小規模的軟體開發團隊越是缺乏有能力對RUP進行正確裁剪的人員！
也許是出於經濟利益上的考量，也許是由於其他的原因，Rational在此方面從未給出有足夠聲勢或者足夠明確的標準和指導。(第三方倒是有出現過簡化版本的RUP，但是人微言輕，這個以後有機會再聊。)
尤其隨著網際網路的興起以及豐富多彩的Web開發模式&框架的快速發展，Rational的反應明顯遲鈍了。
在這方面，更加接近一線工作人員的敏捷聯盟成員們顯然做的更加出色。
先說說可執行性。
敏捷宣言僅有4條比較抽象的價值觀外加十幾條工作準則，既簡單又明確。拿其中名氣最大的極限程式設計（XP）來說，明確的給出了幾款供開發人員模仿的最佳實踐：
- 結對程式設計
- 測試驅動
- 客戶駐場
- 快速設計
- 計劃遊戲
- 隱喻
- ……
開發人員執行起來門檻更低，見效更快。更加誇張的SCRUM甚至一張圖就能完整的描繪整個管理過程。
而同時，敏捷聯盟中，理論更加抽象自適應軟體開發過程使用的人就少很多。由此我們可以看到，其實現實的邏輯就是：誰更接地氣，誰生存的機會就越大。
其次，我們在看看對於“變更”的態度。
大家都知道，“變更”其實是軟體開發這個行業中根本性的痛點。RUP（包括傳統的軟體工程理論和專案管理理論）其實並非完全的牴觸“變更”，而是用了一個比較柔和的說法：管理變更。但是，現實中這個痛點已經痛到了即便如此模糊的用詞也無法調和客戶與開發團隊之間的矛盾了。
對此，敏捷聯盟體系則表現的絕不拖泥帶水，非常乾脆的表達：擁抱變更！（當然，也同時給出了各種輔助手段）這個響亮的口號在人們的心智中徹底的解決了上述根本性的問題，人們當然會對此趨之若鶩。
至此，雖然並非每個敏捷方法的理論體系都是完備的（例如極限程式設計就屬於非常側重於工程實踐的技術過程，而SCRUM則明顯是管理過程，所以曾經一度XP+SCRUM變為了標準配置），但是這些已經都不是重點了，大的趨勢一旦形成，無法逆轉。
由此我們需要意識到，在某種情況下，事物的簡單性就是壓倒一切的力量！
我們可以類比一下，J2EE框架 vs Ruby on Rails框架的情形與RUP vs Agile的情形是多麼的類似啊。再早一些，Java其實也是以其簡單性才獲得快速成長的機會的。
事物都是具有兩面性的，在擁抱敏捷軟體開發過程的同時，我們也應該意識到敏捷過程其實也是有一些自身的問題的。並且，即使已經發展了很多年，在開發人員中仍然存在著對敏捷過程的各種誤解。
我希望能在下一篇文章中，專門針對敏捷軟體開發的過程邏輯聊一聊。