團隊協作(whole team);
規劃策略(the planning game): 主要思想就是先快速地制定乙份概要的計畫，然後隨著專案細節的不斷清晰，再逐步完善這份計畫,產生的結果是一套使用者故事及後續的一兩次迭代的概要計畫。
結對程式設計(pair programming):所有的產品軟體都是由兩個程式設計師、併排坐在一起在同一臺機器上構建的。
測試驅動開發(testing-driven development):編寫單元測試是乙個驗證行為，更是乙個設計行為。同樣，它更是一種編寫文件的行為。編寫單元測試避免了相當數量的反饋迴圈，尤其是功能驗證方面的反饋迴圈。程式設計師以非常短的迴圈週期工作，他們先增加乙個失敗的測試，然後使之通過。
重構(refractoring):重構時一種對**進行改進而不影響功能實現的技術，xp需要開發人員在聞到**的壞味道時，有重構**的勇氣。重構的目的是降低變化引發的風險，使得**優化更加容易。
簡單設計(****** design):提出沒有重複**，盡量少的類和方法，使用迪公尺特法則等，只是針對今天而言，不要因為後期可能會用到，就新增了乙個現在不用的類或者方法，而不是不做可擴充套件性，這兩者並不衝突。即使因為沒有考慮很多，而可拓展性沒有做到很好，xp提倡重構也能將擴充套件性提高乙個檔次，而且更精確更符合現在的需求。而傳統的方式將一切考慮到位也不見得擴充套件性就完美，畢竟變化是不可**的，現在考慮的擴充套件性在幾個月後可能也用不上了，到時必然也是要重構;
**集體所有權(collective code ownership):任何結對的程式設計師都可以在任何時候改進任何**。團隊中的每個成員都擁有對**進行改進的權利，每個人都擁有全部**，也都需要對全部**負責。
持續整合(continuous integration):團隊總是使系統完整地被整合。乙個人拆入（check in）後，其它所有人責任**整合。持續整合是指團隊每天盡可能多次的進行**整合，保證團隊獲取的**都是近期統一過的**，避免太多不一致造成衝突。而上文說的小型發布則是更多的發布測試版本，中間版本，讓客戶或者pm審核，確認功能開發沒有錯誤。需要我們引入**管理工具，版本控制工具。
現場客戶(on-site customer): 作為選擇每個所期望的特性的一部分，客戶可以根據指令碼語言來定義出自動驗收測試來表明該特性可以工作。為了保證開發出來的結果與客戶的預想接近，xp方**認為最重要的需要將客戶請到開發現場，需要客戶進行體驗，確保業務功能正確。
小型發布（small release）:xp方**秉承的是「持續整合，小步快走」的哲學，也就是說每一次發布的版本應該盡可能的小，當然前提條件是每個版本有足夠的商業價值，值得發布。由於小型發布可以使得整合更頻繁，客戶獲得的中間結果也越頻繁，反饋也就越頻繁，客戶就能夠實時地了解專案的進展情況，從而提出更多的意見，以便在下一次迭代中計畫進去。以實現更高的客戶滿意度。
每週40小時工作制（40-hour week）
編碼規範（code standards）:系統中所有的**看起來就好像是被單獨一人編寫的,編碼標準可以消除一些無謂的分歧。
系統隱喻（system metaphor）:創造心照不宣的詞彙和列子，更形象有趣的溝通。比喻有時候更能讓人更快更好的理解你的意思，而不是一堆晦澀專業術語。將整個系統聯絡在一起的全域性檢視；它是系統的未來影像，是它使得所有單獨模組的位置和外觀變得明顯直觀。如果模組的外觀與整個隱喻不符，那麼你就知道該模組是錯誤的。隱喻可以幫助結對夥伴更好地溝通。
敏捷2 2 極限程式設計XP
一提到 xp 很多人的第一反應是微軟的那個作業系統。沒錯，xp 似乎已經是它的代名詞了。但是，在敏捷領域，也有乙個 xp 而且也是一樣的如雷貫耳。那就是傳說中的 extremeprogramming 極限程式設計，它的簡稱就是 xp 既然都帶有程式設計兩個字了，那麼很明顯這個理論框架就是出自軟體開發...
敏捷開發之極限程式設計（XP）
極限程式設計是敏捷開發的一種方法，極限程式設計針對小型的開發團隊來說是乙個不錯的方法.極限程式設計本質是務實主義的體現，快速穩定的實現每乙個使用者要求，是極限程式設計的基本要求。1.客戶盡量和開發人員在一起，一是可以知道開發的進度 二是可以和開發人員進行溝通，實時調整功能點的優先順序。2.對使用者提...
敏捷開發XP極限程式設計的12個最佳實踐
1.計畫遊戲 planning game 1 快速制定計畫 隨著細節的不斷變化而完善 2.小型發布 small release 1 系統的設計要能夠盡可能早地交付 2 詳解 強調在非常短的週期內以遞增的方式發布新版本，從而可以很容易地估計每個迭代週期的進度，便於控制工作量和風險 同時，也可以及時處理...