在這個(gè)項(xiàng)目的非常早期的階段，我們能設(shè)計(jì)一個(gè)階段計(jì)劃， 作為在我們的軟件開發(fā)計(jì)劃里的一個(gè)部分，該計(jì)劃概括了每階段的長(zhǎng)度和及其迭代，并且為每一個(gè)迭代階段制定了嚴(yán)格的時(shí)間計(jì)劃，包括應(yīng)用軟件的發(fā)布。 （在一項(xiàng)RUP項(xiàng)目里的每個(gè)階段可以包含多次迭代。) 我們所不知道的是，什么功能將準(zhǔn)確地在每一個(gè)迭代過程中被交付。

在下一個(gè)階段——精化階段，我們將關(guān)注在詳細(xì)描述需求上，根據(jù)這些需求來開發(fā)軟件，降低由技術(shù)、計(jì)劃和資源帶來的不確定性。隨著我們的精化過程進(jìn)行，我們可以在階段計(jì)劃中補(bǔ)充一些細(xì)節(jié)的東西�；�于在先前一個(gè)迭代階段中學(xué)到的東西，我們能將需要實(shí)現(xiàn)的軟件的功能安排到項(xiàng)目的一個(gè)個(gè)迭代階段。在精化階段的后，項(xiàng)目中的大多數(shù)不確定（危險(xiǎn)）會(huì)得到減輕，我們能談判做出確定的關(guān)于軟件功能范圍的承諾。 如果我們已經(jīng)采取有規(guī)律的版本式方法來開發(fā)我們的應(yīng)用程序，功能范圍的協(xié)商會(huì)容易得多，因?yàn)槲覀兛偰茉谖磥砟骋粋�(gè)版本中完成所要求的功能。

根據(jù)精化階段制定的詳細(xì)的程序功能范圍，我們可以進(jìn)入開發(fā)階段。此時(shí)，我們的重點(diǎn)轉(zhuǎn)移到根據(jù)經(jīng)過校訂的關(guān)于功能范圍的合約，開發(fā)剩下的功能。現(xiàn)在我們?cè)搶?duì)我們的能力感到滿意，因?yàn)槲覀兡茏龅礁鶕?jù)在項(xiàng)目先啟階段制定的時(shí)間表來完成所需要功能的開發(fā)。
通過協(xié)作改進(jìn)需求

要成功地使用RUP需要在項(xiàng)目研究團(tuán)隊(duì)和相關(guān)利益方之間形成一種新的合作關(guān)系。過去，IT界已經(jīng)提出了，向商業(yè)相關(guān)利益方正確定義需求存在一定風(fēng)險(xiǎn)，但是還是假設(shè)交付軟件的風(fēng)險(xiǎn)取決于這些需求。 IT界會(huì)讓用戶簽訂一份文檔，然后來控制這些需求的變化，從而達(dá)到管理這些風(fēng)險(xiǎn)的目的。 IT界會(huì)由于這些變化向用戶收費(fèi)，然后根據(jù)這些變化相應(yīng)增加事先的估計(jì)，從而得以修改時(shí)間計(jì)劃和 超額的支出，從而聲稱項(xiàng)目依然準(zhǔn)時(shí)而且不超支。這種行為會(huì)在相關(guān)利益方和IT界之間引發(fā)猜疑，導(dǎo)致彼此感覺不舒服。

另外一種合作的方法會(huì)大大優(yōu)于上述的方法。相關(guān)利益方和項(xiàng)目研究團(tuán)隊(duì)在事先都清楚認(rèn)識(shí)到，在項(xiàng)目一開始完全正確地定義需求事實(shí)上是不可能的。因此讓項(xiàng)目研究團(tuán)隊(duì)按照預(yù)算和時(shí)間計(jì)劃下執(zhí)行任務(wù)也是不可能的，因?yàn)檫@個(gè)預(yù)算和時(shí)間計(jì)劃本基于不確定的需求、資源和技術(shù)。

采用了“RUP精神”的項(xiàng)目中，相關(guān)利益方和項(xiàng)目研究團(tuán)隊(duì)成員清楚，隨著他們了解更多，需求可以而且應(yīng)當(dāng)變化和改進(jìn)。在項(xiàng)目研究團(tuán)隊(duì)排除項(xiàng)目中大多數(shù)不確定因素之前做精確的計(jì)劃是不明智的。項(xiàng)目管理者必須盡快地說明那些不確定因素，這樣負(fù)責(zé)實(shí)現(xiàn)的團(tuán)隊(duì)能夠根據(jù)需要實(shí)現(xiàn)的功能的范圍來確定軟件功能。

團(tuán)隊(duì)經(jīng)常會(huì)問：“精化階段應(yīng)該持續(xù)多久？”答案是，讓這段時(shí)間足夠長(zhǎng)，從而項(xiàng)目研究組能降低已知的風(fēng)險(xiǎn)，項(xiàng)目管理者可以根據(jù)這個(gè)項(xiàng)目的時(shí)間安排、支出和功能范圍來做出明確的說明。在一個(gè)典型的項(xiàng)目中，這個(gè)階段意味著開發(fā)百分之二十的功能，或者足以證明整個(gè)框架能夠支持所有的需求。

在精化階段的后，當(dāng)研究團(tuán)隊(duì)已經(jīng)將和進(jìn)度、功能、技術(shù)和資源相關(guān)的大部分不確定性消除之后，他們可以列出需求，同時(shí)把將來需求的變化納入正常的變更控制過程中。
將維護(hù)人員調(diào)入開發(fā)團(tuán)隊(duì)

