XP和RUP的比較
XP (Extreme Programming)是Kent Beck和Ward Cunningham於1996年提出的一套軟件開發過程理論。它不同於以往的軟件開發理論，沒有對軟件開發的整個過程進行強制而繁瑣的規定，而是給出了一套在實際軟件開發過程中需要遵守的活動原則。XP沒有強調複雜的過程和繁瑣的文檔，可以說XP是輕量級的軟件開發過程理論。當然，與任何軟件過程理論一樣，XP也是爲了利用更少的成本而開發出品質卓越的軟件，滿足最終用戶的需求，所以它非常強調客戶滿意度和客戶在軟件項目中所扮演的角色。在XP中，主要強調從四個基本方面來提升軟件質量：
△ 提高團隊成員之間的溝通
△ 以最簡單的方法設計和編寫程序
△ 從最終用戶處得到持續的反饋
△ 在項目開發過程中，保持整個團隊的士氣和勇氣
在現代軟件開發過程中，能夠唯一保持不變的就是不斷的變化。客戶的需求隨時可以更改；競爭對手會在開發過程中推出新的版本，不得不使我們更改原有的軟件開發計劃和需求定義。XP充分認識到了這個不可更改的現實，整個理論強調了作爲軟件開發團隊要充分適應這種不斷的變化，即使是在項目開發的後期。
RUP簡介
RUP是IBM Rational的統一過程理論，是一套以文檔爲主的軟件產品，是一套面向過程的軟件開發理論。RUP是一套以架構爲中心，用例驅動的迭代開發過程，具有自己的概念，最佳實踐和核心工作流程。下面就對這些內容作一簡單介紹。
RUP強調在軟件開發的過程中，需要遵守一定的開發流程。目的是爲了按照客戶需求開發出高質量的軟件產品。並且，爲了可以使RUP能夠可以被更廣泛的應用到各種軟件開發項目中，RUP強調了本身的可定製性：即任何組織和項目都可以根據自身的需求開發出符合自身的流程。
△ 角色：定義了在軟件項目中，對某項工作負責的個人或小組。
△ 活動：在開發流程中，角色所從事的活動。
△ 工件和工件集：工件是流程的工作產品。角色使用工件執行活動，並在執行活動的過程中生成工件。工件可以是項目計劃，需求文檔，或是存貯在Rational Rose中的設計模型等。工件集是打算用來完成相似目的的一組相關的工件。
△ 模板：模板是工件的模型。
△ 工作流程：是一系列有順序的活動。對於RUP的核心工作流程，使用活動圖來表示。流程中的每一步，都詳細規定了哪些角色使用何種模型進行什麼活動，用以生產出何種工件。
RUP的最佳實踐包括如下內容：
△ 迭代開發：RUP中，每一代軟件產品都要經歷四個階段：先啓，精華，構建，產品化。爲了減少開發過程中的風險，提高軟件質量，適應變更，RUP要求在每一個階段中採用迭代開發的方式。
△ 需求管理：有效記錄系統需求及其屬性，其間的關聯性。用於在客戶與開發團隊之間就係統的功能達成一致。有利於最大限度的提高客戶滿意度，促進產品開發團隊內的交流。
△ 構件構架：RUP強調系統架構的設計，在迭代的初期需要產生並驗證一個構架，並在以後的逐次迭代中逐步完善。好的架構可以明確系統各個組成部分之間的接口，並且可以方便項目管理。構件是具有明確功能和邊界的一個軟件模塊。架構決定了構件的集成方式。測試是由構件開始，慢慢過渡到整個系統，是自底向上的測試方法。
△ UML：使用UML對整個系統建模。
△ 質量管理：確定質量目標及其評估方法。貫穿於RUP整個過程。
△ 配置和變更管理：嚴格的執行變更和配置管理。
△ 可配置流程：RUP是一個可配置的流程。這個軟件工程流程可以被用戶調整、定製、更改和擴展。
△ Use Case驅動
核心工作流程：
在RUP中，詳細規定了以下流程的工作內容：業務建模、需求、分析設計、實施、測試、部署、配置和變更管理、項目管理和環境。對於每一流程，都給出了詳細的工作流程明細圖，說明了每一個活動所要求參與的角色，所需要的模型和產生的工件。對於流程中的每一步，還給出了一些工作指南，對於用戶進行指導。
▲ 做好計劃：爲了減少軟件開發過程中的風險，確保軟件質量，XP和RUP均要求採取迭代式的開發方式。在XP項目中，項目組要做好軟件開發計劃，開發人員要估計出完成每一個用戶需求（User Story）所需要的時間和投入；客戶根據開發人員的估計和自身的需求來決定這些User Story的優先級。同時要做好迭代開發計劃，明確每一次迭代的目標。XP中要求每次迭代爲1至3個星期，在項目整個開發的過程中應該儘量保證迭代週期的一致性。在每一次迭代開始時，由用戶和開發人員共同商討決定在本次迭代中需要實現的User Story。
在RUP中，每一個階段（先啓，精化，構建，產品化）都由若干次迭代組成，只不過每一次迭代開發的側重點不一樣。舉例來說，在先啓階段進行一次迭代，用以確定項目的規模和前景；在精化階段的一次迭代用以確定軟件需求和架構；在構建階段進行若干次迭代，實現用例並充實架構；再在產品化階段經歷幾次迭代，把產品最終轉移到用戶羣。每一個階段的結束都是一個主要里程碑。項目經理要在項目初期制定軟件開發計劃和階段與迭代計劃。
從這裏我們可以看到，XP和RUP都要求做好開發計劃和迭代計劃，明確每一次迭代的目標。這是現代商業軟件開發普遍採用的方式。
XP使用User Story的形式記錄系統用戶的需求。“User Story”指的是軟件所需要滿足的用戶需求（寫在4×6的卡片上），在XP中用於估計軟件開發時間，並且作爲驗收測試的依據。RUP則是一套以Use Case驅動的開發過程（Use case用來敘述一個用戶在外部使用系統的需求情況）：用戶可以按照Use Case來組織需求；在設計中，要表現各個對象如何通過交互來實現Use Case；在測試階段，要通過Use Case生成測試用例，用於測試、驗證系統的功能。User Case和User Story都是從系統外部描述用戶的需求，並且作爲以後的開發和測試工作的依據，從這個意義上講，二者非常的相似。
XP中並不要求User Story的敘述一定要詳細到以往軟件工程中所要求的詳細地步（4×6的卡片上能包含多少內容呢？）。這主要是因爲充分認識到了現代商業軟件開發的衆多不確定因素，爲了能夠使過程本身可以很好的適應外界因素不斷的變化。而在RUP中對需求的生成和管理都提出了較高的要求。RUP的核心工作流程中包含“需求”流程，其中詳細定義了需求產生的過程及產出的工件，主要包括：詞彙表、需求管理計劃、前景、用例、需求規約（SRS）、需求屬性等等。在RUP的最佳實踐“需求管理”中要求嚴格控制需求的變更，並根據可跟蹤鏈接（Traceability）確定受到影響的其它工件。從對需求的詳細程度、過程要求和產出工件等方面，我們可以看出，RUP相對XP來說是一種“重量級”的軟件開發過程理論。
XP中對需求的要求相對來說要比RUP簡單的多，所以它要求在開發團隊中隨時可以找到客戶代表，可以一起商討軟件需求。
▲ 小版本發佈：XP要求每一次迭代爲1至3個星期，項目組應該儘早使客戶得到一個可以使用的軟件版本，之後在此基礎上進行不斷的演進。在項目的開發過程中，應持續的從on-site customer處得到反饋，用以不斷的完善軟件。持續不斷的與客戶進行交流，可以彌補XP中需求不夠詳細的弱點。XP更強調項目組成員（項目經理、程序員、測試人員、客戶等）之間的交流，面對面的交流可以避免由於書寫需求和閱讀需求產生歧義而帶來的損失。
在RUP中，由於先期的迭代主要是集中在系統的需求和設計上，一般要到項目後期才能夠得到可以使用戶真正使用的版本（不是在需求階段產生的UI Prototype）。要做到小版本發佈，一定要注意軟件產品build要做到自動化（可以使用ant，gnu make等工具）。否則，如果每次產品發佈時都會發生break build，會爲項目組帶來許多不必要的麻煩。
▲ 設計簡單：
KISS (Keep It Simple and Stupid)! XP要求使用盡可能簡單的設計來完成目前開發階段的用戶需求（User Story）。不要擔心以後的用戶需求會對系統造成何種影響。用戶的需求很有可能會出現變化，所以不要進行過於複雜的設計。同時，簡單的設計也有利於節省時間，保證系統質量，減少出錯的機會。XP對設計的生成過程和文檔沒有提出更多的要求。
在RUP中，強調了架構的重要性，在開發過程中的“精化”階段，要生成並驗證一個軟件架構。該架構是系統的部分實現，是一個可執行的架構原型。使用該架構可以驗證系統某方面的功能，並且可以降低以下幾方面的風險：性能、吞吐量、可靠性等。並且，在RUP中還使用基於構件的開發（CBD）。基於構件的開發，可以帶來如下好處：分清系統每一部分的責任，使每一部分具有清晰的邊界；可以執行有效的複用；可以作爲項目管理的基礎；可以方便地進行自底向上的集成測試。
值得注意的是，在RUP中也並不否定“設計簡單”的原則，簡單的設計可以保證系統的健壯性和易於維護（能使用最簡單的設計來滿足用戶的需求才是真正的挑戰）。RUP和XP的不同在於架構在整個軟件開發過程中所處的地位。RUP提倡以架構作爲軟件開發的中心，可見架構在RUP中的重要性。而使用XP，有可能在開始編程的時候，系統根本不具備一個體系架構，只使用最簡單的方式去滿足User Story要求的功能。系統的整體架構是在不斷的迭代開發過程中逐漸形成的，並且程序的設計是蘊藏在一行一行的代碼中。XP的側重點是在於如何靈活地處理不斷的變化。在使用XP的項目中，不會等到需求和設計都寫的非常詳細了纔會開始編寫程序，而是把編寫需求和設計的工作減少到最少，儘快的開始編程，通過短週期的迭代不斷地產出可以讓用戶使用的版本，並從客戶處得到持續的反饋，在不斷的發展過程中逐漸完成系統的每一部分。
由於沒有詳細的文檔來說明需求和設計，在XP團隊中溝通就顯得尤爲重要，項目組成員需要面對面的討論軟件的具體問題。XP的這種做法可以避免由於寫作和閱讀文檔的歧義而引起的錯誤，但也因此限制了團隊規模。一般情況下，XP可以應用於12個程序員以下的團隊。相對而言，RUP可以應用於較大規模的團隊，不同的團隊之間通過書寫完善的文檔來進行交流。
▲ 重構 （Refactoring）
隨着開發進程的進行，很有可能發現在項目早期進行的系統設計和程序代碼不能適應進一步的開發。在程序中可能會出現重複的代碼，從來沒有使用過的類或方法。慢慢的這些代碼很有可能變成整個系統的累贅，沒有人敢於去修改這些莫名其妙的代碼。XP強調要在整個軟件開發週期內不斷的進行重構，並且對於這些不合適的代碼進行堅決的修改，來保持系統程序的簡潔和準確，從而達到保證軟件質量的目的。
RUP中沒有明確的提到重構。重構是確保源代碼質量的一種重要的手段。通過重構，可以最大限度的減少代碼的重複，保持簡單清晰的設計風格。XP中建議程序員經常對程序進行重構。
▲ 雙人編程 （Pair Programming）
使用XP的項目中，代碼是由兩個程序員共同編寫完成的。XP中是這樣形容的：兩個程序員共同坐在同一臺計算機前，其中一個執行編程任務，另外一人在旁邊審查代碼；兩個程序員會在適當的時候交換他們的工作。乍看起來，可能會覺得這種方法浪費生產力，但XP理論認爲這種生產方式可以顯著提高軟件質量，並且不會因爲某一程序員的離開而造成軟件開發的停頓。通過和不同的程序員進行雙人編程，可以使軟件的知識傳播到每一個團隊成員。在實際項目中，真正要實施雙人編程可能會有一定的困難。首先，公司的領導層不一定同意這種做法（既然在同一時刻只有五個人在編程，爲什麼要十個人呢？）；其次，程序員本身不一定習慣這種編程方式。應爲編寫程序是一種精神高度集中的腦力勞動過程，需要一個安靜和不受其他人打擾的環境；第三，兩個個性完全不同的人也很難能夠坐在一起共同工作。
如果不使用雙人編程的開發方式，可以通過code review（代碼複查）的方式來複查代碼。通過code review，不僅可以促使程序員開發出優秀、易懂的程序，還可以發現許多潛在的bug，使團隊的每一個成員都對程序有一個整體的瞭解。
在RUP中的核心工作流程--“實施”中也要求在構件在經過了編碼和單元測試之後，要進行“複審代碼”的活動。該項活動的輸入工件爲經過編譯的源代碼和編程指南，輸出的工件是被接受或拒絕的源代碼和複審記錄。複審代碼可以促使所有程序員使用相同的編程規範，發現自動測試所忽略的bug，促進項目成員之間的溝通。可以說，代碼審查是人們在長期的軟件開發過程中總結出來的寶貴經驗，對於提高軟件質量有着不可替代的作用。
▲ 集體主義 （Collective Ownership）
XP強調開發中的軟件作爲一個整體是屬於整個開發團隊的。每一個程序員都可以修改任何錯誤，重構任何一段程序，不只侷限於自己開發的代碼（建議在更改別人的代碼之前，一定要在源程序中加入註釋，用來解釋爲什麼更改，如何更改等問題），但前提是必須做好單元測試。並且，系統的架構由整個團隊負責開發的，每一個程序員都參與，不需要一個特別的架構設計師。
在RUP的核心工作流程“分析設計”中，要由角色“架構設計師”來進行架構分析的工作；在編碼階段，要由開發人員進行編碼。由於在RUP中把架構設計和編碼實現分成兩個不同的工作流程，很自然的就把不同階段的工作對應到不同的角色上去。
從這裏我們可以引申出一個問題，就是XP團隊中對成員的要求實際上是很高的。在XP中，程序員首先要負責和客戶代表討論具體的需求，決定使用何種技術去滿足客戶的商業需求（User Story），並且和客戶一起制定出迭代開發計劃；其次，XP中無特定的架構設計師，而是強調每一個程序員都是系統的設計者，程序的設計是包含在代碼中的；要能夠很好的理解其它程序員編寫的代碼；並且，程序員還要寫好單元測試用例，執行單元測試。所以我們看到，在XP中，每一個程序員都會身兼多個角色，他必須要具有廣泛的知識基礎，要有很強的溝通能力和應變能力，還要能夠合理的安排個人的工作時間和具有很強的責任心。由此可見，XP的理論基礎是非常強調個體在團隊中所起的作用。
如果團隊成員的水平參此不齊、有強有弱，最好不要使用XP進行開發，可以考慮類似RUP的做法：由少數比較有經驗的程序員（senior engineer）負責軟件整體的架構，而由其它的成員負責編碼。
▲ 隱喻命名（System Metaphor）
XP要求使用一套簡單易懂、具有象徵意義的詞語來命名程序中的類和方法。使任何人都可以通過名稱容易地理解整個系統。使用隱喻命名的方式，可以使每一個開發人員能夠更好的瞭解系統每一部分的功能及其相互之間的關係。
相對於XP來說，RUP是使用系統架構來說明每一部分的關係、接口、以及功能的。RUP的最佳實踐包括使用UML來進行系統的分析設計，UML可以在所有的團隊成員之間提供可供交流的統一語言。並且，因爲UML已經非常的普及，項目成員可以使用UML來與非項目成員進行有效的交流。
相比之下，使用UML的做法比較嚴謹，不容易產生歧異，可以更好地起到交流的作用。
▲ 持續集成 （Continuous Integration）
對於XP項目中的程序員來說，至少每天要和源代碼管理系統進行一次同步，並且至少要check in自己的代碼一次。持續集成的好處的顯而易見的：可以使程序員工作在最新的代碼之上，在早期避免一些由於兼容性而引起的問題。如果程序員在開發了2－4周之後才與系統進行集成，所付出的代價將是巨大的：他很可能還需要1－2周的時間調整自己的代碼來與其它程序員的改動進行集成，並且非常容易產生錯誤。
在RUP中，建議用戶Rational工具進行配置管理。持續集成可以說是軟件配置管理（SCM）的最佳實踐之一，無論使用任何過程，任何工具都應該在開發過程中做到這一點。很多新一代的軟件配置管理工具可以完全支持持續集成，甚至在產品中徹底的貫徹了持續集成的思想。
▲ 編程規範 (Coding Standards)
XP要求開發團隊應使用統一的軟件編程規範，使得代碼更加清晰和易於其它程序員理解，還可以使每一個程序員都可以通過源代碼本身直接地進行交流。
▲ 不加班 (No Overtime)
爲了保證開發團隊的士氣和精力，XP不鼓勵進行加班，應該嚴格保證每週40小時的工作時間。如果能夠實現XP的要求，恐怕所有程序員都會認爲來到了理想國了。現實世界中，加班是不可避免的（不只是軟件開發，各種行業的從業人員都會加班），但是要採取有效的手段激勵團隊的士氣，使得每個成員都具有必勝的信心和旺盛的鬥志。
▲ 測試（Testing）
XP中主要從兩方面強調了測試的重要性：單元測試和驗收測試。
單元測試：在程序開發之前，需要爲所開發的代碼編寫測試用例。程序員所編寫的每一行代碼都需要經過單元測試。並且單元測試要做到自動化（使用自動化測試工具：JUnit等）。所有爲單元測試所編寫的代碼也需要和源代碼一起check in到版本控制系統中。
驗收測試：客戶爲了驗證整個系統是否滿足需求（User Story）而進行的測試。一個User Story直到通過了所有和它相關的驗收測試纔可以認爲是真正完成。驗收測試需做到自動化，可以用於在產品發佈之前的迴歸測試。
除了驗收測試和單元測試，RUP同時強調了集成測試、可靠性測試、壓力測試等其它類型的測試。並且給出了一些實踐指導原則。在實際軟件開發項目中（例如一個B/S結構的應用），可靠性測試和壓力測試等都具有很重要的意義。即使使用XP，也不能忽略這些測試。
▲ 客戶代表（On-site Customer）
應用XP的開發團隊中應該隨時可以找到一名客戶代表。程序員可以與該代表商量系統的需求。該客戶代表還需要參與產品發佈計劃和迭代開發計劃的制定，決定User Story的優先級和產品發佈時間；以及進行相應的驗收測試。
在RUP中的“業務建模”和“需求”兩個核心工作流程中幾乎每一個活動（這些活動主要在先啓和精化階段進行）都涉及到了客戶和最終用戶。客戶和最終用戶主要的作用是提出系統需求，協助系統分析員決定需求的優先級、工作量、成本、風險等屬性，並且需要協助業務流程分析員完成對目標組織的業務流程分析和建模工作。
客戶在現代軟件開發中所扮演的角色是至關重要的。開發團隊的最終目的就是滿足客戶提出的需求。能夠與客戶進行有效的溝通是軟件項目成功的必要條件。由於XP並沒有要求在項目開始階段寫出完整的客戶需求，所以它爲了把握軟件開發的方向，需要不斷的與客戶進行交流。客戶水平的高低，也有可能直接影響到項目開發的成敗。所以在XP的團隊中，不止是每一個程序員要有較高的水平和責任心，團隊中的客戶也需要有高水平和盡職盡責。
小結:
綜上所述，我們可以看到相對於RUP來說，XP是一種輕量級（light weight）的軟件開發過程理論，主要體現在三個方面：
☆ 對過程的要求。
☆ 對過程所產出工件（文檔等）數量的要求。
☆ 對文檔內容的詳細程度要求。
當然，RUP強調了本身是可定製的，用戶可以根據自身的需求對流程和工件等進行適當的剪裁（但是讀懂RUP的所有內容，然後再作出合理的定製，絕對不是一件簡單的事情，需要花費大量的精力），從而得到基於RUP的敏捷方法。
XP是一種people-oriented的輕量化過程理論；RUP更像是一種面向過程(process-oriented)的開發理論。可以說XP是由程序員來驅動的軟件開發過程，而RUP則是過程驅動的軟件開發。相對XP來說，RUP顯得非常的龐大，實踐指導意義並不十分突出，如果一個項目完全遵循RUP去做，很有可能忽略了程序本身，而過於的注重過程控制，走向軟件開發中的形式主義。過於的注重形式，勢必使團隊花費很多的時間去滿足過程的要求，使得程序員不能專心在開發程序上。XP則是強調儘量把時間放在實實在在的編寫程序（coding）上。但是，在XP中，有一些必要的內容又被過分的省略了。舉例來說，任何一個軟件產品的發佈，都不僅僅是通過驗收測試，還應包括相應的文檔、培訓教材、在線幫助等支持性文檔，這些在XP中都沒有得到很好的體現。
XP只給出了一般的開發活動原則（例如：計劃、雙人編程、重構等），沒有硬性規定開發過程，所以我們可以說XP非常地適合軟件需求變化的發生（這正是現代軟件開發的一大特點），無論需求如何變化，使用XP的團隊都可以及時的調整自己的開發計劃，重構程序代碼，在最短的時間內使軟件滿足客戶的實際需求。開發團隊也可以根據項目不同階段的不同特點以及不同的人員狀態，及時的進行開發流程的調整。所以我們說XP本身具有高度的適應性。RUP強調了對於變更的控制，所以說它是力求控制變化，控制變化的發生，控制變化所產生的影響。在RUP中，也指明瞭在產品後期可以對需求和軟件架構進行修改，但是變更要有嚴格的控制。
軟件開發是所有團隊成員腦力勞動的結果，其特點就是涉及到的人的因素非常多。爲了使不同的人員能夠有效的合作，生產出零缺陷軟件，儘量減少軟件項目中的風險，人們逐漸認識到了軟件開發要遵循一定的過程規範，才能夠避免開發過程中的混亂。但是，即使有了固定的過程控制，也絕不可能淡化人的因素對軟件產品所產生的影響。最終編寫代碼和執行測試都是要由人來完成的。優秀的程序員不使用任何過程也可以開發出很好的軟件，他們可以從實踐中逐步總結出自己的最佳過程；而平庸的程序員無論使用何種優秀的過程實踐，也只能編寫出一般的軟件產品。
XP對團隊成員的水平要求是很高的，需要通過人與人之間面對面的交流來替代書面文檔。之所以這樣，是因爲長期的實踐證明：要書寫出沒有歧異的軟件需求文檔需要花費太多的精力，與其這樣，還不如在這段時間裏開發出一個客戶可用的版本，讓客戶使用並從客戶處得到反饋。所以，XP一般不適用於大規模的開發團隊；一般來說，XP可以應用在12個程序員以下的軟件開發團隊。如果把一個大的軟件項目分解到若干個小型團隊，在每一個小的團隊中使用XP，一定要注意如何進行團隊之間的溝通和交流，這也是XP理論沒有強調的一部分。從理論上來說，RUP可以適用於更大規模的軟件開發團隊，團隊之間通過書寫完備的文檔來進行交流。
總之，軟件項目由於涉及的人的因素非常之多，直接導致了項目本身的千變萬化。在實際的項目中，必然都存在着一個不斷摸索的過程。實際項目本身的過程管理，很有可能包含一部分XP的內容，同時又具有RUP的因素，很有可能還有項目成員根據以往經驗獲得的最佳實踐。在真正的軟件開發過程中，我們不能盲目的去追求單純的過程管理，而是要注意過程管理的最終目的：開發出優秀的軟件產品。