Ｑ：我的經(jīng)理引入了ＲＵＰ，告訴我們使用它，他說RUP是敏捷的，但是對我來說它看起來是瀑布型，能給我一些怎樣繼續(xù)下去的建議嗎？
Ａ：在回答這個問題之前，我想簡單說明一下一個人為什么會建議使用ＲＵＰ。簡單說，ＲＵＰ是由一組實踐組成的迭代的和適應(yīng)性過程，例如迭代開發(fā)和配置管理。進(jìn)一步說，它是靈活的和面向結(jié)果的。在它的主要結(jié)構(gòu)中，采用了很多有用的實踐，諸如DSDM，Evo，Scrum，和XP。同樣的，它也是得到廣泛驗證的流行的迭代方法，上萬個組織采用了它。最后，它提供了通用的軟件開發(fā)詞匯。例如，RUP定義了象版本和風(fēng)險列表這樣的制品。那些采用了RUP的組織在軟件開發(fā)活動中使用相同的術(shù)語，這增進(jìn)了交流。
幾年前，RUP的架構(gòu)師Philippe Kruchten和我寫了一篇文章《How to fail with RUP:7 step to pain and suffering》，其中總結(jié)了一些敏捷－毀滅的缺陷我們看到的RUP的使用者或顧問所陷入的一些缺陷，下面是一些陷阱：
陷阱：將瀑布模型的概念或階段劃分和RUP相對應(yīng)。
瀑布模型或者順序的生命周期意味著首先嘗試去理解和記錄盡可能多的需求，然后設(shè)計規(guī)格說明和模型，然后再構(gòu)建系統(tǒng)。研究表明瀑布模型是一種高風(fēng)險和極易失敗的過程。它的作用在過去的10年里被誤傳了。
RUP并沒有沿用瀑布模型的順序的開發(fā)周期，相反，它是迭代和不斷改良的過程，就象DSDM，Evo，Scrum，XP一樣。也就是說，我們在快速構(gòu)建軟件的過程中不斷精化需求和設(shè)計。我們快速開始編程，例如,當(dāng)我們只理解了10％的需求的時候。事實上，RUP提出了6個實踐，第一項就是迭代開發(fā)。一個RUP項目應(yīng)該以2-6周為一個迭代周期來持續(xù)改進(jìn)系統(tǒng)。
任何一個感覺象“首先要整理出大量的需求”或者“在開始編碼前寫大量的規(guī)格說明書”的RUP項目都是對RUP的濫用，例如：將RUP當(dāng)作瀑布模型，或者被所謂的專家建議采用連他們自己都不理解的過程。
另一種常見的以瀑布模型來看待RUP的想法是錯誤的將瀑布模型的各開發(fā)階段（需求，設(shè)計等）和RUP中的開發(fā)階段畫上等號。RUP將每次迭代分為四個更小的階段：初始，細(xì)化，構(gòu)建，移交。對于任何將開始和需求，精化和設(shè)計，構(gòu)建和編碼畫上等號的觀點都是錯誤的。
這里不打算對每個階段都作出詳細(xì)的說明，只給出一些簡要的說明：
1. 初始：這一階段，我們開發(fā)系統(tǒng)的版本和商業(yè)用例，發(fā)現(xiàn)一些小的但是很重要的需求，以及關(guān)鍵的風(fēng)險，確定哪些要留到細(xì)化階段。在開始階段我們只需要發(fā)現(xiàn)“Top-10”的高級別的需求。通常，這個階段非常短，也許只有幾個小時或幾天，否則將會陷入到瀑布模型的“預(yù)先定義”的陷阱中。在初始階段不包括對項目的整體評價，主要是為下面的細(xì)化階段定義范圍和目標(biāo)。
2. 細(xì)化：迭代地構(gòu)建核心架構(gòu)和解決項目的高級別的風(fēng)險。這里所說的構(gòu)建核心架構(gòu)指編程，整合，測試，而不是指“紙上”的練習(xí)或者構(gòu)建將會被拋棄的原型。當(dāng)我們在并行開發(fā)系統(tǒng)的核心部分同時反復(fù)地發(fā)現(xiàn)需求的細(xì)節(jié)。在這個階段需求會發(fā)生顯著的變化，經(jīng)過反饋－適應(yīng)的過程，變化能夠得到有規(guī)律的評估和實現(xiàn)。注意這和傳統(tǒng)的瀑布模型的需求定義形成鮮明的對比，多數(shù)的需求在并行開發(fā)核心架構(gòu)的時候會被細(xì)化，并從實際的開發(fā)中得到大量反饋。例如，在細(xì)化階段，每個為期2周的迭代周期內(nèi)，都有可能有1-2天的時間進(jìn)行對需求的討論。在一些較大型的項目中，這個迭代周期可能為2-4周。在細(xì)化階段的最后，開發(fā)的成果物被提出，這時再決定是否進(jìn)行構(gòu)建。
3. 構(gòu)建：迭代地構(gòu)建在細(xì)化階段沒有完成的部分，迭代進(jìn)行集成，質(zhì)量評估，并準(zhǔn)備部署。需求變更在這一階段會比較少，因為需求在細(xì)化階段已經(jīng)被精練，細(xì)化了。
4. 移交：完成beta測試，發(fā)布，部署系統(tǒng)。
陷阱：創(chuàng)建過多的工件
RUP是一個過程的FrameWork，或者說是一組可選的實踐和工件，可以根據(jù)項目的實際情況進(jìn)行裁剪，也就是說“對癥下藥”。在這個前提下，RUP定義了一組大約40個可選工件，例如：版本，風(fēng)險列表，發(fā)布說明。通常的“過程裁剪”的原則是“越少越好”，而且近可能少得創(chuàng)建工件（兩個或三個）。大多數(shù)項目都會從簡短的版本和風(fēng)險列表中收益，很多的其他工件都可以被忽略掉。而敏捷RUP更提倡盡早開始編碼和創(chuàng)建軟件的基礎(chǔ)部分。
陷阱：像大規(guī)模制造業(yè)的過程那樣使用RUP
RUP不僅僅定義了一組工件，還包含一組可選的活動，例如整合子系統(tǒng)。很明顯，一個團(tuán)隊不需要學(xué)習(xí)很多的細(xì)節(jié)就能夠決定他們應(yīng)該采用哪些活動。如果一個人學(xué)習(xí)，并嘗試在項目中嚴(yán)格實行這些可選活動，就像生產(chǎn)一輛汽車的制造過程，就是對RUP的一種濫用。軟件開發(fā)是“新產(chǎn)品的開發(fā)”，而不是重復(fù)的制造，需要靈活性，創(chuàng)造性來應(yīng)對來自構(gòu)筑軟件的挑戰(zhàn)，不是一張按部就班的處方。
RUP是靈活的，并且鼓勵采用來自于所有軟件開發(fā)方法學(xué)中的技術(shù)，例如，你可以采用Scrum的實踐中提倡的實行每天的“站立會議”。而不是遵循RUP中的“定義”式的過程。
Ａ：在回答這個問題之前，我想簡單說明一下一個人為什么會建議使用ＲＵＰ。簡單說，ＲＵＰ是由一組實踐組成的迭代的和適應(yīng)性過程，例如迭代開發(fā)和配置管理。進(jìn)一步說，它是靈活的和面向結(jié)果的。在它的主要結(jié)構(gòu)中，采用了很多有用的實踐，諸如DSDM，Evo，Scrum，和XP。同樣的，它也是得到廣泛驗證的流行的迭代方法，上萬個組織采用了它。最后，它提供了通用的軟件開發(fā)詞匯。例如，RUP定義了象版本和風(fēng)險列表這樣的制品。那些采用了RUP的組織在軟件開發(fā)活動中使用相同的術(shù)語，這增進(jìn)了交流。
幾年前，RUP的架構(gòu)師Philippe Kruchten和我寫了一篇文章《How to fail with RUP:7 step to pain and suffering》，其中總結(jié)了一些敏捷－毀滅的缺陷我們看到的RUP的使用者或顧問所陷入的一些缺陷，下面是一些陷阱：
陷阱：將瀑布模型的概念或階段劃分和RUP相對應(yīng)。
瀑布模型或者順序的生命周期意味著首先嘗試去理解和記錄盡可能多的需求，然后設(shè)計規(guī)格說明和模型，然后再構(gòu)建系統(tǒng)。研究表明瀑布模型是一種高風(fēng)險和極易失敗的過程。它的作用在過去的10年里被誤傳了。
RUP并沒有沿用瀑布模型的順序的開發(fā)周期，相反，它是迭代和不斷改良的過程，就象DSDM，Evo，Scrum，XP一樣。也就是說，我們在快速構(gòu)建軟件的過程中不斷精化需求和設(shè)計。我們快速開始編程，例如,當(dāng)我們只理解了10％的需求的時候。事實上，RUP提出了6個實踐，第一項就是迭代開發(fā)。一個RUP項目應(yīng)該以2-6周為一個迭代周期來持續(xù)改進(jìn)系統(tǒng)。
任何一個感覺象“首先要整理出大量的需求”或者“在開始編碼前寫大量的規(guī)格說明書”的RUP項目都是對RUP的濫用，例如：將RUP當(dāng)作瀑布模型，或者被所謂的專家建議采用連他們自己都不理解的過程。
另一種常見的以瀑布模型來看待RUP的想法是錯誤的將瀑布模型的各開發(fā)階段（需求，設(shè)計等）和RUP中的開發(fā)階段畫上等號。RUP將每次迭代分為四個更小的階段：初始，細(xì)化，構(gòu)建，移交。對于任何將開始和需求，精化和設(shè)計，構(gòu)建和編碼畫上等號的觀點都是錯誤的。
這里不打算對每個階段都作出詳細(xì)的說明，只給出一些簡要的說明：
1. 初始：這一階段，我們開發(fā)系統(tǒng)的版本和商業(yè)用例，發(fā)現(xiàn)一些小的但是很重要的需求，以及關(guān)鍵的風(fēng)險，確定哪些要留到細(xì)化階段。在開始階段我們只需要發(fā)現(xiàn)“Top-10”的高級別的需求。通常，這個階段非常短，也許只有幾個小時或幾天，否則將會陷入到瀑布模型的“預(yù)先定義”的陷阱中。在初始階段不包括對項目的整體評價，主要是為下面的細(xì)化階段定義范圍和目標(biāo)。
2. 細(xì)化：迭代地構(gòu)建核心架構(gòu)和解決項目的高級別的風(fēng)險。這里所說的構(gòu)建核心架構(gòu)指編程，整合，測試，而不是指“紙上”的練習(xí)或者構(gòu)建將會被拋棄的原型。當(dāng)我們在并行開發(fā)系統(tǒng)的核心部分同時反復(fù)地發(fā)現(xiàn)需求的細(xì)節(jié)。在這個階段需求會發(fā)生顯著的變化，經(jīng)過反饋－適應(yīng)的過程，變化能夠得到有規(guī)律的評估和實現(xiàn)。注意這和傳統(tǒng)的瀑布模型的需求定義形成鮮明的對比，多數(shù)的需求在并行開發(fā)核心架構(gòu)的時候會被細(xì)化，并從實際的開發(fā)中得到大量反饋。例如，在細(xì)化階段，每個為期2周的迭代周期內(nèi)，都有可能有1-2天的時間進(jìn)行對需求的討論。在一些較大型的項目中，這個迭代周期可能為2-4周。在細(xì)化階段的最后，開發(fā)的成果物被提出，這時再決定是否進(jìn)行構(gòu)建。
3. 構(gòu)建：迭代地構(gòu)建在細(xì)化階段沒有完成的部分，迭代進(jìn)行集成，質(zhì)量評估，并準(zhǔn)備部署。需求變更在這一階段會比較少，因為需求在細(xì)化階段已經(jīng)被精練，細(xì)化了。
4. 移交：完成beta測試，發(fā)布，部署系統(tǒng)。
陷阱：創(chuàng)建過多的工件
RUP是一個過程的FrameWork，或者說是一組可選的實踐和工件，可以根據(jù)項目的實際情況進(jìn)行裁剪，也就是說“對癥下藥”。在這個前提下，RUP定義了一組大約40個可選工件，例如：版本，風(fēng)險列表，發(fā)布說明。通常的“過程裁剪”的原則是“越少越好”，而且近可能少得創(chuàng)建工件（兩個或三個）。大多數(shù)項目都會從簡短的版本和風(fēng)險列表中收益，很多的其他工件都可以被忽略掉。而敏捷RUP更提倡盡早開始編碼和創(chuàng)建軟件的基礎(chǔ)部分。
陷阱：像大規(guī)模制造業(yè)的過程那樣使用RUP
RUP不僅僅定義了一組工件，還包含一組可選的活動，例如整合子系統(tǒng)。很明顯，一個團(tuán)隊不需要學(xué)習(xí)很多的細(xì)節(jié)就能夠決定他們應(yīng)該采用哪些活動。如果一個人學(xué)習(xí)，并嘗試在項目中嚴(yán)格實行這些可選活動，就像生產(chǎn)一輛汽車的制造過程，就是對RUP的一種濫用。軟件開發(fā)是“新產(chǎn)品的開發(fā)”，而不是重復(fù)的制造，需要靈活性，創(chuàng)造性來應(yīng)對來自構(gòu)筑軟件的挑戰(zhàn)，不是一張按部就班的處方。
RUP是靈活的，并且鼓勵采用來自于所有軟件開發(fā)方法學(xué)中的技術(shù)，例如，你可以采用Scrum的實踐中提倡的實行每天的“站立會議”。而不是遵循RUP中的“定義”式的過程。