簡介
極限編程是一個輕量級的、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟體項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。
XP是一種近螺鏇式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。
極限編程的目標
極限編程的主要目標在於降低因需求變更而帶來的成本。在傳統系統開發方法中，系統需求是在項目開發的開始階段就確定下來，並在之後的開發過程中保持不變的。這意味著項目開發進入到之後的階段時出現的需求變更（而這樣的需求變更在一些發展極快的領域中是不可避免的）將導致開發成本急速增加。
極限編程透過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個套用了極限編程方法的系統開發項目在應對需求變更時將顯得更為靈活。
極限編程的特徵
極限編程方法的基本特徵是：
•增量和反覆式的開發----一次小的改進跟著一個小的改進。
•反覆性，通常是自動重複的單元測試，回歸測試。參見JUnit。
•結對程式設計
•在程式設計團隊中的用戶互動（在場的客戶）
•軟體重構
•共享的代碼所有權
•簡單
•反饋
•用隱喻來組織系統
•可以忍受的速度
相關概念
軟體開發過程
軟體開發的過程是：需求分析、設計、編碼和測試。
需求分析：不僅僅是用戶需求，應該是開發中遇到的所有的需求。比如，你首先要知道做這個項目是為了解決什麼問題；測試案例中應該輸入什麼數據……為了清楚地知道這些需求，你經常要和客戶、項目經理等交流。
設計：編碼前，肯定有個計畫告訴你要做什麼，結構是怎樣等等。你一定要按照這個來做，否則可能會一團糟。
編碼：如果在項目截止日，你的程式不能跑起來或達不到客戶的要求，你就拿不到錢。
測試：目的是讓你知道，什麼時候算是完成了。如果你聰明，你就應該先寫測試，這樣可以及時知道你是否真地完成了。否則，你經常會不知道，到底有哪些功能是真正完成了，離預期目標還差多遠。
權利和義務
定義每個用戶需求的商業優先權；
制訂總體計畫，包括用多少投資、經過多長時間、達到什麼目的；
在項目開發過程中的每個工作周，都能讓投資獲得最大的收益；
通過重複運行你所指定的功能測試，準確地掌握項目進展情況；
能隨時改變需求、功能或優先權，同時避免昂貴的再投資；能夠根據各種變化及時調整項目計畫；
能夠隨時取消項目；項目取消時，以前的開發工作不是一堆垃圾，已開發完的功能是合乎要求的，正在進行或未完成的的工作則應該是不難接手的。
開發人員
知道要做什麼，以及要優先做什麼；
工作有效率；
有問題或困難時，能得到客戶、同事、上級的回答或幫助；
對工作做評估，並根據周圍情況的變化及時重新評估；
積極承擔工作，而不是消極接受分配；
一周40小時工作制，不加班。
其他問題
靈巧的輕量級軟體開發方法
一套軟體開發方法是由一系列與開發相關的規則、規範和慣例。重量級的開發方法嚴格定義了許多的規則、流程和相關的文檔工作。靈巧的輕量級開發方法，其規則和文檔相對較少，流程更加靈活，實施起來相對較容易。
在軟體工程概念出現以前，程式設計師們按照自己喜歡的方式開發軟體。程式的質量很難控制，調試程式很繁瑣，程式設計師之間也很難讀懂對方寫的代碼。1968年，Edsger Dijkstra給CACM寫了一封題為GOTO Statement Considered Harmful的信，軟體工程的概念由此誕生。程式設計師們開始摒棄以前的做法，轉而使用更系統、更嚴格的開發方法。為了使控制軟體開發和控制其它產品生產一樣嚴格，人們陸續制定了很多規則和做法，發明了很多軟體工程方法，軟體質量開始得到大幅度提高。隨著遇到的問題更多，規則和流程也越來越精細和複雜。
到了今天，在實際開發過程中，很多規則已經難於遵循，很多流程複雜而難於理解，很多項目中文檔的製作過程正在失去控制。人們試圖提出更全面更好的一攬子方案，或者寄希望於更複雜的、功能更強大的輔助開發工具（CaseTools），但總是不能成功，而且開發規範和流程變得越來越複雜和難以實施。
為了趕進度，程式設計師們經常跳過一些指定的流程，很少人能全面遵循那些重量級開發方法。
失敗的原因很簡單，這個世界沒有萬能藥。因此，一些人提出，將重量級開發方法中的規則和流程進行刪減、重整和最佳化，這樣就產生了很多適應不同需要的輕量級流程。在這些流程中，合乎實際需要的規則被保留下來，不必要的複雜化開發的規則被拋棄。而且，和傳統的開發方法相比，輕量級流程不再象流水生產線，而是更加靈活。
ExtremeProgramming（XP）就是這樣一種靈巧的輕量級軟體開發方法。
為什麼稱為“Extreme”（極限）？
“Extreme”（極限）是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它XP所不提倡的，則一概忽略（如開發前期的整體設計等）。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進度。
核心價值
極限編程中有四個核心價值是我們在開發中必須注意的：
溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、此外還擴展了第五個價值觀：尊重（Respect）。
XP用“溝通、簡單、反饋、勇氣和尊重”來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕鬆愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定範圍內成功地打破了軟體工程“必須重量”才能成功的傳統觀念。
XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用“溝通、簡單、反饋、勇氣和尊重”的態度來對待XP；輕鬆愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。
價值
極限編程技術以溝通、簡單、反饋、勇氣和尊重為價值標準 。
溝通
構建一個軟體系統的基本任務之一就是與系統的開發者交流以明確係統的具體需求。在一些正式的軟體開發方法中，這一任務是通過文檔來完成的。
極限編程技術可以被看成是在開發小組的成員之間迅速構建與傳播制度上的認識的一種方法。它的目標是向所有開發人員提供一個對於系統的共享的視角，而這一視角又是與系統的最終用戶的視角相吻合的。為了達到這一目標，極限編程支持設計、抽象、還有用戶-程式設計師間交流的簡單化，鼓勵經常性的口頭交流與回饋。
簡單
極限編程鼓勵從最簡單的解決方式入手再通過不斷重構達到更好的結果。這種方法與傳統系統開發方式的不同之處在於，它只關注於對當前的需求來進行設計、編碼，而不去理會明天、下周或者下個月會出現的需求。極限編程的擁護者承認這樣的考慮是有缺陷的，即有時候在修改現有的系統以滿足未來的需求時不得不付出更多的努力。然而他們主張“不對將來可能的需求上投入精力”所得到的好處可以彌補這一點，因為將來的需求在他們還沒提出之前是很可能發生變化的。為了將來不確定的需求進行設計以及編碼意味著在一些可能並不需要的方面浪費資源。而與之前提到的“交流”這一價值相關聯來看，設計與代碼上的簡化可以提高交流的質量。一個由簡單的編碼實現的簡單的設計可以更加容易得被小組中的每個程式設計師所理解。
反饋
在極限編程中，“反饋”是和系統開發的很多不同方面相關聯的：
•來自系統的反饋：通過編寫單元測試，程式設計師能夠很直觀的得到經過修改後系統的狀態。
•來自客戶的反饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當前系統的狀態。這樣的評審一般計畫2、3個禮拜進行一次，這樣客戶可以非常容易的了解、掌控開發的進度。
•來自小組的反饋：當客戶帶著新需求來參加項目計畫會議時，小組可以直接對於實現新需求所需要的時間進行評估然後反饋給客戶 。
反饋是與“交流”、“簡單”這兩條價值緊密聯繫的。為了溝通系統中的缺陷，可以通過編寫單元測試，簡單的證明某一段代碼存在問題。來自系統的直接反饋信息將提醒程式設計師注意這一部分。用戶可以以定義好的功能需求為依據，對系統進行周期性的測試。用Kent Beck的話來說：“編程中的樂觀主義是危險的，而及時反饋則是解決它的方法。”
勇氣
極限編程理論中的“系統開發中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為今天的需求設計以及編碼，不要考慮明天”這條戒律。這是努力避免陷入設計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發人員在需要重構他們的代碼時能感到舒適。這意味著重新審查現有系統並完善它會使得以後出現的變化需求更容易被實現。另一個勇氣的例子是了解什麼時候應該完全丟棄現有的代碼。每個程式設計師都有這樣的經歷：他們花了一整天的時間糾纏於自己設計和代碼中的一個複雜的難題卻無所得，而第二天回來以一個全新而清醒的角度來考慮，在半小時內就輕鬆解決了問題。
開發
工作環境
為了在軟體開發過程中最大程度地實現和滿足客戶和開發人員的基本權利和義務，XP要求把工作環境也做得最好。每個參加項目開發的人都將擔任一個角色（項目經理、項目監督人等等）並履行相應的權利和義務。所有的人都在同一個開放的開發環境中工作，最好是所有人在同一個大房子中工作，還有茶點供應；每周40小時，不提倡加班；每天早晨，所有人一起站著開個短會；牆上有一些大白板，所有的Story卡、CRC卡等都貼在上面，討論問題的時候可以在上面寫寫畫畫；下班後大家可以一起玩電腦遊戲……
需求
客戶應該是項目開發隊伍中的一員，而不是和開發人員分開的；因為從項目的計畫到最後驗收，客戶一直起著很重要的作用。開發人員和客戶一起，把各種需求變成一個個小的用戶故事（UserStory），例如“計算年級的總人數，就是把該年級所有班的人數累加。”；這些模組又會根據實際情況被組合在一起或者被分解成更小的模組；它們都被記錄在一些故事卡（StoryCard）上，之後分別被程式設計師們在各個小的疊代中（Iteration，通常不超過3個星期）實現；客戶根據每個模組的商業價值來指定它們的優先權；開發人員要做的是確定每個需求模組的開發風險，風險高的（通常是因為缺乏類似的經驗）需求模組將被優先研究、探索和開發；經過開發人員和客戶分別從不同的角度評估每個模組後，它們被安排在不同的開發周期里，客戶將得到一個儘可能準確的開發計畫；客戶為每個需求模組指定驗收測試（功能測試）。
每發布一次開發的軟體（經過一個開發周期），用戶都能得到一個可以開始使用的系統，這個系統全面實現了相應的計畫中的所有需求。而在一些傳統的開發模式中，無論什麼功能，用戶都要等到所有開發完成後才能開始使用。
設計
從具體開發的角度來看，XP內層的過程是一個個基於測試驅動開發（TestDrivenDevelopment）周期，諸如計畫和設計等外層的過程都是圍繞這些展開的。每個開發周期都有很多相應的單元測試（UnitTest）。剛開始，因為什麼都沒有實現，所以所有的單元測試都是失敗的；隨著一個個小的需求模組的完成，通過的單元測試也越來越多。通過這種方式，客戶和開發人員都很容易檢驗，是否履行了對客戶的承諾。XP提倡對於簡單的設計（SimpleDesign），就是用最簡單的方式，使得為每個簡單的需求寫出來的程式可以通過所有相關的單元測試。XP強調拋棄那種一攬子詳細設計方式（BigDesignUpFront），因為這種設計中有很多內容是你現在或最近都根本不需要的。XP還大力提倡設計走查（Review）、代碼走查以及重構（Refectory），所有的這些過程其實也是最佳化設計的過程；在這些過程中不斷運行單元測試和功能測試，可以保證經過重整和最佳化後的系統仍然符合所有需求。
編程
既然編程很重要，XP就提倡結對編程（PairProgramming），而且代碼所有權是歸於整個開發隊伍（CollectiveCodeOwnership）。程式設計師在寫程式和重構程式的時候，都要嚴格遵守編程規範。任何人都可以修改其他人寫的程式，修改後要確定新程式能通過單元測試。結對編程的好處是，一個人編寫代碼時另一個人在思考。思考者的頭腦中保持總體概念，不僅手頭問題的這一段，而且還有XP指導方針。例如，如果兩個人都在工作，就不太可能會有其中一個說“我不想首先寫測試”而離開。如果編碼者遇到障礙，他們就交換位置。如果兩個人都遇到障礙，他們的討論可能被在這個區域工作的其他人聽到，可能給出幫助。這種結對方式，使事情順暢、有章可循。也許更重要的是，他能使程式設計更具有社交性和娛樂性。
測試
既然測試很重要，XP就提倡在開始寫程式之前先寫單元測試。開發人員應該經常把開發好的模組整合到一起（ContinuousIntegration），每次整合後都要運行單元測試；做任何的代碼走查和修改，都要運行單元測試；發現了BUG，就要增加相應的測試（因此XP方法不需要BUG資料庫）。除了單元測試之外，還有集成測試，功能測試、壓力測試和系統測試等。所有這些測試，是XP開發過程中最重要的文檔之一，也是最終交付給用戶的內容之一 。
方法
基於敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐
團隊協作(Whole Team)
規劃策略(The Planning Game)；
結對編程(Pair programming)
測試驅動開發(Testing-Driven Development)
重構(Refactoring)
簡單設計(Simple Design)
代碼集體所有權(Collective Code Ownership)
持續集成(Continuous Integration)
客戶測試(Customer Tests)
小型發布（Small Release）
每周40小時工作制（40-hour Week）
編碼規範（Code Standards）
系統隱喻（System Metaphor）
極限編程的4個商業實踐：
•測試驅動開發—TDD是你的商業安全網。因為測試是在編碼之前完成的，所以寫完的測試一定會運行失敗，接下來再寫代碼使測試可以通過。TDD保證你的產品功能，不管公司和技術團隊實現的是大規模的變更還是小規模的變更。
•結對編程—讓2名開發人員寫同一段代碼，使用同一個鍵盤和同一台顯示器。因為結對大大降低了浪費的時間和缺陷，所以能帶來更高質量的代碼，並帶來高水平的協作。
•集體代碼所有制和持續集成—如果每段代碼不只有一個人熟悉，那么就不會有什麼交流瓶頸了。把代碼持續集成到一個主幹可以避免重複和不匹配的代碼。
•重構—在當時的情況下，寫的代碼是解決已知問題的。通常，團隊巧妙地解決了他們的問題，然後持續重構和修改代碼，確保代碼庫能以最為高效的方式不斷滿足業務最新的需要。
規則
項目開發小組
在XP中，每個對項目做貢獻的人都應該是項目開發小組中的一員。而且，這個小組中必須至少有一個人對用戶需求非常清晰，能夠提出需求、決定各個需求的商業價值（優先權）、根據需求等的變化調整項目計畫等。這個人扮演的是“客戶”這個角色，當然最好就是實際的最終用戶，因為整個項目就是圍繞最終用戶的需求而展開的。程式設計師是項目開發小組中必不可少的成員。小組中可以有測試員，他們幫助客戶制訂驗收測試；有分析員，幫助客戶確定需求；通常還有個Coach（教練），負責跟蹤開發進度、解決開發中遇到的一些問題、推動項目進行；還可以有一個項目經理，負責調配資源、協助項目內外的交流溝通等等。項目小組中有這么多角色，但並不是說，每個人做的工作是別人不能插手或干預的，XP鼓勵每個人儘可能地為項目多做貢獻。平等相處，取長補短；這就是最好的XP開發小組。
過程
計畫項目（PlanningGame）、驗收測試、小規模發布（SmallReleases）
XP開發小組使用簡單的方式進行項目計畫和開發跟蹤，並以此預測項目進展情況和決定未來的步驟。根據需求的商業價值，開發小組針對一組組的需求進行一系列的開發和整合，每次開發都會產生一個通過測試的、可以使用的系統。
計畫項目
XP的計畫過程主要針對軟體開發中的兩個問題：預測在交付日期前可以完成多少工作；現在和下一步該做些什麼。不斷的回答這兩個問題，就是直接服務於如何實施及調整開發過程；與此相比，希望一開始就精確定義整個開發過程要做什麼事情以及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP中又兩個主要的相應過程：
軟體發布計畫（ReleasePlanning）。客戶闡述需求，開發人員估算開發成本和風險。客戶根據開發成本、風險和每個需求的重要性，制訂一個大致的項目計畫。最初的項目計畫沒有必要（也沒有可能）非常準確，因為每個需求的開發成本、風險及其重要性都不是一成不變的。而且，這個計畫會在實施過程中被不斷地調整以趨精確。
周期開發計畫（IterationPlanning）。開發過程中，應該有很多階段計畫（比如每三個星期一個計畫）。開發人員可能在某個周期對系統進行內部的重整和最佳化（代碼和設計），而在某個周期增加了新功能，或者會在一個周期內同時做兩方面的工作。但是，經過每個開發周期，用戶都應該能得到一個已經實現了一些功能的系統。而且，每經過一個周期，客戶就會再提出確定下一個周期要完成的需求。在每個開發周期中，開發人員會把需求分解成一個個很小的任務，然後估計每個任務的開發成本和風險。這些估算是基於實際開發經驗的，項目做得多了，估算自然更加準確和精確；在同一個項目中，每經過一個開發周期，下一次的估算都會有更多的經驗、參照和依據，從而更加準確。這些簡單的步驟對客戶提供了豐富的、足夠的信息，使之能靈活有效地調控開發進程。每過兩三個星期，客戶總能夠實實在在地看到開發人員已經完成的需求。在XP里，沒有什麼“快要完成了”、“完成了90%”的模糊說法，要不是完成了，要不就是沒完成。這種做法看起來好像有利有弊：好處是客戶可以馬上知道完成了哪些、做出來的東西是否合用、下面還要做些什麼或改進什麼等等；壞處是客戶看到做出來的東西，可能會很不滿意甚至中止契約。實際上，XP的這種做法是為了及早發現問題、解決問題，而不是等到過了幾個月，用戶終於看到開發完的系統了，然後才告訴你這個不行、那個變了、還要增加哪個內容等等。
驗收測試
客戶對每個需求都定義了一些驗收測試。通過運行驗收測試，開發人員和客戶可以知道開發出來的軟體是否符合要求。XP開發人員把這些驗收測試看得和單元測試一樣重要。為了不浪費寶貴的時間，最好能將這些測試過程自動化。
頻繁地小規模發布軟體（SmallReleases）
每個周期（Iteration）開發的需求都是用戶最需要的東西。在XP中，對於每個周期完成時發布的系統，用戶都應該可以很容易地進行評估，或者已經能夠投入實際使用。這樣，軟體開發對於客戶來說，不再是看不見摸不著的東西，而是實實在在的。XP要求頻繁地發布軟體，如果有可能，應該每天都發布一個新版本；而且在完成任何一個改動、整合或者新需求後，就應該立即發布一個新版本。這些版本的一致性和可靠性，是靠驗收測試和測試驅動的開發來保證的。
簡單設計
XP中讓初學者感到最困惑的就是這點。XP要求用最簡單的辦法實現每個小需求，前提是按照這些簡單設計開發出來的軟體必須通過測試。這些設計只要能滿足系統和客戶在當下的需求就可以了，不需要任何畫蛇添足的設計，而且所有這些設計都將在後續的開發過程中就被不斷地重整和最佳化。
在XP中，沒有那種傳統開發模式中一次性的、針對所有需求的總體設計。在XP中，設計過程幾乎一直貫穿著整個項目開發：從制訂項目的計畫，到制訂每個開發周期（Iteration）的計畫，到針對每個需求模組的簡捷設計，到設計的覆核，以及一直不間斷的設計重整和最佳化。整個設計過程是個螺鏇式的、不斷前進和發展的過程。從這個角度看，XP是把設計做到了極致。
PairProgramming
XP中，所有的代碼都是由兩個程式設計師在同一台機器上一起寫的——這是XP中讓人爭議最多、也是最難實施的一點。這保證了所有的代碼、設計和單元測試至少被另一個人覆核過，代碼、設計和測試的質量因此得到提高。看起來這樣象是在浪費人力資源，但是各種研究表明事實恰恰相反。——這種工作方式極大地提高了工作強度和工作效率。
很多程式設計師一開始是被迫嘗試這點的（XP也需要行政命令的支持）。開始時總是不習慣的，而且兩個人的效率不會比一個人的效率高。這種做法的效果往往要堅持幾個星期或一兩個月後才能很顯著。據統計，在所有剛開始PairProgramming的程式設計師中，90%的人在兩個月以後都很認為這種工作方式更加高效。
項目開發中，每個人會不斷地更換合作編程的夥伴。因此，PairProgramming不但提高了軟體質量，還增強了相互之間的知識交流和更新，增強了相互之間的溝通和理解。這不但有利於個人，也有利於整個項目、開發隊伍和公司。從這點看，PairProgramming不僅僅適用於XP，也適用於所有其它的軟體開發方法。
測試驅動
反饋是XP的四個基本的價值觀之一——在軟體開發中，只有通過充分的測試才能獲得充分的反饋。XP中提出的測試，在其它軟體開發方法中都可以見到，比如功能測試、單元測試、系統測試和負荷測試等；與眾不同的是，XP將測試結合到它獨特的螺鏇式增量型開發過程中，測試隨著項目的進展而不斷積累。另外，由於強調整個開發小組擁有代碼，測試也是由大家共同維護的。即，任何人在往代碼庫中放程式（CheckIn）前，都應該運行一遍所有的測試；任何人如果發現了一個BUG，都應該立即為這個BUG增加一個測試，而不是等待寫那個程式的人來完成；任何人接手其他人的任務，或者修改其他人的代碼和設計，改動完以後如果能通過所有測試，就證明他的工作沒有破壞原系統。這樣，測試才能真正起到幫助獲得反饋的作用；而且，通過不斷地優先編寫和累積，測試應該可以基本覆蓋全部的客戶和開發需求，因此開發人員和客戶可以得到儘可能充足的反饋。
重構
XP強調簡單的設計，但簡單的設計並不是沒有設計的流水賬式的程式，也不是沒有結構、缺乏重用性的程式設計。開發人員雖然對每個USERSTORY都進行簡單設計，但同時也在不斷地對設計進行改進，這個過程叫設計的重構（Refactoring）。這個名字最早出現在MartinFowler寫的《Refactoring:Improving the Design of Existing Code》這本書中。
Refactoring主要是努力減少程式和設計中重複出現的部分，增強程式和設計的可重用性。Refactoring的概念並不是XP首創的，它已經被提出了近30年了，而且一直被認為是高質量的代碼的特點之一。但XP強調，把Refactoring做到極致，應該隨時隨地、儘可能地進行Refactoring，只要有可能，程式設計師都不應該心疼以前寫的程式，而要毫不留情地改進程式。當然，每次改動後，程式設計師都應該運行測試程式，保證新系統仍然符合預定的要求。
XP開發小組經常整合不同的模組。為了提高軟體質量，除了測試驅動開發和PairProgramming以外，XP要求每個人的代碼都要遵守編程規範，任何人都可以修改其他人寫的代碼，而且所有人都應該主動檢查其他人寫的代碼。
頻繁地整合
在很多項目中，開發人員往往很遲才把各個模組整合在一起。在這些項目中，開發人員經常在整合過程中發現很多問題，但不能肯定到底是誰的程式出了問題；而且，只有整合完成後，開發人員才開始稍稍使用整個系統，然後就馬上交付給客戶驗收。對於客戶來說，即使這些系統能夠通過終驗收測試，因為使用時間短，客戶門心裡並沒有多少把握。
為了解決這些問題，XP提出，整個項目過程中，應該頻繁地，儘可能地整合已經開發完的USERSTORY（每次整合一個新的USERSTORY）。每次整合，都要運行相應的單元測試和驗收測試，保證符合客戶和開發的要求。整合後，就發布一個新的套用系統。這樣，整個項目開發過程中，幾乎每隔一兩天，都會發布一個新系統，有時甚至會一天發布好幾個版本。通過這個過程，客戶能非常清楚地掌握已經完成的功能和開發進度，並基於這些情況和開發人員進行有效地、及時地交流，以確保項目順利完成。
集體擁有代碼
在很多項目開發過程中，開發人員只維護自己的代碼，而且很多人不喜歡其他人隨意修改自己的代碼。因此，即使可能有相應的比較詳細的開發文檔，但一個程式設計師卻很少、也不太願意去讀其他程式設計師的代碼；而且，因為不清楚其他人的程式到底實現了什麼功能，一個程式設計師一般也不敢隨便改動其他人的代碼。同時，因為是自己維護自己的代碼，可能因為時間緊張或技術水平的局限性，某些問題一直不能被發現或得到比較好的解決。針對這點，XP提倡大家共同擁有代碼，每個人都有權利和義務閱讀其他代碼，發現和糾正錯誤，重整和最佳化代碼。這樣，這些代碼就不僅僅是一兩個人寫的，而是由整個項目開發隊伍共同完成的，錯誤會減少很多，重用性會儘可能地得到提高，代碼質量是非常好。
為了防止修改其他人的代碼而引起系統崩潰，每個人在修改後都應該運行測試程式。（從這點，我們可以再次看到，XP的各個慣例和規則是怎樣有機地結合在一起的。）
編程規範
XP開發小組中的所有人都遵循一個統一的編程標準，因此，所有的代碼看起來好像是一個人寫的。因為有了統一的編程規範，每個程式設計師更加容易讀懂其他人寫的代碼，這是實現CollectiveCodeOwnership的重要前提之一。
每周40小時工作制（40-hour Week），不加班
XP過程通過使用一些形象的比喻讓所有人對系統有個共同的、簡潔的認識。XP認為加班是不正常的，因為這說明關於項目進度的估計和安排有問題。
Metaphor（系統比喻）
為了幫助每個人一致清楚地理解要完成的客戶需求、要開發的系統功能，XP開發小組用很多形象的比喻來描述系統或功能模組是怎樣工作的。比如，對於一個搜尋引擎，它的Metaphor可能就是“一大群蜘蛛，在網上四處尋找要捕捉的東西，然後把東西帶回巢穴。”
其他相關
大量的加班意味著原來的計畫是不準確的，或者是程式設計師不清楚自己到底什麼時候能完成什麼工作。而且，開發管理人員和客戶也因此無法準確掌握開發速度；開發人員也因此非常疲勞。XP認為，如果出現大量的加班現象，開發管理人員（比如Coach）應該和客戶一起確定加班的原因，並及時調整項目計畫、進度和資源。
XP中一些基本概念的簡介
UserStory：開發人員要求客戶把所有的需求寫成一個個獨立的小故事，每個只需要幾天時間就可以完成。開發過程中，客戶可以隨時提出新的UserStory，或者更改以前的UserStory。
StoryEstimates和開發速度：開發小組對每個UserStory進行估算，並根據每個開發周期（Iteration）中的實際情況反覆計算開發速度。這樣，開發人員和客戶能知道每個星期到底能開發多少UserStory。
ReleasePlan和ReleaseScope：整個開發過程中，開發人員將不斷地發布新版本。開發人員和客戶一起確定每個發布所包含的UserStory。
Iteration（開發周期，或稱疊代）和IterationPlan：在一個Release過程中，開發人員要求客戶選擇最有價值的UserStory作為未來一兩個星期的開發內容。
TheSeed：第一個疊代（Iteration）完成後，提交給客戶的系統。雖然這不是最終的產品，但它已經實現了幾個客戶認為是最重要的Story，開發人員將逐步在其基礎上增加新的模組。
ContinuousIntegration（整合）：把開發完的UserStory的模組一個個拼裝起來，一步步接近乃至最終完成最終產品。
驗收測試（功能測試）：對於每個UserStory，客戶將定義一些測試案例，開發人員將使運行這些測試案例的過程自動化。
UnitTest（單元測試）：在開始寫程式前，程式設計師針對大部分類的方法，先寫出相應的測試程式。
Refactoring(重構)：去掉代碼中的冗餘部分，增加代碼的可重用性和伸縮性。
影響
通過軟體工程設計的簡單而優美的軟體並不比那些設計複雜而難以維護的軟體有價值。這是真的嗎？XP認為事實並非如此。 一個典型的項目花在人力上的金錢是花在硬體上的時間的20 倍，這意味著一個項目每年要花200 萬美元在程式設計師身上，而僅僅花10 萬美元在電腦設備上。很多聰明的程式設計師說：“我們如此聰明，發現一種方法可以節省20%的硬體開銷”，然後他們使得源程式大而且難懂和難以維護，他們會說：“但是我們節省了20%或者2 萬美元每年，很大的節省”。反之，如果我們寫我們的程式簡單而且容易擴展，我們將至少節省10%的人力開銷，一筆更大的節省，這是你客戶一定會注意到的一些事情。
另外一個對客戶來說很重要的問題就是程式的BUGS 。XP 不只是強調測試，而且要求正確的測試。測試必須是能自動進行的，以便為程式和客戶提供一個安全的環境。在編碼的所有階段，我們不斷增加測試用例。當找到bug 時，我們就添加新的測試，一個緊密的安全網就這樣產生了。同一個BUG 不出現兩次，這些一定會引起用戶的注意。你的客戶必須注意的另外一件事情：XP 開發者擁抱需求變化。XP 使我們能夠接受需求的變化。
一般情況下，客戶只有在系統被開發完成以後能真正去體會它。XP 卻不一樣，它通過加強客戶的反饋來縮短開發的周期，同時獲得足夠的時間來改變功能和獲得用戶的認同。在XP 中，你的客戶應該明確的知道這一點。
XP開發過程的大多的革命是在軟體開發的方法上，代碼質量的重要程度超出人們一般所認為的。僅僅因為我們的客戶不能明白我們的原始碼並不意味著我們可以不努力去管理代碼的質量。
使用
XP方法的產生是因為難以管理的需求變化，從一開始你的客戶並不是很完全的知道他們要的系統是怎么樣的，你可能面對的系統的功能一個月變化多次。在大多數軟體開發環境中不斷變化的需求是唯一的不變，這個時候套用XP 就可以取得別的方法不可能取得的成功。XP 方法的建立同時也是為了解決軟體開發項目中的風險問題。假如你的客戶在特定的時間內，需要一個相當難開發的系統，而且對於你的項目組來說，這個系統是一個新的挑戰（從來沒有做過），那風險就更大了，如果這個系統對於整個軟體行業來說都是新的挑戰，那么它的風險就更大了，採用XP 將可以減少風險，增加成功的可能。 XP方法是為小團體開發建立的，在2-10 個人之間。假如你的團體恰好合適，你就不需要用其他的軟體工程方法了，就用XP ，但是要注意你不能將XP 方法套用於大團體的開發項目中。我們應該注意，在需求一慣呈動態變化或者高具有高風險的項目中，你就會發現XP 方法在小團體的開發中的作用要遠遠高於在大團體的開發。
XP方法需要一個擴展的開發團體，XP 團體不僅僅包括開發者，經理、客戶也是其中的一員，所有的工作一環扣一環，問問題，商討方法和日程，增加功能測試，這些問題的解決不僅僅涉及到軟體的開發者。
另一個需要是可測試性，你必須能增加自動的單元測試和功能測試，然而在你進行這個需求的時候，你會發現有許多的問題很難測試，這需要充分發揮你的測試的經驗和智慧，而且你有時還要改變你的設計以便它可以更容易的進行測試。記住：那兒有需求，那兒就應該有測試的方法。
在XP方法的好處的清單上，最後一條是生產力。在同樣的合作環境下，XP 項目都一致的表現出比使用其他方法高的多的生產力。但這從來不是XP 方法學的真正目標。XP 真實追求的目標是：在規定的時間生產出滿足客戶需要的軟體。假如對於你的開發來說，這是很重要的方面，你就可以選擇XP 了。
實踐
1、完整團隊
XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。
2、計畫遊戲
計畫是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
3、客戶測試
作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。
4、簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含儘可能少的代碼。
5、結對編程
所有的產品軟體都是由兩個程式設計師、並排坐在一起在同一台機器上構建的。
6、測試驅動開發
編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功能驗證方面的反饋循環。程式設計師以非常短的循環周期工作，他們先增加一個失敗的測試，然後使之通過。
7、改進設計
隨時利用重構方法改進已經腐化的代碼，保持代碼儘可能的乾淨、具有表達力。
8、持續集成
團隊總是使系統完整地被集成。一個人拆入（Check in）後，其它所有人責任代碼集成。
9、集體代碼所有權
任何結對的程式設計師都可以在任何時候改進任何代碼。沒有程式設計師對任何一個特定的模組或技術單獨負責，每個人都可以參與任何其它方面的開發。
10、編碼標準
系統中所有的代碼看起來就好像是被單獨一人編寫的。
11、隱喻
將整個系統聯繫在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模組的位置和外觀變得明顯直觀。如果模組的外觀與整個隱喻不符，那么你就知道該模組是錯誤的。
12、可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
小結
XP的一個成功因素是重視客戶的反饋——開發的目的就是為了滿足客戶的需要。XP方法使開發人員始終都能自信地面對客戶需求的變化。XP強調團隊合作，經理、客戶和開發人員都是開發團隊中的一員。團隊通過相互之間的充分交流和合作，使用XP這種簡單但有效的方式，努力開發出高質量的軟體。XP的設計簡單而高效；程式設計師們通過測試獲得客戶反饋，並根據變化修改代碼和設計，他們總是爭取儘可能早地將軟體交付給客戶。XP程式設計師能夠勇於面對需求和技術上的變化。
XP很象一個由很多小塊拼起來的智力拚圖，單獨看每一小塊都沒有什麼意義，但拼裝好後，一幅美麗的圖畫就會呈現在你面前。
