RUP是敏捷的嗎？

    本文翻譯自Agile Time第二期的Ask The Experts欄目的一部分。文中主要指出一些對RUP或UP的誤解和實踐中的錯誤。Craig Larman是《UML於模式應用》一書的作者，文中的一些觀點在《UML與模式應用》中也有出現。

Ｑ：

我的經理引入了ＲＵＰ，告訴我們使用它，他說RUP是敏捷的，但是對我來說它看起來是瀑布型，能給我一些怎樣繼續下去的建議嗎？

Ａ：

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

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

 

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

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

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

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

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

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

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

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

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

4.       移交：完成beta測試，釋出，部署系統。

陷阱：建立過多的工件

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

 陷阱：像大規模製造業的過程那樣使用RUP

RUP不僅僅定義了一組工件，還包含一組可選的活動，例如整合子系統。很明顯，一個團隊不需要學習很多的細節就能夠決定他們應該採用哪些活動。如果一個人學習，並嘗試在專案中嚴格實行這些可選活動，就像生產一輛汽車的製造過程，就是對RUP的一種濫用。軟體開發是“新產品的開發”，而不是重複的製造，需要靈活性，創造性來應對來自構築軟體的挑戰，不是一張按部就班的處方。

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408753/，如需轉載，請註明出處，否則將追究法律責任。