計算機軟件水平考試：RUP是敏捷的嗎？

　�。粒涸诨卮疬@個問題之前，我想簡單說明一下一個人為什么會建議使用ＲＵＰ。簡單說，ＲＵＰ是由一組最佳實踐組成的迭代的和適應性過程，例如迭代開發(fā)和配置管理。進一步說，它是靈活的和面向結果的。在它的主要結構中，采用了很多有用的實踐，諸如DSDM，Evo，Scrum，和XP。同樣的，它也是得到廣泛驗證的流行的迭代方法，上萬個組織采用了它。最后，它提供了通用的軟件開發(fā)詞匯。例如，RUP定義了象版本和風險列表這樣的制品。那些采用了RUP的組織在軟件開發(fā)活動中使用相同的術語，這增進了交流。

　　幾年前，RUP的架構師Philippe Kruchten和我寫了一篇文章《How to fail with RUP:7 step to pain and suffering》，其中總結了一些敏捷－毀滅的缺陷我們看到的RUP的使用者或顧問所陷入的一些缺陷，下面是一些陷阱

　　陷阱：將瀑布模型的概念或階段劃分和RUP相對應。

　　瀑布模型或者順序的生命周期意味著首先嘗試去理解和記錄盡可能多的需求，然后設計規(guī)格說明和模型，然后再構建系統(tǒng)。研究表明瀑布模型是一種高風險和極易失敗的過程。它的作用在過去的10年里被誤傳了。

　　RUP并沒有沿用瀑布模型的順序的開發(fā)周期，相反，它是迭代和不斷改良的過程，就象DSDM，Evo，Scrum，XP一樣。也就是說，我們在快速構建軟件的過程中不斷精化需求和設計。我們快速開始編程，例如,當我們只理解了10％的需求的時候。事實上，RUP提出了6個最佳實踐，第一項就是迭代開發(fā)。一個RUP項目應該以2-6周為一個迭代周期來持續(xù)改進系統(tǒng)。

　　任何一個感覺象“首先要整理出大量的需求”或者“在開始編碼前寫大量的規(guī)格說明書”的RUP項目都是對RUP的濫用，例如：將RUP當作瀑布模型，或者被所謂的專家建議采用連他們自己都不理解的過程。

　　另一種常見的以瀑布模型來看待RUP的想法是錯誤的將瀑布模型的各開發(fā)階段（需求，設計等）和RUP中的開發(fā)階段畫上等號。RUP將每次迭代分為四個更小的階段：初始，細化，構建，移交。對于任何將開始和需求，精化和設計，構建和編碼畫上等號的觀點都是錯誤的。

　　這里不打算對每個階段都作出詳細的說明，只給出一些簡要的說明

　　1. 初始：這一階段，我們開發(fā)系統(tǒng)的版本和商業(yè)用例，發(fā)現一些小的但是很重要的需求，以及關鍵的風險，確定哪些要留到細化階段。在開始階段我們只需要發(fā)現“Top-10”的高級別的需求。通常，這個階段非常短，也許只有幾個小時或幾天，否則將會陷入到瀑布模型的“預先定義”的陷阱中。在初始階段不包括對項目的整體評價，主要是為下面的細化階段定義范圍和目標。

　　2. 細化：迭代地構建核心架構和解決項目的高級別的風險。這里所說的構建核心架構指編程，整合，測試，而不是指“紙上”的練習或者構建將會被拋棄的原型。當我們在并行開發(fā)系統(tǒng)的核心部分同時反復地發(fā)現需求的細節(jié)。在這個階段需求會發(fā)生顯著的變化，經過反饋－適應的過程，變化能夠得到有規(guī)律的評估和實現。注意這和傳統(tǒng)的瀑布模型的需求定義形成鮮明的對比，多數的需求在并行開發(fā)核心架構的時候會被細化，并從實際的開發(fā)中得到大量反饋。例如，在細化階段，每個為期2周的迭代周期內，都有可能有1-2天的時間進行對需求的討論。在一些較大型的項目中，這個迭代周期可能為2-4周。在細化階段的最后，開發(fā)的成果物被提出，這時再決定是否進行構建。

　　3. 構建：迭代地構建在細化階段沒有完成的部分，迭代進行集成，質量評估，并準備部署。需求變更在這一階段會比較少，因為需求在細化階段已經被精練，細化了。

　　4. 移交：完成beta測試，發(fā)布，部署系統(tǒng)。

　　陷阱：創(chuàng)建過多的工件

　　RUP是一個過程的FrameWork，或者說是一組可選的實踐和工件，可以根據項目的實際情況進行裁剪，也就是說“對癥下藥”。在這個前提下，RUP定義了一組大約40個可選工件，例如：版本，風險列表，發(fā)布說明。通常的“過程裁剪”的原則是“越少越好”，而且近可能少得創(chuàng)建工件（兩個或三個）。大多數項目都會從簡短的版本和風險列表中收益，很多的其他工件都可以被忽略掉。而敏捷RUP更提倡盡早開始編碼和創(chuàng)建軟件的基礎部分。

　　陷阱：像大規(guī)模制造業(yè)的過程那樣使用RUP

　　RUP不僅僅定義了一組工件，還包含一組可選的活動，例如整合子系統(tǒng)。很明顯，一個團隊不需要學習很多的細節(jié)就能夠決定他們應該采用哪些活動。如果一個人學習，并嘗試在項目中嚴格實行這些可選活動，就像生產一輛汽車的制造過程，就是對RUP的一種濫用。軟件開發(fā)是“新產品的開發(fā)”，而不是重復的制造，需要靈活性，創(chuàng)造性來應對來自構筑軟件的挑戰(zhàn)，不是一張按部就班的處方。

　　RUP是靈活的，并且鼓勵采用來自于所有軟件開發(fā)方法學中的技術，例如，你可以采用Scrum的實踐中提倡的實行每天的“站立會議”。而不是遵循RUP中的“定義”式的過程。