在這個項目的非常早期的階段，我們能設(shè)計一個階段計劃， 作為在我們的軟件開發(fā)計劃里的一個部分，該計劃概括了每階段的長度和及其迭代，并且為每一個迭代階段制定了嚴(yán)格的時間計劃，包括應(yīng)用軟件的發(fā)布。 （在一項RUP項目里的每個階段可以包含多次迭代。) 我們所不知道的是，什么功能將準(zhǔn)確地在每一個迭代過程中被交付。
在下一個階段——精化階段，我們將關(guān)注在詳細(xì)描述需求上，根據(jù)這些需求來開發(fā)軟件，降低由技術(shù)、計劃和資源帶來的不確定性。隨著我們的精化過程進(jìn)行，我們可以在階段計劃中補(bǔ)充一些細(xì)節(jié)的東西。基于在先前一個迭代階段中學(xué)到的東西，我們能將需要實現(xiàn)的軟件的功能安排到項目的一個個迭代階段。在精化階段的后，項目中的大多數(shù)不確定（危險）會得到減輕，我們能談判做出確定的關(guān)于軟件功能范圍的承諾。 如果我們已經(jīng)采取有規(guī)律的版本式方法來開發(fā)我們的應(yīng)用程序，功能范圍的協(xié)商會容易得多，因為我們總能在未來某一個版本中完成所要求的功能。
根據(jù)精化階段制定的詳細(xì)的程序功能范圍，我們可以進(jìn)入開發(fā)階段。此時，我們的重點轉(zhuǎn)移到根據(jù)經(jīng)過校訂的關(guān)于功能范圍的合約，開發(fā)剩下的功能。現(xiàn)在我們該對我們的能力感到滿意，因為我們能做到根據(jù)在項目先啟階段制定的時間表來完成所需要功能的開發(fā)。
通過協(xié)作改進(jìn)需求
要成功地使用RUP需要在項目研究團(tuán)隊和相關(guān)利益方之間形成一種新的合作關(guān)系。過去，IT界已經(jīng)提出了，向商業(yè)相關(guān)利益方正確定義需求存在一定風(fēng)險，但是還是假設(shè)交付軟件的風(fēng)險取決于這些需求。 IT界會讓用戶簽訂一份文檔，然后來控制這些需求的變化，從而達(dá)到管理這些風(fēng)險的目的。 IT界會由于這些變化向用戶收費，然后根據(jù)這些變化相應(yīng)增加事先的估計，從而得以修改時間計劃和 超額的支出，從而聲稱項目依然準(zhǔn)時而且不超支。這種行為會在相關(guān)利益方和IT界之間引發(fā)猜疑，導(dǎo)致彼此感覺不舒服。
另外一種合作的方法會大大優(yōu)于上述的方法。相關(guān)利益方和項目研究團(tuán)隊在事先都清楚認(rèn)識到，在項目一開始完全正確地定義需求事實上是不可能的。因此讓項目研究團(tuán)隊按照預(yù)算和時間計劃下執(zhí)行任務(wù)也是不可能的，因為這個預(yù)算和時間計劃本基于不確定的需求、資源和技術(shù)。
采用了“RUP精神”的項目中，相關(guān)利益方和項目研究團(tuán)隊成員清楚，隨著他們了解更多，需求可以而且應(yīng)當(dāng)變化和改進(jìn)。在項目研究團(tuán)隊排除項目中大多數(shù)不確定因素之前做精確的計劃是不明智的。項目管理者必須盡快地說明那些不確定因素，這樣負(fù)責(zé)實現(xiàn)的團(tuán)隊能夠根據(jù)需要實現(xiàn)的功能的范圍來確定軟件功能。
團(tuán)隊經(jīng)常會問：“精化階段應(yīng)該持續(xù)多久？”答案是，讓這段時間足夠長，從而項目研究組能降低已知的風(fēng)險，項目管理者可以根據(jù)這個項目的時間安排、支出和功能范圍來做出明確的說明。在一個典型的項目中，這個階段意味著開發(fā)百分之二十的功能，或者足以證明整個框架能夠支持所有的需求。
在精化階段的后，當(dāng)研究團(tuán)隊已經(jīng)將和進(jìn)度、功能、技術(shù)和資源相關(guān)的大部分不確定性消除之后，他們可以列出需求，同時把將來需求的變化納入正常的變更控制過程中。
將維護(hù)人員調(diào)入開發(fā)團(tuán)隊
很多組織將新程序開發(fā)和現(xiàn)有程序維護(hù)區(qū)別對待。通常來說，他們會外請顧問來根據(jù)新的技術(shù)建立新的程序，但是一旦這項程序開發(fā)部署完畢，他們會將該程序應(yīng)用交付給內(nèi)部維護(hù)人員支持。這會讓工作人員失去動力。來維護(hù)一個別人建立的應(yīng)用程序，對工作人員來說不會太滿意，尤其是當(dāng)這些維護(hù)人員還很少和新技術(shù)接觸的情況下。同樣，在不知道先前的開發(fā)基于何種決策的情況下，要有效地維持一個應(yīng)用程序也非常困難。如果你應(yīng)用了這種方法，你必須給維護(hù)人員提供足夠的材料，這將會增加系統(tǒng)的開銷。
在迭代化開發(fā)環(huán)境中，將維護(hù)人員調(diào)到開發(fā)隊伍中，讓他們同時負(fù)責(zé)維護(hù)現(xiàn)有版本以及為未來的新版本開發(fā)新功能，更有意義了。這促使團(tuán)隊始終關(guān)注系統(tǒng)的商業(yè)目標(biāo)和特色，使得團(tuán)隊成員能夠幫助完善這個商業(yè)目標(biāo)和特色。終，這種方法將帶來一個更高效更愉快的開發(fā)隊伍，同時也會減少文檔負(fù)擔(dān)。
問合適的問題，并要求增加的功能演示
迭代化開發(fā)方法會如何影響指導(dǎo)委員會管理與項目管理者會晤的方法呢？首先，管理者必須確認(rèn)委員會了解在整個RUP各個階段中項目會如何變化。只有這樣委員會才能夠問出有意義的問題，在不同階段中調(diào)整提供的資金水平。比如，在精化過程中，他們應(yīng)該問項目管理者索取定時更新的風(fēng)險列表，從而能確認(rèn)這些風(fēng)險是否在該階段后過程被消除。
在一個項目先啟階段中，應(yīng)集中關(guān)注于降低風(fēng)險和不確定因素，這是使用RUP優(yōu)于使用其他迭代化方法的重要優(yōu)勢。在開發(fā)軟件的精化階段中，如果使用降低風(fēng)險的方法，發(fā)現(xiàn)大的不確定性是十分必要的。很多風(fēng)險與構(gòu)架關(guān)系有關(guān)。盡管客戶相關(guān)利益方可能會給開發(fā)團(tuán)隊施加壓力，要求先建立他們所認(rèn)為的重要的功能，在精化階段還是要根據(jù)結(jié)構(gòu)而不是客戶來設(shè)置優(yōu)先級。指導(dǎo)委員會必須知道這些。在精化過程的后，當(dāng)大的不確定性已經(jīng)被解決，項目也將進(jìn)入開發(fā)建設(shè)階段，這時候優(yōu)先級設(shè)置可以多考慮以用戶需求為驅(qū)動。
在有些情況下，先完成主要功能的構(gòu)建，來降低和需求相關(guān)的風(fēng)險以及工作流中的不確定性，可能是有意義的。然而，如果這種功能是很直接的而且并不和一些很明顯的不確定性相關(guān)，開發(fā)團(tuán)隊可以將該功能的開發(fā)推遲到構(gòu)建階段進(jìn)行。記住：我們的目標(biāo)是盡快完成精化階段，這樣我們能給相關(guān)利益方確切的承諾，轉(zhuǎn)入開發(fā)構(gòu)建階段。
指導(dǎo)委員會應(yīng)當(dāng)也需要基于一個已基線化的架構(gòu)，驗證關(guān)鍵用例場景（使用真的可以運行的軟件而不是模型�。� 事實上，他們可能會考慮在他們的會議間放上投影機(jī)來使得軟件演示更順暢。這和傳統(tǒng)的瀑布式方法有著根本的不同。指導(dǎo)委員會通常只有在整個應(yīng)用程序即將投入使用的時候，看到demo版本而不是看到一個功能型的演示版本。另外，他們通常用甘特圖來衡量整個項目的進(jìn)程，在甘特圖上會顯示已經(jīng)完成了33％尚未完成66％，諸如此類�；蛘撸麄儠䥺柟芾碚呤欠褚呀�(jīng)簽訂了需求和設(shè)計文檔。首先，而且也是重要的是，項目管理者需要教育指導(dǎo)委員會成員，如何來衡量進(jìn)度：的有效方法是看能夠工作的軟件而不是簽訂的文檔。
