極限程式設計(extreme programming)是一種開發紀律，以簡單性、交流、反饋和勇氣為基本宗旨。它的做法是以有效的實踐規則將整個團隊緊密聯絡起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當的調節規則以適應自己的特殊情況。
在極限程式設計中，每乙個專案貢獻者都是「團隊」完整的一部分。這個隊伍是圍繞著乙個每天和隊伍坐在一起共同工作的商業代表——「客戶」建立起來的。
核心實踐：整體團隊
極限程式設計的隊伍採用一種簡單的方式來進行規劃和跟蹤，以決定下一步要做什麼和預知專案什麼時候會完成。聚焦於商業價值，團隊通過一系列的通過了客戶定義的測試和完全整合的小的發布來創作軟體系統。
核心實踐：規劃策略，小發行版，客戶測試
極限程式設計者通過成對和小組的方式共同工作，通過簡單設計和強制測試的**，不斷的提公升設計以保證設計總是適合當前的需求。
核心實踐：簡單設計，成對程式設計，測試優先開發，設計改進
極限程式設計隊伍會總是保持系統能夠整合並且在所有的時間執行。程式設計師以成對的方式編寫所有的產品**，並且在所有時間內都共同工作。他們以相似的形式編碼以保證所有成員都可以按需要理解和改進所有的**。
核心實踐：持續整合，集體**所有權，編碼標準
極限程式設計隊伍分享乙個公共並且簡單的系統藍圖。所有成員可以按照一種不時保持同步的節奏進行工作。
核心實踐：系統比喻，可接受的步伐
核心實踐
團隊整體
乙個xp專案的所有參與者都作為乙個團隊的成員坐在一起。這個團隊必須包括乙個業務的代表——「客戶」，他提供需求，設定優先度，並掌管整個專案的方向。最好這個客戶或者他的助手是乙個終端使用者，了解該領域，知道什麼是所需要的。團隊當然還要有程式設計師。團隊可能會包含測試員，他幫助客戶定義客戶驗收測試。分析員可以作為客戶的助手，幫助客戶定義需求。通常還會有乙個指導,他幫助整個團隊跟蹤、推動開發程序。也可能會有乙個管理者，他提供資源、處理對外交流和分工協作。這些職責中沒有任何乙個是必須某個個人獨有的：每乙個xp團隊的成員都以任何他們所能做到的方式參與，最好的團隊沒有專家，只有一些有著特殊的技能的一般的參與者。
規劃策略
xp的計畫解決軟體開發中的兩個關鍵問題：預知在責任期內哪些東西將被完成，並且確定下一步需要做什麼。重點是把握專案的正確軌道——這是相當簡單明瞭的——更勝於希望精確預知哪些東西將會需要以及可能花費多少時間——這是相當困難的。在xp這裡有兩個關鍵的規劃步驟，用來解決這兩個問題：
發布計畫是乙個實踐讓客戶向程式設計師們演示所希望獲得的特性，然後程式設計師們評估它們的難度。當手中有了代價的評估和這些特性的重要程式的認知之後，客戶安排乙個專案計畫。最初的發布計畫需要留有足夠的餘地：優先順序以及評估都不是真實可靠的，並且知道團隊開始工作以前，我們都無法確切地了解隊伍的開發進度。甚至最初的發布計畫也不是足夠精確能進行決斷，所以xp隊伍通常會不時地校正發布計畫。
迭代計畫是乙個實踐籍此可以為團隊提供每幾個開發周的導向。xp隊伍通過兩周的「迭代」來建立軟體系統，在每乙個迭代結束時提供可以執行的有實際用途的軟體系統。在進行迭代計畫時，客戶演示下兩周內希望完成的特性。程式設計師們將它們分割成若干個任務，並且評估它們的成本（比發布計畫要細緻一些）。基於在之前的迭代中完成的工作，團隊簽定當前迭代中將要承擔的工作。
這些計畫十分的簡單，然而他們為客戶提供了非常好的資訊和極好的操縱控制。每隔幾周，多少進展都可以一目了然。在xp中沒有「百分之九十完成」：乙個特性故事要麼完成了，要麼沒有完成。關注可視結果方法在於乙個很好的小的對立論點：一方面來說，非常直觀地，如果進度不能令人滿意，客戶可以在某乙個位置取消專案。從另一方面說，進度是顯而易見地，並且判斷哪些東西將會完成的能力是很完善的，因此xp專案往往可以在較少的壓力下完成更多的需要的東西。
客戶測試
作為每乙個所要求特性的演示的一部分，xp客戶定義乙個或者多個自動進行的接受測試來表明特性已經能夠實現。團隊實現這些測試並且用它們來向自己和客戶證明特性已經被正確的實現了。由於時間的壓力，自動化是很重要的，手工測試將被跳過。這就像當黑夜來臨的時候，就可以關掉你的燈一樣。
最好的xp團隊會將他們的客戶測試當作程式設計師的測試一樣對待：一旦測試執行了，從此之後團隊會保持它能夠一直正確執行。這意味著系統只能夠被改進，總是向前的，從不會倒退。
小發行版本
xp團隊通過兩個重要的方式實踐小發行版本：
第一，團隊在每乙個迭代發布可以執行的，測試過的軟體系統，提供客戶選擇的商業價值。客戶可以為任何目的使用這個軟體系統，無論是評估還是發布給終端使用者（強烈推薦）。最重要的方式是在每乙個迭代結束的時候軟體系統是可見的，並且提交給了客戶。這保證了任何事情都是公開和真實的。
第二，xp團隊盡可能頻繁地發布給他們的終端使用者。xp**專案每天都進行發布，居家專案則每月或者更頻繁地發布。甚至可以簡包裝的產品可以每季度地發運。
這麼頻繁地建立好的版本也許顯得不太可能，但是xp團隊每時每刻都在進行著發布。更多資訊可以參看持續整合，並請注意這些頻繁的發布通過xp中隨處可見的測試（如同客戶測試和測試優先開發中所描述的）變得現實了。
簡單設計
xp團隊建構軟體系統為乙個簡單的設計。他們從簡單開始，並且在整個程式設計師測試和設計改進過程中，他們保持著簡單的設計。乙個xp團隊保持著設計總是剛好適合系統當前的功能要求。這裡沒有多餘的投入，並且軟體系統總是為將來做好了準備。
成對程式設計
在xp所有的產品軟體都是由兩個程式設計師併排坐在一起，在同一臺機器上共同完成的。這個實踐保證了所有的產品**都至少有乙個其它的程式設計師進行了審視，而結果是更好的設計，更好的測試和更好的**。
讓兩個程式設計師去做「乙個程式設計師的工作」看起來有些效率低下，但是實際上剛好相反。研究表明成對程式設計在讓程式設計師們單獨工作相同的時間內會得到更好的**。這證明了：兩個頭腦加在一起比乙個好得多！
很多程式設計師在還沒有嘗試過的情況下就反對成對程式設計。這確實需要一些實踐來做好它，而且你需要認真地實踐數週以上的時間來看到結果。百分之九十的學習過成對程式設計的程式設計師都會喜歡這樣，因此我們向所有的團隊強烈推薦它。
除開提供更好的**和測試之外，成隊也提供了知識在團隊中間傳遞。當成對地程式設計師交換夥伴時，每個人都會從其它的某個人那裡學到新的知識。程式設計師們在學習，他們的技術在提高，他們對團隊和公司來講變得更有價值。成對，即使它本身在xp過程之外實施，也是每個人的巨大成功。
測試優先開發
僅僅寫了測試程式還是不夠的：你必須要執行它們。這裡，極限程式設計也是極端的。這些「程式設計師測試」，或者說「單元測試」是乙個完整的集合，每當程式設計師們發布任何**到**庫的時候（成對的程式設計師通常每天發布兩次或者更多次），每乙個程式設計師測試必須能夠正確的執行。每時每刻都是百分之百執行！這意味著程式設計師們可以立刻得到有關他們做得究竟如何的反饋。進一步說，這些測試提供了軟體設計改進時無價的支援。
設計改進
極限程式設計在每乙個迭代都關注於提供商業價值。為了在整個專案過程中完成這個目標，軟體系統必須有良好的設計。可選擇性可能會降低並且最終停滯。因此xp採用一種持續改進設計的過程，稱為「重構」，來自於martin fowler 的書名，「重構：改進現有**的設計」。
重構的過程關注在去掉重複（乙個低劣設計的明確標誌），以及提高**的「內聚」，還有減少「耦合」。高內聚和低耦合在最近三十年以來被公認為是良好設計的特點。結果就是xp團隊從乙個好的簡單的設計出發，並且總是讓軟體系統有乙個好的簡單的設計。這讓他們能保持他們的開發速度，並且通常在實際上提高了專案開發速度。
重構自然是通過全面的測試來提供有力的支援的，這些測試用來確認當設計改變的時候不會破壞系統中的任何東西。因此客戶測試和程式設計師測試都是有效的評價因素。xp的實踐是相互支援的：他們會比各自獨立時更為強壯。
持續整合
極限程式設計隊伍總是保持的系統完全地整合在一起。我們說每日建構版本是為弱者提供的：xp團隊每天都要構建系統很多次。（乙個40人的xp團隊每天至少整合八到十次！）
這個實踐的好處可以通過回想你可能聽說過的（或者是親身參與過的）專案來了解：當系統構建是每週或以更低的頻率進行時，通常會陷入「整合的地獄」，在那裡所有東西都不能執行而且沒有人知道為什麼。
極少進行整合會給軟體專案帶來一系列的問題。第乙個，儘管整合是發行好的工作**的條件， 但是團隊並不去實踐它，而且通常它被委派給那些對整個系統並不十分了解的人。第二，極少整合的**通常是——我寧願說總是——錯漏百出。
集體**所有權
在乙個極限程式設計專案中，每一對程式設計師都可以在任何時候改進任何一處的**。這意味著所有的**在很多人的關注下獲得更多的收益，這樣就提公升了**質量並且減少了缺陷。這裡還有另外乙個重要的好處：當**僅由單個人負責的時候，要求的特性往往會放到了錯誤的位置，因為乙個程式設計師發現他需要乙個特性但是那段**卻不歸他管理。**的所有者太忙樂而不能去增加這個特性，所以這個程式設計師只好把這個特性加進了這個特性本不應該存在的他自己的**中。這導致了難看的，難於維護到**，充斥著重複和低（差）的內聚。
如果有人在他們所不理解的**上進行盲目的修改時，集體**所有權可能帶來問題。xp通過兩種關鍵技術來避免這類的問題：通過程式設計師測試來捕獲錯誤，成對程式設計則表明在不熟悉的**上工作的時候最佳途徑是找乙個這方面的專家作為夥伴。為了確保在需要是進行好的修改，這種實踐將知識延伸到了整個團隊。
編碼標準
xp團隊遵循乙個公共的編碼標準，因此系統中所有的**看上去都像出自單獨乙個——非常有能力的——人之手。這個標準的規定並不重要：重要的是要讓所有的**看上去很相似，用來支援集體**所有權。
系統比喻
極限程式設計團隊對於程式如何運作形成乙個共識，我們稱之為「系統比喻」。在最佳狀態時，系統比喻是關於程式如何運作的乙個簡單的靈魂描述，例如用「這個程式工作時就像一箱子蜜蜂，外出尋找花粉並帶回蜂箱」作為乙個基於**的資訊查詢系統的描述。
有些時候乙個十分詩意的想象可能不會出現。在任何情況下，無論有沒有生動的比喻，xp團隊都會選用乙個公共的命名系統來確保每個人都能理解系統是如何工作的，以及到**去找到你所需要的功能，或者找到你要增加功能的正確位置。
可接受的步伐
極限程式設計團隊都會在這裡很長的一段時間。他們努力的工作，並且在乙個能夠不斷維持的步伐下。這意味著在有效的時候他們會加班工作，而且他們經常這樣工作來保證每週都有最大的生產力。這恰當的解釋了死亡競賽式的專案既不會有生產力也不會創造有質量的軟體系統。xp團隊在這裡是要勝利而不是要死亡。
小結極限程式設計是一種以簡單性、交流、反饋和勇氣為基本宗旨的開發紀律。它的做法是以有效的實踐規則將整個團隊緊密聯絡起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當地調節實踐規則以適應自己的特殊情況。
挑戰極限 極限程式設計中的「極限」
最近，一直在看robert martin的 敏捷軟體開發 原則 模式和實踐 該文中以極限程式設計 xp 來講述敏捷的實踐。看完有關於 xp實踐的部分，對 xp基本的主張和如何去實踐有了乙個大概的了解。但是，一直有個問題在我腦海中，那就是這種開發實踐方式為什麼會被稱為 極限程式設計 看完這部分之後，對...
極限程式設計下的極限測試
極限測試主要由兩部分測試組成 單元測試和驗收測試。單元測試是極限測試中主要採用的測試方法，它具有兩條簡單規則 所有 模組在編碼開始之前必須設計好單元測試用例。在產品發布之前需要通過單元測試。極限測試中的單元測試和普通的單元測試之間最大的區別是 極限測試中的單元測試必須在模組編碼之前就完成設計和生成。...
XP極限程式設計
結隊程式設計是xp極限程式設計的乙個關鍵實踐，如果把結隊程式設計放到整個xp裡面會更容易體現出它的價值，所以我覺得分析結隊程式設計的乙個整體思路是 1 適用場景 xp的適用性在 什麼樣的專案中適合採用xp，在這樣的專案中xp可以起到什麼作用。如果離開了適用場景，xp的適用性都要重新考慮，所以就更不用...