定義
1、extreme programming (xp) 是以開發符合變化的客戶需求的軟體為目標而產生的一種方法， 它的成功得益於它對客戶滿意度的特別強調，xp 使開發者能夠更有效的響應客戶的需求變化，哪怕在軟體生命週期的後期。
2、一種歷過很多實踐考驗的軟體開發方法.
3、是一種輕量、高效、低風險、柔性、可**、科學而且充滿樂趣的軟體開發方法。
4、是勇氣，交流，反饋和簡單。
5、是軟體開發過程中的紀律，它規定：必須在程式設計前寫測試，必須兩個人一起程式設計，必須遵守程式設計規範……。
6、是把最好的實踐經驗提取出來，形成了乙個嶄新的開發方法
. xp 與其它方**的不同之處
1. 短週期內的早期、具體和持續的反饋。
3. 遞增地進行計畫程式設計，這種方法迅速提供乙個總體計畫，然後在專案的整個生命週期內不斷發展它。
4. 針對不斷變化的業務需求，靈活地對功能的實現進行計畫的能力。
5. 依賴於程式設計師或客戶編寫的自動測試來監控開發速度，使得系統得以進展並及早捕獲缺陷。
6. 依賴口頭交流、測試和源**來溝通系統的結構和意圖。
7. 依賴於在整個系統存在期間一直持續的進化式設計過程。
8. 依賴於技術水平一般的程式設計師之間的緊密協作。
9. 依賴於能同時滿足程式設計師的短期本能和專案的長期利益的實踐。
. xp價值觀
communication
開發中的大部分問題都是由溝通問題引起的
xp的目標是通過使用許多沒有交流就無法完成的實踐來保持正確的通訊流
simplicity
做到簡單並非易事，世界上最難的事情就是不去考慮自己明天、下星期乃至下個月的任務。
xp是在打賭. 它打賭今天做得簡單一些，然後在明天需要時再花些功夫進行改進，要比今天做得很複雜，但以後再也用不到要好得多
簡單和溝通之間有一種奇妙的相互支援的關係。
–溝通得越多，就越清楚哪些工作需要做，並能更加確信哪些工作不需要做。
–系統越簡單，需要的溝通越少，但是溝通會更加全面
feedback
－－客戶和測試者為需要系統實現的所有故事編寫功能測試，能夠得到有關系統狀態的具體反饋。
－－客戶隔2－3周檢查一次日程，檢視開發團隊的整體進度是否與計畫相符，並隨之調整計畫。
溝通, 簡單和反饋是相互聯絡的；
–反饋越充分，溝通越容易。
–系統越簡單，就越容易測試和提供反饋
courage
溝通支援勇氣，因為它帶來了高風險、高回報的試驗的可能性。
簡單支援勇氣，因為有了乙個簡單的系統，你可以比以前勇敢得多，你無意中將其破壞的可能性也大大減少。
勇氣支援簡單，因為只有你有可能簡化系統，你就會嘗試。
反饋支援勇氣，因為如果你按下按鈕就能夠看到測試結果通過（或不通過，這時你可以將**扔掉），那麼即使對**進行根本的改動你也會感覺安全得多。
管理. xp的基本原則
1.rapid feedback 快速反饋
指開發人員通過短的迭代週期，得到反饋資訊，並迅速查驗他們前面的工作是否滿足客戶要求。
2. assume simplicity 假定簡單
指將系統開發中的每個問題以盡量簡單的方法來解決。沒有人能夠準確預知未來的需求，因此設計只需要滿足現階段的需求即可。
3. incremental change 遞增改變
指用一系列的小改變來逐步解決乙個問題。這一原則可用於計畫、開發和設計等。
4. embracing change 擁抱變化
指在解決緊迫問題時，採取的一種包容的策略。程式設計師要明白客戶的要求並不是固定的，因此功能的優先順序和功能需求都是在變化的。
5. quality work 優質產品
指工作和產品的質量是不容忽視的，不可以因為時間而放棄質量，並作出讓步。
挑戰極限 極限程式設計中的「極限」
最近，一直在看robert martin的 敏捷軟體開發 原則 模式和實踐 該文中以極限程式設計 xp 來講述敏捷的實踐。看完有關於 xp實踐的部分，對 xp基本的主張和如何去實踐有了乙個大概的了解。但是，一直有個問題在我腦海中，那就是這種開發實踐方式為什麼會被稱為 極限程式設計 看完這部分之後，對...
極限程式設計下的極限測試
極限測試主要由兩部分測試組成 單元測試和驗收測試。單元測試是極限測試中主要採用的測試方法，它具有兩條簡單規則 所有 模組在編碼開始之前必須設計好單元測試用例。在產品發布之前需要通過單元測試。極限測試中的單元測試和普通的單元測試之間最大的區別是 極限測試中的單元測試必須在模組編碼之前就完成設計和生成。...
XP極限程式設計
結隊程式設計是xp極限程式設計的乙個關鍵實踐，如果把結隊程式設計放到整個xp裡面會更容易體現出它的價值，所以我覺得分析結隊程式設計的乙個整體思路是 1 適用場景 xp的適用性在 什麼樣的專案中適合採用xp，在這樣的專案中xp可以起到什麼作用。如果離開了適用場景，xp的適用性都要重新考慮，所以就更不用...