1、Attack major risks early and continuously ...or they will arrack you
為什么要在早期處理最大風(fēng)險(xiǎn)呢？未被處理的風(fēng)險(xiǎn)往往會導(dǎo)致你潛在的投入更多的精力在有缺陷的框架或者不理想的需求上。實(shí)際上風(fēng)險(xiǎn)的數(shù)量往往與項(xiàng)目完成時(shí)間估算的上下限有關(guān)系。為了得到準(zhǔn)確的估算，你必須首先著眼于識別和處理風(fēng)險(xiǎn)。
迭代模型和瀑布模型的比較差別：

出自文章：The Sprit of thr RUP
那么如何才能盡早的處理風(fēng)險(xiǎn)呢？在每一個(gè)迭代的開始，RUP建議你建立或修訂一個(gè)重大風(fēng)險(xiǎn)列表，然后決定你應(yīng)該如何處理這些風(fēng)險(xiǎn)，通常你需要找出最重要的三個(gè)或五個(gè)風(fēng)險(xiǎn)。比如風(fēng)險(xiǎn)列表可能看上去會是這個(gè)樣子：
Risk 1：讓我們擔(dān)心的是，基于過去的經(jīng)驗(yàn)，X部門并不會理解我們計(jì)劃滿足什么需求，這有可能會導(dǎo)致他們要求在軟件的beta版本提交時(shí)候提出變更。
Risk 2：我們還不明確如何才能與老系統(tǒng)Y集成。
Risk 3：我們沒有在.Net平臺下開發(fā)或使用Rational Rose的習(xí)慣。
Risk 4：...etc。
好了，現(xiàn)在如何來使用這個(gè)風(fēng)險(xiǎn)列表呢？處理風(fēng)險(xiǎn)是項(xiàng)目組中每個(gè)人都應(yīng)該考慮的事情。看看哪些應(yīng)該是你一貫應(yīng)該解決的，然后稍微調(diào)整計(jì)劃來表明你確實(shí)要對這些風(fēng)險(xiǎn)進(jìn)行處理。通常，風(fēng)險(xiǎn)的處理應(yīng)該從多個(gè)角度入手考慮，比如需求、設(shè)計(jì)和測試。在每一個(gè)角度中，先擬定一個(gè)粗放的解決方案，然后持續(xù)不斷的細(xì)化它，進(jìn)而縮減這些風(fēng)險(xiǎn)。比如采用下面的這些手段來一一對應(yīng)的解決上面的風(fēng)險(xiǎn)：
Risk1：當(dāng)有關(guān)X部門的用例被制訂出來的時(shí)候，使用UI原型進(jìn)行補(bǔ)充。與X部門召開會議，然后與他們一起遍歷這些用例，使用UI原型作為指導(dǎo)。在需求文檔中獲取X部門的正式簽名確認(rèn)。讓X部門的參與貫穿項(xiàng)目周期，不斷地為他們提供早期原型和alpha版軟件。
Risk 2：挑選一兩名開發(fā)能手成立“飛虎隊(duì)”來構(gòu)建一個(gè)實(shí)實(shí)在在的原型，來展示如何與老系統(tǒng)Y集成。之后集成的工作可能會告一段落，但是原型會證明與老系統(tǒng)集成的有效性。在整個(gè)項(xiàng)目中，確保有有效的測試涵蓋對于老系統(tǒng)Y的集成部分。
......
Risk 3：派遣一些人去進(jìn)行有關(guān).net方面和Rational Rose的培訓(xùn)......
有很多項(xiàng)目風(fēng)險(xiǎn)與所選框架有關(guān)。這就是為什么RUP在精化階段的主要目標(biāo)是確保框架的正確性。為了做到這一點(diǎn)，你不能僅僅設(shè)計(jì)框架，還要實(shí)現(xiàn)并測試它。
時(shí)刻注意風(fēng)險(xiǎn)列表是不停變化的。與風(fēng)險(xiǎn)的斗爭是一場持久戰(zhàn)--每一次迭代都會減少或除去一些風(fēng)險(xiǎn)，與此同時(shí)，其他一些風(fēng)險(xiǎn)又會成長，新的風(fēng)險(xiǎn)也會出現(xiàn)。
2、Ensure that you deliver value of your customer
向客戶提交有價(jià)值的東西顯然是很重要的。那么如何才能做到這一點(diǎn)呢？我們的建議就是：把迭代和用例驅(qū)動方法密切的結(jié)合。
什么是用例？用例是一種捕獲功能需求的途徑。一旦一個(gè)用例能夠清楚地描述一個(gè)用戶如何與系統(tǒng)進(jìn)行交互，那么相關(guān)的業(yè)務(wù)人員也能夠描述清楚。一旦用例能夠說清楚交互在時(shí)間上的先后順序，相關(guān)的業(yè)務(wù)人員、分析人員就能識別用例中的任意的“hole（什么意思？）”。一個(gè)用例幾乎可以被認(rèn)為是未來用戶手冊的一部分，而它在被寫出來的時(shí)候基本不用考慮特別的用戶接口。不要想著在用例中寫下用戶接口（這里的接口也許是指輸入、輸出等）；作為替代，你可以以UI原型作為用例的補(bǔ)充，以截圖的方式。
用例通常被很多人用來向掌管錢的客戶展現(xiàn)他們的系統(tǒng)會做什么。但這并不是用例的主要益處。用例的主要益處就是能夠讓團(tuán)隊(duì)的成員更加貼近于需求，并以此指導(dǎo)他們的設(shè)計(jì)、實(shí)現(xiàn)、測試還有最終用戶手冊的編寫。用例強(qiáng)迫你保持對于用戶視角的客觀性，并且它們使你能夠驗(yàn)證設(shè)計(jì)和實(shí)現(xiàn)是否真正切合了用戶的需求。它們甚至使你在為項(xiàng)目做計(jì)劃和管理邊界的時(shí)候能夠小心謹(jǐn)慎的考慮用戶的需要。

出自文章：The Sprit of thr RUP
時(shí)序圖、協(xié)作圖展現(xiàn)了這些與系統(tǒng)的交互如何被你的設(shè)計(jì)所實(shí)現(xiàn)。你同樣可以根據(jù)用例來編寫測試case。你可以選擇要實(shí)現(xiàn)哪些用例，并以此劃定你的系統(tǒng)邊界。正如上面所強(qiáng)調(diào)的，用例會讓你從始至終都圍繞著需求進(jìn)行工作。

讀后感：

這篇文章看上去有些空泛，它曾經(jīng)被刊登在ibm上，現(xiàn)在卻再也找不到了。作者真正闡述清楚了RUP的Spirit了嗎，還是他自己也是一知半解呢？