很多組織將新程序開發(fā)和現(xiàn)有程序維護(hù)區(qū)別對(duì)待。通常來說，他們會(huì)外請(qǐng)顧問來根據(jù)新的技術(shù)建立新的程序，但是一旦這項(xiàng)程序開發(fā)部署完畢，他們會(huì)將該程序應(yīng)用交付給內(nèi)部維護(hù)人員支持。這會(huì)讓工作人員失去動(dòng)力。來維護(hù)一個(gè)別人建立的應(yīng)用程序，對(duì)工作人員來說不會(huì)太滿意，尤其是當(dāng)這些維護(hù)人員還很少和新技術(shù)接觸的情況下。同樣，在不知道先前的開發(fā)基于何種決策的情況下，要有效地維持一個(gè)應(yīng)用程序也非常困難。如果你應(yīng)用了這種方法，你必須給維護(hù)人員提供足夠的材料，這將會(huì)增加系統(tǒng)的開銷。

在迭代化開發(fā)環(huán)境中，將維護(hù)人員調(diào)到開發(fā)隊(duì)伍中，讓他們同時(shí)負(fù)責(zé)維護(hù)現(xiàn)有版本以及為未來的新版本開發(fā)新功能，更有意義了。這促使團(tuán)隊(duì)始終關(guān)注系統(tǒng)的商業(yè)目標(biāo)和特色，使得團(tuán)隊(duì)成員能夠幫助完善這個(gè)商業(yè)目標(biāo)和特色。終，這種方法將帶來一個(gè)更高效更愉快的開發(fā)隊(duì)伍，同時(shí)也會(huì)減少文檔負(fù)擔(dān)。
問合適的問題，并要求增加的功能演示

迭代化開發(fā)方法會(huì)如何影響指導(dǎo)委員會(huì)管理與項(xiàng)目管理者會(huì)晤的方法呢？首先，管理者必須確認(rèn)委員會(huì)了解在整個(gè)RUP各個(gè)階段中項(xiàng)目會(huì)如何變化。只有這樣委員會(huì)才能夠問出有意義的問題，在不同階段中調(diào)整提供的資金水平。比如，在精化過程中，他們應(yīng)該問項(xiàng)目管理者索取定時(shí)更新的風(fēng)險(xiǎn)列表，從而能確認(rèn)這些風(fēng)險(xiǎn)是否在該階段后過程被消除。

在一個(gè)項(xiàng)目先啟階段中，應(yīng)集中關(guān)注于降低風(fēng)險(xiǎn)和不確定因素，這是使用RUP優(yōu)于使用其他迭代化方法的重要優(yōu)勢(shì)。在開發(fā)軟件的精化階段中，如果使用降低風(fēng)險(xiǎn)的方法，發(fā)現(xiàn)大的不確定性是十分必要的。很多風(fēng)險(xiǎn)與構(gòu)架關(guān)系有關(guān)。盡管客戶相關(guān)利益方可能會(huì)給開發(fā)團(tuán)隊(duì)施加壓力，要求先建立他們所認(rèn)為的重要的功能，在精化階段還是要根據(jù)結(jié)構(gòu)而不是客戶來設(shè)置優(yōu)先級(jí)。指導(dǎo)委員會(huì)必須知道這些。在精化過程的后，當(dāng)大的不確定性已經(jīng)被解決，項(xiàng)目也將進(jìn)入開發(fā)建設(shè)階段，這時(shí)候優(yōu)先級(jí)設(shè)置可以多考慮以用戶需求為驅(qū)動(dòng)。

在有些情況下，先完成主要功能的構(gòu)建，來降低和需求相關(guān)的風(fēng)險(xiǎn)以及工作流中的不確定性，可能是有意義的。然而，如果這種功能是很直接的而且并不和一些很明顯的不確定性相關(guān)，開發(fā)團(tuán)隊(duì)可以將該功能的開發(fā)推遲到構(gòu)建階段進(jìn)行。記�。何覀兊哪繕�(biāo)是盡快完成精化階段，這樣我們能給相關(guān)利益方確切的承諾，轉(zhuǎn)入開發(fā)構(gòu)建階段。

指導(dǎo)委員會(huì)應(yīng)當(dāng)也需要基于一個(gè)已基線化的架構(gòu)，驗(yàn)證關(guān)鍵用例場(chǎng)景（使用真的可以運(yùn)行的軟件而不是模型�。�。 事實(shí)上，他們可能會(huì)考慮在他們的會(huì)議間放上投影機(jī)來使得軟件演示更順暢。這和傳統(tǒng)的瀑布式方法有著根本的不同。指導(dǎo)委員會(huì)通常只有在整個(gè)應(yīng)用程序即將投入使用的時(shí)候，看到demo版本而不是看到一個(gè)功能型的演示版本。另外，他們通常用甘特圖來衡量整個(gè)項(xiàng)目的進(jìn)程，在甘特圖上會(huì)顯示已經(jīng)完成了33％尚未完成66％，諸如此類�；蛘�，他們會(huì)問管理者是否已經(jīng)簽訂了需求和設(shè)計(jì)文檔。首先，而且也是重要的是，項(xiàng)目管理者需要教育指導(dǎo)委員會(huì)成員，如何來衡量進(jìn)度：的有效方法是看能夠工作的軟件而不是簽訂的文檔。