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