RUP的過程改進，倡導針對不同類型項目進行適當?shù)牟眉?，實際上這也是一種靈活適應的方式、隨需而變的思想。我對此是理解并贊同的，但是我對RUP卻一直保持一種相對謹慎的態(tài)度。
對于RUP來說，首先，我認為它過于理想化和理論化，RUP 是過程組件、方法以及技術的框架，你可以將其應用于任何特定的軟件項目，由用戶自己限定 RUP 的使用范圍。對于各種類型的軟件項目，RUP并未給出具體的自身裁減及實施策略，總有些無依據(jù)可循的感覺。你既可以說它能解決任何問題，也可以說它什么都不是；其次，RUP從本質(zhì)來說還是一個強調(diào)設計和規(guī)范的軟件方法，從這個角度來講，與傳統(tǒng)的瀑布模型沒有太大差別，它的靈活性較之敏捷方法還是相對較弱的。在一些小型軟件項目、特別是不可預測的軟件項目開發(fā)中，面臨著各種緊急需求、面臨著時間壓力，沿用RUP是很難應付自如的。但是在另一方面，RUP強調(diào)對知識的收集、整理和加工定義，強調(diào)在軟件開發(fā)的時候要有好的體系結(jié)構(gòu)。所以它還是很有利于知識的積累和共享的。
相比RUP ，敏捷方法如XP則更為靈活，倡導盡早的、持續(xù)的交付有價值的軟件滿足用戶需要。用交流溝通取代詳盡的文檔，強調(diào)團隊的主動、自律、自我組織和自發(fā)管理。而XP也是以代碼為核心的一種方法，這里有很多的東西是未知的，知識只存在于兩個地方：開發(fā)者的頭腦和最后的代碼。對于項目管理者來說，他們會認為敏捷開發(fā)方法弱化了知識管理的概念，而實際上敏捷開發(fā)注重的是最有價值的知識的積累和沉淀。
如何靈活應對各種項目風險、如何化優(yōu)先滿足用戶價值、又如何能夠有效的控制項目開發(fā)過程、如果做好項目過程中的知識管理，是每一個軟件項目管理者都需要深入思考的問題。RUP的倡導者一直強調(diào)RUP裁剪，實際上我認為RUP不僅僅是需要自身的裁剪，還需要學會融合。在RUP裁剪的同時，適宜的融合敏捷開發(fā)的各種實踐。不要認為RUP與XP是矛盾的，其實不然，它們具有不同的原理、具有不同的應用領域。在 RUP 中融合了 XP 技術時，才會得到過程的正確量，既滿足了項目所有成員的需要，又解決了所有主要的項目風險問題。對于一個工作于高信任環(huán)境中的小型項目團隊，其中用戶是團隊的一部分，那么 XP 完全可以勝任。對于團隊越來越分散，代碼量越來越大，或者構(gòu)架沒有很好定義的情況，您需要做一些其他工作。在用戶交互具有"契約"風格的項目中，僅有 XP 是不夠的。RUP 是一個框架，可以從 RUP 出發(fā)，在必要時以一組更健壯的技術來擴展 XP。
RUP實踐包括：
1． 迭代開發(fā): RUP的開發(fā)過程建立在一系列迭代之上，每次迭代都有一個固定的時間限制（例如四個星期），稱為"時間盒"，每次迭代結(jié)束的時候都發(fā)布一個穩(wěn)定的小版本，該版本是最終系統(tǒng)的子集。"時間盒"是迭代開發(fā)中的關鍵概念：它意味著迭代周期的期限是固定的，如果目標沒有完成，則放棄本次迭代的需求，而不是延長迭代的時間。
2． 管理需求
3． 使用基于組件的構(gòu)架
4． 可視建模
5． 持續(xù)的質(zhì)量驗證
6． 控制變更
關于RUP階段的一個簡潔和準確的描述：
1.初始－開發(fā)系統(tǒng)的業(yè)務用例；要求探索少量但是重要的需求（大約10%），以便獲得范圍、關鍵風險的尺度，并且決定是否進入細化階段。
2.細化－迭代地構(gòu)建核心體系結(jié)構(gòu)和解決技術風險。構(gòu)建體系結(jié)構(gòu)意味著真正的編程、集成及測試-這不是紙上談兵或者丟棄原型。細化階段，我們需要迭代地詳細地探索大部分需求（大約80%），同時實現(xiàn)系統(tǒng)的核心風險部分。在整個細化階段需求都可能是變化的，通過不斷的"反饋－適應"循環(huán)，評估已實現(xiàn)的部分。
可以看到，這與傳統(tǒng)的瀑布風格的需求定義不同，其大部分需求是在開發(fā)核心體系結(jié)構(gòu)的同時細化得到的，并且其從實際的開發(fā)中得到反饋。我們也能夠以此為據(jù)來決定是否繼續(xù)此項目。
3.構(gòu)造－迭代地構(gòu)建細化階段沒有做的元素；迭代地集成和進行質(zhì)量保證；準備部署。由于大部分需求的不穩(wěn)定性已經(jīng)在細化階段澄清，所以在構(gòu)造階段需求的變化較少。
4. 發(fā)布－完成&beta測試，確定版本，部署系統(tǒng)。RUP規(guī)則推薦"迭代周期的長度是2－6周"。 迭代開發(fā)和RUP的本質(zhì)是采取小步驟，對于可能不完美的實現(xiàn)，迅速集成，質(zhì)量保證，測試，及時獲得反饋，然后根據(jù)反饋，調(diào)整需求、設計和實現(xiàn)。小步驟、反饋和調(diào)整是核心概念。
迭代方法允許我們邊學邊走；隨著迭代的進行，我們得到越來越多的真實的需求，更加客觀的風險，以及完成該項目的更加準確的能力估計。簡言之，經(jīng)驗使我們成為更好的計劃者。
12 個 XP 實踐包括：
有計劃的開發(fā)：通過結(jié)合使用優(yōu)先級"故事"和技術估算，確定下一版本的功能
小版本：以小的增量版本經(jīng)常向客戶發(fā)布軟件
隱喻：隱喻是一個簡單、共享的"故事"或描述，說明系統(tǒng)如何工作
簡單設計：通過保持代碼簡單從而保證設計簡單。不斷的在代碼中尋找復雜點并且立刻進行移除
測試驅(qū)動開發(fā)：用戶編寫測試內(nèi)容以對"故事"進行測試。程序員編寫測試內(nèi)容來發(fā)現(xiàn)代碼中的任何問題。在編寫代碼前先編寫測試內(nèi)容
重構(gòu)：這是一項簡化技術，用來移除代碼中的重復內(nèi)容和復雜之處
結(jié)對編程：團隊中的兩個成員使用同一臺計算機開發(fā)所有的代碼。一個人編寫代碼或者驅(qū)動，另一個人同時審查代碼的正確性和可理解性
集體代碼所有權：任何人都擁有所有的代碼。這就意味這每個人都可以在任何時候變更任何代碼
持續(xù)集成：每天多次創(chuàng)建和集成系統(tǒng)，只要任何實現(xiàn)任務完成就要進行
每周 40 個小時：程序員在疲勞時無法保證效率。連續(xù)兩周加班是絕對不允許的
現(xiàn)場客戶：一名真實的客戶全時工作于開發(fā)環(huán)境中，幫助定義系統(tǒng)、編寫測試內(nèi)容并回答問題
編碼標準：程序員采用一致的編碼標準證
RUP與XP的融合，是各自特點的相互補充，也是軟件開發(fā)方法的平衡之道。而對軟件技術平衡的思考也可以說是技術成熟的開始吧。
最后，再闡明我對軟件項目開發(fā)的理解。在軟件項目開發(fā)過程中，應該能夠識別、分析不同軟件項目的特點，采用相對適合的開發(fā)實踐來適應軟件開發(fā)過程，保證對軟件開發(fā)的有效支持，以便能夠創(chuàng)造出&ldquo足夠好的&rdquo軟件。而這個足夠就是對進度、成本、質(zhì)量之間的平衡，化滿足客戶需要的實現(xiàn)。
對于RUP來說，首先，我認為它過于理想化和理論化，RUP 是過程組件、方法以及技術的框架，你可以將其應用于任何特定的軟件項目，由用戶自己限定 RUP 的使用范圍。對于各種類型的軟件項目，RUP并未給出具體的自身裁減及實施策略，總有些無依據(jù)可循的感覺。你既可以說它能解決任何問題，也可以說它什么都不是；其次，RUP從本質(zhì)來說還是一個強調(diào)設計和規(guī)范的軟件方法，從這個角度來講，與傳統(tǒng)的瀑布模型沒有太大差別，它的靈活性較之敏捷方法還是相對較弱的。在一些小型軟件項目、特別是不可預測的軟件項目開發(fā)中，面臨著各種緊急需求、面臨著時間壓力，沿用RUP是很難應付自如的。但是在另一方面，RUP強調(diào)對知識的收集、整理和加工定義，強調(diào)在軟件開發(fā)的時候要有好的體系結(jié)構(gòu)。所以它還是很有利于知識的積累和共享的。
相比RUP ，敏捷方法如XP則更為靈活，倡導盡早的、持續(xù)的交付有價值的軟件滿足用戶需要。用交流溝通取代詳盡的文檔，強調(diào)團隊的主動、自律、自我組織和自發(fā)管理。而XP也是以代碼為核心的一種方法，這里有很多的東西是未知的，知識只存在于兩個地方：開發(fā)者的頭腦和最后的代碼。對于項目管理者來說，他們會認為敏捷開發(fā)方法弱化了知識管理的概念，而實際上敏捷開發(fā)注重的是最有價值的知識的積累和沉淀。
如何靈活應對各種項目風險、如何化優(yōu)先滿足用戶價值、又如何能夠有效的控制項目開發(fā)過程、如果做好項目過程中的知識管理，是每一個軟件項目管理者都需要深入思考的問題。RUP的倡導者一直強調(diào)RUP裁剪，實際上我認為RUP不僅僅是需要自身的裁剪，還需要學會融合。在RUP裁剪的同時，適宜的融合敏捷開發(fā)的各種實踐。不要認為RUP與XP是矛盾的，其實不然，它們具有不同的原理、具有不同的應用領域。在 RUP 中融合了 XP 技術時，才會得到過程的正確量，既滿足了項目所有成員的需要，又解決了所有主要的項目風險問題。對于一個工作于高信任環(huán)境中的小型項目團隊，其中用戶是團隊的一部分，那么 XP 完全可以勝任。對于團隊越來越分散，代碼量越來越大，或者構(gòu)架沒有很好定義的情況，您需要做一些其他工作。在用戶交互具有"契約"風格的項目中，僅有 XP 是不夠的。RUP 是一個框架，可以從 RUP 出發(fā)，在必要時以一組更健壯的技術來擴展 XP。
RUP實踐包括：
1． 迭代開發(fā): RUP的開發(fā)過程建立在一系列迭代之上，每次迭代都有一個固定的時間限制（例如四個星期），稱為"時間盒"，每次迭代結(jié)束的時候都發(fā)布一個穩(wěn)定的小版本，該版本是最終系統(tǒng)的子集。"時間盒"是迭代開發(fā)中的關鍵概念：它意味著迭代周期的期限是固定的，如果目標沒有完成，則放棄本次迭代的需求，而不是延長迭代的時間。
2． 管理需求
3． 使用基于組件的構(gòu)架
4． 可視建模
5． 持續(xù)的質(zhì)量驗證
6． 控制變更
關于RUP階段的一個簡潔和準確的描述：
1.初始－開發(fā)系統(tǒng)的業(yè)務用例；要求探索少量但是重要的需求（大約10%），以便獲得范圍、關鍵風險的尺度，并且決定是否進入細化階段。
2.細化－迭代地構(gòu)建核心體系結(jié)構(gòu)和解決技術風險。構(gòu)建體系結(jié)構(gòu)意味著真正的編程、集成及測試-這不是紙上談兵或者丟棄原型。細化階段，我們需要迭代地詳細地探索大部分需求（大約80%），同時實現(xiàn)系統(tǒng)的核心風險部分。在整個細化階段需求都可能是變化的，通過不斷的"反饋－適應"循環(huán)，評估已實現(xiàn)的部分。
可以看到，這與傳統(tǒng)的瀑布風格的需求定義不同，其大部分需求是在開發(fā)核心體系結(jié)構(gòu)的同時細化得到的，并且其從實際的開發(fā)中得到反饋。我們也能夠以此為據(jù)來決定是否繼續(xù)此項目。
3.構(gòu)造－迭代地構(gòu)建細化階段沒有做的元素；迭代地集成和進行質(zhì)量保證；準備部署。由于大部分需求的不穩(wěn)定性已經(jīng)在細化階段澄清，所以在構(gòu)造階段需求的變化較少。
4. 發(fā)布－完成&beta測試，確定版本，部署系統(tǒng)。RUP規(guī)則推薦"迭代周期的長度是2－6周"。 迭代開發(fā)和RUP的本質(zhì)是采取小步驟，對于可能不完美的實現(xiàn)，迅速集成，質(zhì)量保證，測試，及時獲得反饋，然后根據(jù)反饋，調(diào)整需求、設計和實現(xiàn)。小步驟、反饋和調(diào)整是核心概念。
迭代方法允許我們邊學邊走；隨著迭代的進行，我們得到越來越多的真實的需求，更加客觀的風險，以及完成該項目的更加準確的能力估計。簡言之，經(jīng)驗使我們成為更好的計劃者。
12 個 XP 實踐包括：
有計劃的開發(fā)：通過結(jié)合使用優(yōu)先級"故事"和技術估算，確定下一版本的功能
小版本：以小的增量版本經(jīng)常向客戶發(fā)布軟件
隱喻：隱喻是一個簡單、共享的"故事"或描述，說明系統(tǒng)如何工作
簡單設計：通過保持代碼簡單從而保證設計簡單。不斷的在代碼中尋找復雜點并且立刻進行移除
測試驅(qū)動開發(fā)：用戶編寫測試內(nèi)容以對"故事"進行測試。程序員編寫測試內(nèi)容來發(fā)現(xiàn)代碼中的任何問題。在編寫代碼前先編寫測試內(nèi)容
重構(gòu)：這是一項簡化技術，用來移除代碼中的重復內(nèi)容和復雜之處
結(jié)對編程：團隊中的兩個成員使用同一臺計算機開發(fā)所有的代碼。一個人編寫代碼或者驅(qū)動，另一個人同時審查代碼的正確性和可理解性
集體代碼所有權：任何人都擁有所有的代碼。這就意味這每個人都可以在任何時候變更任何代碼
持續(xù)集成：每天多次創(chuàng)建和集成系統(tǒng)，只要任何實現(xiàn)任務完成就要進行
每周 40 個小時：程序員在疲勞時無法保證效率。連續(xù)兩周加班是絕對不允許的
現(xiàn)場客戶：一名真實的客戶全時工作于開發(fā)環(huán)境中，幫助定義系統(tǒng)、編寫測試內(nèi)容并回答問題
編碼標準：程序員采用一致的編碼標準證
RUP與XP的融合，是各自特點的相互補充，也是軟件開發(fā)方法的平衡之道。而對軟件技術平衡的思考也可以說是技術成熟的開始吧。
最后，再闡明我對軟件項目開發(fā)的理解。在軟件項目開發(fā)過程中，應該能夠識別、分析不同軟件項目的特點，采用相對適合的開發(fā)實踐來適應軟件開發(fā)過程，保證對軟件開發(fā)的有效支持，以便能夠創(chuàng)造出&ldquo足夠好的&rdquo軟件。而這個足夠就是對進度、成本、質(zhì)量之間的平衡，化滿足客戶需要的實現(xiàn)。