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其實也是以其簡單性纔得到快速成長的機會的。

事物都是具備兩面性的，在擁抱敏捷軟件開發過程的同時，咱們也應該意識到敏捷過程其實也是有一些自身的問題的。而且，即便已經發展了不少年，在開發人員中仍然存在着對敏捷過程的各類誤解。

我但願能在下一篇文章中，專門針對敏捷軟件開發的過程邏輯聊一聊。