指導(dǎo)委員會(huì)應(yīng)該在整個(gè)項(xiàng)目生命周期的早期開始關(guān)心項(xiàng)目的質(zhì)量問(wèn)題。我們不能僅僅根據(jù)已經(jīng)完成的項(xiàng)目來(lái)衡量項(xiàng)目的進(jìn)展，這樣當(dāng)我們發(fā)現(xiàn)質(zhì)量差的時(shí)候已經(jīng)太晚了，這是我們低估了檢測(cè)需要付出的努力。在可迭代化方法中，我們很早有次品率的指標(biāo)，也很早要求投入精力來(lái)進(jìn)行檢測(cè)，但是管理委員會(huì)可能不知道需要在整個(gè)項(xiàng)目的早期開始費(fèi)心問(wèn)一些有關(guān)質(zhì)量的問(wèn)題。因此，初級(jí)的RUP項(xiàng)目管理者可能不能遵從RUP的指導(dǎo)方針，在一開始的時(shí)候不能全面地檢測(cè)。但是不幸的是，很多這樣的管理者聲稱他們?cè)谟肦UP管理項(xiàng)目，但是他們其實(shí)還是在采用瀑布式技術(shù)。通常來(lái)說(shuō)，他們會(huì)將他們的任務(wù)計(jì)劃按照RUP方法組織階段分類，尤其是在測(cè)試領(lǐng)域。指導(dǎo)委員會(huì)必須檢查確認(rèn)項(xiàng)目管理者在項(xiàng)目開展的早期有測(cè)試者，并且給測(cè)試者分配好任務(wù)檢查使用情景下的任務(wù)執(zhí)行情況。
總之，委員會(huì)應(yīng)該對(duì)項(xiàng)目組做出以下的要求：
使用演示版本展示項(xiàng)目進(jìn)度：
你完成了多少用例場(chǎng)景?
在這次迭代過(guò)程中你完成了什么功能?
在下一次迭代過(guò)程中你將創(chuàng)建什么功能?
說(shuō)明你已經(jīng)完成的系統(tǒng)的質(zhì)量：
缺陷數(shù)是多少，并且這些缺陷的嚴(yán)重級(jí)別是什么？
缺陷趨勢(shì)是怎樣的？（發(fā)現(xiàn)率和解決率）
消除不必要的關(guān)閉
將RUP引入傳統(tǒng)的瀑布式環(huán)境一個(gè)富有挑戰(zhàn)性的方面是：它對(duì)于結(jié)束的依賴性大大降低。人們只有在確保文檔是完整和準(zhǔn)確的情況下才會(huì)結(jié)束文檔。因此，他們總是傾向于坐等而耽誤了決策，這會(huì)推遲決策，從而減慢項(xiàng)目的進(jìn)程，浪費(fèi)經(jīng)費(fèi)。作為新的選擇，RUP承認(rèn)我們從過(guò)去的經(jīng)驗(yàn)中得到的知識(shí)：在任何情況下文檔都不可能完整和精確。因此RUP指導(dǎo)方針鼓勵(lì)我們接受這樣的現(xiàn)實(shí)：所有事情都會(huì)改變，都會(huì)往前走。.
軟件開發(fā)界流行的名言是：你付出的努力的20%用以完成你80%的工作。因此這意味著你需要付出你80%的努力來(lái)完成剩下的20%的工作。很符合邏輯推論的結(jié)論是：在項(xiàng)目的迭代過(guò)程中，好先做完那80%的工作，然后再完成那剩下的20%。敏捷的迭代開發(fā)都和追求“足夠好”有關(guān)，你會(huì)在你的工作中繼續(xù)改進(jìn)你的產(chǎn)品。相關(guān)利益方和項(xiàng)目開發(fā)組連續(xù)的日常協(xié)作保證項(xiàng)目的進(jìn)展而言，是一個(gè)比間歇生產(chǎn)和關(guān)閉正式文檔方法好得多的方法。
然而，對(duì)于重要的項(xiàng)目工件，我還是會(huì)要求正式關(guān)閉的文檔，比如在先啟階段結(jié)束時(shí)的遠(yuǎn)景文檔和軟件開發(fā)計(jì)劃，還有在精化階段結(jié)束時(shí)。通常，當(dāng)項(xiàng)目組對(duì)整個(gè)需求有更進(jìn)一步理解的時(shí)候，在精化階段的結(jié)束會(huì)產(chǎn)生重大的變更。盡管我傾向于調(diào)整范圍維持預(yù)算和計(jì)劃，但是有時(shí)重新規(guī)劃剩下的迭代開發(fā)階段是很有意義的，尤其是在你不能夠降低功能范圍，或者在項(xiàng)目還存在著交付功能的不確定性而引入另一個(gè)精化階段的迭代的情況下。
不斷調(diào)整計(jì)劃和期望
我經(jīng)常說(shuō)管理一個(gè)瀑布式的或者傳統(tǒng)的項(xiàng)目，在項(xiàng)目的前80%非常直接而有趣，在那段時(shí)間內(nèi)，任務(wù)是線性的，在一段時(shí)間內(nèi)你可以集中注意于一項(xiàng)規(guī)則（比如需求）. 然而當(dāng)集成和測(cè)試開始的時(shí)候，你會(huì)經(jīng)常發(fā)現(xiàn)不是模版不能整合，測(cè)試很費(fèi)勁，系統(tǒng)架構(gòu)有缺陷，執(zhí)行效果很差，是用戶提出這個(gè)應(yīng)用不是他們所需要的。如果你在管理一個(gè)瀑布型的項(xiàng)目，你在項(xiàng)目臨近結(jié)束的時(shí)候，需要找一個(gè)借口將這個(gè)項(xiàng)目轉(zhuǎn)交給另一個(gè)可憐人。
管理一個(gè)RUP項(xiàng)目在開始的階段會(huì)更有些挑戰(zhàn)性，因?yàn)槲覀兺瑫r(shí)考慮各種條件約束，包括需求、編程以及測(cè)試。然而在接下來(lái)的階段，非正式溝通和良好的生命周期管理工具支持會(huì)使得項(xiàng)目的復(fù)雜性容易管理得多。
對(duì)一個(gè)RUP項(xiàng)目管理者來(lái)說(shuō)困難的階段是精化過(guò)程的末期。這時(shí)候他們會(huì)發(fā)現(xiàn)范圍、預(yù)算以及時(shí)間計(jì)劃沒有意義。這時(shí)候他們不得不做出很艱難的決定，可能還需要重新規(guī)劃整個(gè)項(xiàng)目的一部分。但是這也有好的一方面，這發(fā)生在項(xiàng)目的先啟階段，這時(shí)候能讓相關(guān)利益方調(diào)整他們的期望。
在整個(gè)項(xiàng)目的后，盡管我們可能不能達(dá)到相關(guān)利益方開始的 預(yù)期， 我們應(yīng)該可以達(dá)到我們?cè)诰A段后達(dá)成的協(xié)議所規(guī)定的要求。讓相關(guān)利益方學(xué)會(huì)期望團(tuán)隊(duì)實(shí)現(xiàn)在精化的后階段所擬訂的要求，而不是他們開始所期望的要求，這是成為一個(gè)成功RUP項(xiàng)目管理人的關(guān)鍵所在。
我希望我已經(jīng)向大家說(shuō)明，在建立部門應(yīng)用軟件的時(shí)候，采用不斷增強(qiáng)的版本策略可以在IT投資上有非常顯著的好處。RUP為這種方法提供了很好的指導(dǎo)。我希望您的組織可以考慮這種方法。 如果你已經(jīng)決定創(chuàng)造一個(gè)迭代化軟件開發(fā)環(huán)境，那教育相關(guān)利益方非常重要，你必須讓他們懂得RUP項(xiàng)目的合作特性。你的指導(dǎo)委員會(huì)管理你開發(fā)應(yīng)用的方法對(duì)你的成功有效地使用預(yù)算，避免傳統(tǒng)瀑布式方法的不佳行為有著非常重要的意義。
祝你好運(yùn)！
