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

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

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

讀后感：

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