極限編程(eXtreme Programming)是一種開發(fā)紀(jì)律，以簡單性、交流、反饋和勇氣為基本宗旨。它的做法是以有效的實踐規(guī)則將整個團隊緊密聯(lián)系起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當(dāng)?shù)恼{(diào)節(jié)規(guī)則以適應(yīng)自己的特殊情況。
在極限編程中，每一個項目貢獻者都是“團隊”完整的一部分。這個隊伍是圍繞著一個每天和隊伍坐在一起共同工作的商業(yè)代表——“客戶”建立起來的。
核心實踐：整體團隊
極限編程的隊伍采用一種簡單的方式來進行規(guī)劃和跟蹤，以決定下一步要做什么和預(yù)知項目什么時候會完成。聚焦于商業(yè)價值，團隊通過一系列的通過了客戶定義的測試和完全集成的小的發(fā)布來創(chuàng)作軟件系統(tǒng)。
核心實踐：規(guī)劃策略，小發(fā)行版，客戶測試
極限編程者通過成對和小組的方式共同工作，通過簡單設(shè)計和強制測試的代碼，不斷的提升設(shè)計以保證設(shè)計總是適合當(dāng)前的需求。
核心實踐：簡單設(shè)計，成對編程，測試優(yōu)先開發(fā)，設(shè)計改進
極限編程隊伍會總是保持系統(tǒng)能夠集成并且在所有的時間運行。程序員以成對的方式編寫所有的產(chǎn)品代碼，并且在所有時間內(nèi)都共同工作。他們以相似的形式編碼以保證所有成員都可以按需要理解和改進所有的代碼。
核心實踐：持續(xù)集成，集體代碼所有權(quán)，編碼標(biāo)準(zhǔn)
極限編程隊伍分享一個公共并且簡單的系統(tǒng)藍圖。所有成員可以按照一種不時保持同步的節(jié)奏進行工作。
核心實踐：系統(tǒng)比喻，可接受的步伐
核心實踐
團隊整體
一個XP項目的所有參與者都作為一個團隊的成員坐在一起。這個團隊必須包括一個業(yè)務(wù)的代表——“客戶”，他提供需求，設(shè)置優(yōu)先度，并掌管整個項目的方向。最好這個客戶或者他的助手是一個最終用戶，了解該領(lǐng)域，知道什么是所需要的。團隊當(dāng)然還要有程序員。團隊可能會包含測試員，他幫助客戶定義客戶驗收測試。分析員可以作為客戶的助手，幫助客戶定義需求。通常還會有一個指導(dǎo),他幫助整個團隊跟蹤、推動開發(fā)進程。也可能會有一個管理者，他提供資源、處理對外交流和分工協(xié)作。這些職責(zé)中沒有任何一個是必須某個個人獨有的：每一個XP團隊的成員都以任何他們所能做到的方式參與，最好的團隊沒有專家，只有一些有著特殊的技能的一般的參與者。
規(guī)劃策略
XP的計劃解決軟件開發(fā)中的兩個關(guān)鍵問題：預(yù)知在責(zé)任期內(nèi)哪些東西將被完成，并且確定下一步需要做什么。重點是把握項目的正確軌道——這是相當(dāng)簡單明了的——更勝于希望精確預(yù)知哪些東西將會需要以及可能花費多少時間——這是相當(dāng)困難的。在XP這里有兩個關(guān)鍵的規(guī)劃步驟，用來解決這兩個問題：
發(fā)布計劃是一個實踐讓客戶向程序員們演示所希望獲得的特性，然后程序員們評估它們的難度。當(dāng)手中有了代價的評估和這些特性的重要程序的認(rèn)知之后，客戶安排一個項目計劃。最初的發(fā)布計劃需要留有足夠的余地：優(yōu)先級以及評估都不是真實可靠的，并且知道團隊開始工作以前，我們都無法確切地了解隊伍的開發(fā)進度。甚至最初的發(fā)布計劃也不是足夠精確能進行決斷，所以XP隊伍通常會不時地校正發(fā)布計劃。
迭代計劃是一個實踐籍此可以為團隊提供每幾個開發(fā)周的導(dǎo)向。XP隊伍通過兩周的“迭代”來建立軟件系統(tǒng)，在每一個迭代結(jié)束時提供可以運行的有實際用途的軟件系統(tǒng)。在進行迭代計劃時，客戶演示下兩周內(nèi)希望完成的特性。程序員們將它們分割成若干個任務(wù)，并且評估它們的成本（比發(fā)布計劃要細致一些）。基于在之前的迭代中完成的工作，團隊簽定當(dāng)前迭代中將要承擔(dān)的工作。
這些計劃十分的簡單，然而他們?yōu)榭蛻籼峁┝朔浅：玫男畔⒑蜆O好的操縱控制。每隔幾周，多少進展都可以一目了然。在XP中沒有“百分之九十完成”：一個特性故事要么完成了，要么沒有完成。關(guān)注可視結(jié)果方法在于一個很好的小的對立論點：一方面來說，非常直觀地，如果進度不能令人滿意，客戶可以在某一個位置取消項目。從另一方面說，進度是顯而易見地，并且判斷哪些東西將會完成的能力是很完善的，因此XP項目往往可以在較少的壓力下完成更多的需要的東西。
客戶測試
作為每一個所要求特性的演示的一部分，XP客戶定義一個或者多個自動進行的接受測試來表明特性已經(jīng)能夠?qū)崿F(xiàn)。團隊實現(xiàn)這些測試并且用它們來向自己和客戶證明特性已經(jīng)被正確的實現(xiàn)了。由于時間的壓力，自動化是很重要的，手工測試將被跳過。這就像當(dāng)黑夜來臨的時候，就可以關(guān)掉你的燈一樣。
最好的XP團隊會將他們的客戶測試當(dāng)作程序員的測試一樣對待：一旦測試運行了，從此之后團隊會保持它能夠一直正確運行。這意味著系統(tǒng)只能夠被改進，總是向前的，從不會倒退。
小發(fā)行版本
XP團隊通過兩個重要的方式實踐小發(fā)行版本：
第一，團隊在每一個迭代發(fā)布可以運行的，測試過的軟件系統(tǒng)，提供客戶選擇的商業(yè)價值?？蛻艨梢詾槿魏文康氖褂眠@個軟件系統(tǒng)，無論是評估還是發(fā)布給最終用戶（強烈推薦）。最重要的方式是在每一個迭代結(jié)束的時候軟件系統(tǒng)是可見的，并且提交給了客戶。這保證了任何事情都是公開和真實的。
第二，XP團隊盡可能頻繁地發(fā)布給他們的最終用戶。XP網(wǎng)站項目每天都進行發(fā)布，居家項目則每月或者更頻繁地發(fā)布。甚至可以簡包裝的產(chǎn)品可以每季度地發(fā)運。
這么頻繁地創(chuàng)建好的版本也許顯得不太可能，但是XP團隊每時每刻都在進行著發(fā)布。更多信息可以參看持續(xù)集成，并請注意這些頻繁的發(fā)布通過XP中隨處可見的測試（如同客戶測試和測試優(yōu)先開發(fā)中所描述的）變得現(xiàn)實了。
簡單設(shè)計
XP團隊建構(gòu)軟件系統(tǒng)為一個簡單的設(shè)計。他們從簡單開始，并且在整個程序員測試和設(shè)計改進過程中，他們保持著簡單的設(shè)計。一個XP團隊保持著設(shè)計總是剛好適合系統(tǒng)當(dāng)前的功能要求。這里沒有多余的投入，并且軟件系統(tǒng)總是為將來做好了準(zhǔn)備。
在XP中設(shè)計并不是一次性完成的事情，也不是一件從上到下的事情，它是自始至終的事情。在發(fā)布計劃和迭代計劃中都有設(shè)計的步驟，在快速設(shè)計過程中集合了團隊的能力并且在整個項目過程地構(gòu)中改進設(shè)計。在類似于極端編程這樣的遞增和迭代過程中，良好的設(shè)計是本質(zhì)。這是在整個開發(fā)過程中必須更多的關(guān)注設(shè)計的原因。
成對編程
在XP所有的產(chǎn)品軟件都是由兩個程序員并排坐在一起，在同一臺機器上共同完成的。這個實踐保證了所有的產(chǎn)品代碼都至少有一個其它的程序員進行了審視，而結(jié)果是更好的設(shè)計，更好的測試和更好的代碼。
讓兩個程序員去做“一個程序員的工作”看起來有些效率低下，但是實際上剛好相反。研究表明成對編程在讓程序員們單獨工作相同的時間內(nèi)會得到更好的代碼。這證明了：兩個頭腦加在一起比一個好得多！
很多程序員在還沒有嘗試過的情況下就反對成對編程。這確實需要一些實踐來做好它，而且你需要認(rèn)真地實踐數(shù)周以上的時間來看到結(jié)果。百分之九十的學(xué)習(xí)過成對編程的程序員都會喜歡這樣，因此我們向所有的團隊強烈推薦它。
除開提供更好的代碼和測試之外，成隊也提供了知識在團隊中間傳遞。當(dāng)成對地程序員交換伙伴時，每個人都會從其它的某個人那里學(xué)到新的知識。程序員們在學(xué)習(xí)，他們的技術(shù)在提高，他們對團隊和公司來講變得更有價值。成對，即使它本身在XP過程之外實施，也是每個人的巨大成功。
測試優(yōu)先開發(fā)
極端編程圍繞著反饋，而在軟件開發(fā)中，好的反饋需要好的測試。最優(yōu)秀的XP團隊實踐“測試優(yōu)先開發(fā)”，在一個很小的循環(huán)中增加一個測試，然后讓它能夠工作。幾乎是輕而易舉的，團隊提供的代碼接近100%都有測試程序覆蓋著，在絕大多數(shù)情況下這是很重要的進步。（如果你的程序員已經(jīng)提供了更多的現(xiàn)有測試程序，你會擁有更多的力量。將它們保存下來，他們只會提供幫助的！）
僅僅寫了測試程序還是不夠的：你必須要運行它們。這里，極限編程也是極限的。這些“程序員測試”，或者說“單元測試”是一個完整的集合，每當(dāng)程序員們發(fā)布任何代碼到代碼庫的時候（成對的程序員通常每天發(fā)布兩次或者更多次），每一個程序員測試必須能夠正確的運行。每時每刻都是百分之百運行！這意味著程序員們可以立刻得到有關(guān)他們做得究竟如何的反饋。進一步說，這些測試提供了軟件設(shè)計改進時無價的支持。
設(shè)計改進
極限編程在每一個迭代都關(guān)注于提供商業(yè)價值。為了在整個項目過程中完成這個目標(biāo)，軟件系統(tǒng)必須有良好的設(shè)計?？蛇x擇性可能會降低并且最終停滯。因此XP采用一種持續(xù)改進設(shè)計的過程，稱為“重構(gòu)”，來自于Martin Fowler 的書名，“重構(gòu)：改進現(xiàn)有代碼的設(shè)計”。
重構(gòu)的過程關(guān)注在去掉重復(fù)（一個低劣設(shè)計的明確標(biāo)志），以及提高代碼的“內(nèi)聚”，還有減少“耦合”。高內(nèi)聚和低耦合在最近三十年以來被公認(rèn)為是良好設(shè)計的特點。結(jié)果就是XP團隊從一個好的簡單的設(shè)計出發(fā)，并且總是讓軟件系統(tǒng)有一個好的簡單的設(shè)計。這讓他們能保持他們的開發(fā)速度，并且通常在實際上提高了項目開發(fā)速度。
重構(gòu)自然是通過全面的測試來提供有力的支持的，這些測試用來確認(rèn)當(dāng)設(shè)計改變的時候不會破壞系統(tǒng)中的任何東西。因此客戶測試和程序員測試都是有效的評價因素。XP的實踐是相互支持的：他們會比各自獨立時更為強壯。
持續(xù)集成
極限編程隊伍總是保持的系統(tǒng)完全地集成在一起。我們說每日建構(gòu)版本是為弱者提供的：XP團隊每天都要構(gòu)建系統(tǒng)很多次。（一個40人的XP團隊每天至少集成八到十次?。?div style="height:15px;">
這個實踐的好處可以通過回想你可能聽說過的（或者是親身參與過的）項目來了解：當(dāng)系統(tǒng)構(gòu)建是每周或以更低的頻率進行時，通常會陷入“集成的地獄”，在那里所有東西都不能運行而且沒有人知道為什么。
極少進行集成會給軟件項目帶來一系列的問題。第一個，盡管集成是發(fā)行好的工作代碼的條件， 但是團隊并不去實踐它，而且通常它被委派給那些對整個系統(tǒng)并不十分了解的人。第二，極少集成的代碼通常是——我寧愿說總是——錯漏百出。
在一個極限編程項目中，每一對程序員都可以在任何時候改進任何一處的代碼。這意味著所有的代碼在很多人的關(guān)注下獲得更多的收益，這樣就提升了代碼質(zhì)量并且減少了缺陷。這里還有另外一個重要的好處：當(dāng)代碼僅由單個人負責(zé)的時候，要求的特性往往會放到了錯誤的位置，因為一個程序員發(fā)現(xiàn)他需要一個特性但是那段代碼卻不歸他管理。代碼的所有者太忙樂而不能去增加這個特性，所以這個程序員只好把這個特性加進了這個特性本不應(yīng)該存在的他自己的代碼中。這導(dǎo)致了難看的，難于維護到代碼，充斥著重復(fù)和低（差）的內(nèi)聚。
如果有人在他們所不理解的代碼上進行盲目的修改時，集體代碼所有權(quán)可能帶來問題。XP通過兩種關(guān)鍵技術(shù)來避免這類的問題：通過程序員測試來捕獲錯誤，成對編程則表明在不熟悉的代碼上工作的時候最佳途徑是找一個這方面的專家作為伙伴。為了確保在需要是進行好的修改，這種實踐將知識延伸到了整個團隊。
XP團隊遵循一個公共的編碼標(biāo)準(zhǔn)，因此系統(tǒng)中所有的代碼看上去都像出自單獨一個——非常有能力的——人之手。這個標(biāo)準(zhǔn)的規(guī)定并不重要：重要的是要讓所有的代碼看上去很相似，用來支持集體代碼所有權(quán)。
極限編程團隊對于程序如何運作形成一個共識，我們稱之為“系統(tǒng)比喻”。在最佳狀態(tài)時，系統(tǒng)比喻是關(guān)于程序如何運作的一個簡單的靈魂描述，例如用“這個程序工作時就像一箱子蜜蜂，外出尋找花粉并帶回蜂箱”作為一個基于代理的信息查詢系統(tǒng)的描述。
有些時候一個十分詩意的想象可能不會出現(xiàn)。在任何情況下，無論有沒有生動的比喻，XP團隊都會選用一個公共的命名系統(tǒng)來確保每個人都能理解系統(tǒng)是如何工作的，以及到哪里去找到你所需要的功能，或者找到你要增加功能的正確位置。
極限編程團隊都會在這里很長的一段時間。他們努力的工作，并且在一個能夠不斷維持的步伐下。這意味著在有效的時候他們會加班工作，而且他們經(jīng)常這樣工作來保證每周都有最大的生產(chǎn)力。這恰當(dāng)?shù)慕忉屃怂劳龈傎愂降捻椖考炔粫猩a(chǎn)力也不會創(chuàng)造有質(zhì)量的軟件系統(tǒng)。XP團隊在這里是要勝利而不是要死亡。
