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