什麼是敏捷專案管理中所提到的XP？

XP Stands for Extreme programming 就是常說的極限程式設計，是不是有一種恍然大悟的感覺。

重點：客戶滿意度

一、4個價值：

溝通
簡單
回饋
勇氣
二、5個準則：

快速反饋
假設簡單：認為任何問題都可以”極度簡單”地解決。傳統的系統開發方法要考慮未來的變化，要考慮程式碼的可重用性。極限程式設計拒絕這樣做。
增量變化
擁抱變化
高質量的工作：高效團隊配合，完成
三、原則：

編碼是核心活動
XP團隊做大量測試
讓客戶和程式設計師直接溝通
總體設計必不可少
提高可讀性
降低複雜性
提高可維護性
確保可擴充套件性
四、12個支援實踐：
1、規劃遊戲： 所有團隊成員參與規劃，在業務和技術人員之間不存在隔閡
2、短交付週期： 和Scrum一樣採用迭代的交付方式

計劃遊戲：XP的計劃過程主要針對軟體開發中的兩個問題

預測在交付日期前可以完成多少工作；
現在和下一步該做些什麼。
針對這兩個問題，XP中又兩個主要的相應過程：

軟體釋出計劃（ReleasePlanning）【會在實施過程中不斷調整以趨於精準】；
週期開發計劃（IterationPlanning）
3、結對程式設計：

    eg：一個程式設計師控制電腦並且主要考慮編碼細節。另外一個人主要關注整體結構，不斷的對第一個程式設計師寫的程式碼進行評審，形式不固定，甚至建議程式設計師儘量交叉結對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統熟悉

4、可持續的節奏： 儲存體力【而非全速短跑】
5、程式碼集體所有： 整個團隊（每個人）都對所有的程式碼負責
6、編碼規範
7、簡化設計
8、測試驅動開發 （英文全稱Test-Driven Development，簡稱TDD）：

    它要求在編寫某個功能的程式碼之前先編寫測試程式碼，然後只編寫使測試通過的功能 這有助於編寫簡潔可用和高質量的程式碼，並加速開發過程。
    簡單來說，就是不可執行/可執行/重構——這正是測試驅動開發的口號

9、重構： 努力減少程式和設計中重複出現的部分，增強程式和設計的可重用性【依賴越少，效果越好】
10、系統隱喻： XP開發小組用很多形象的比喻來描述系統或功能模組是怎樣工作的
11、持續整合： 團隊成員使用最新的程式碼工作，並儘可能經常地將多個開發團隊程式碼進行整合
12、現場客戶： 在極限程式設計中，“客戶”並不是為系統付帳的人，而是真正使用該系統的人。極限程式設計認為客戶應該時刻在現場解決問題

極限程式設計（英語：Extreme programming，縮寫為XP），是一種軟體工程方法學，是敏捷軟體開發中應用最為廣泛和最富有成效的幾種方法學之一。如同其他敏捷方法學，極限程式設計和傳統方法學的本質不同在於它更強調可適應性而不是可預測性。極限程式設計的支持者認為軟體需求的不斷變化是很自然的現象，是軟體專案開發中不可避免的、也是應該欣然接受的現象；他們相信，和傳統的在專案起始階段定義好所有需求再費盡心思的控制變化的方法相比，有能力在專案週期的任何階段去適應變化，將是更加現實更加有效的方法。

極限程式設計為管理人員和開發人員開出了一劑指導日常實踐的良方；這個實踐意味著接受並鼓勵某些特別的有價值的方法。支持者相信，這些在傳統的軟體工程中看來是“極端的”實踐，將會使開發過程比傳統方法更加好的響應使用者需求，因此更加敏捷，更好的構建出高質量軟體。

極限程式設計的創始者是肯特·貝克、沃德·坎寧安和羅恩·傑弗里斯，他們在為克萊斯勒綜合報酬系統（C3）的薪水冊專案工作時提出了極限程式設計方法。肯特·貝克在1996年3月成為C3的專案負責人，開始對專案的開發方法學進行改善。他寫了一本關於這個改善後的方法學的書，並且於1999年10月將之發行，這就是《極限程式設計解析》（2005第二版出版）。克萊斯勒在2000年2月取消了實質上並未成功的C3專案，但是這個方法學卻一直流行在軟體工程領域中。至今，很多軟體開發專案都一直以極限程式設計做為他們的指導方法學。

極限程式設計的目標

極限程式設計的主要目標在於降低因需求變更而帶來的成本。在傳統系統開發方法中，系統需求是在專案開發的開始階段就確定下來，並在之後的開發過程中保持不變的。這意味著專案開發進入到之後的階段時出現的需求變更將導致開發成本急速增加，而這樣的需求變更在一些發展極快的領域中是不可避免的。

極限程式設計通過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應用了極限程式設計方法的系統開發專案在應對需求變更時將顯得更為靈活。

極限程式設計的12個核心實踐

短交付週期

極限程式設計和Scrum一樣採用迭代的交付方式，每個迭代1-3周時間。在每個迭代結束的時候，團隊交付可執行的，經過測試的功能，這些功能可以馬上投入使用。

計劃遊戲

XP的計劃過程主要針對軟體開發中的兩個問題：預測在交付日期前可以完成多少工作；現在和下一步該做些什麼。不斷的回答這兩個問題，就是直接服務於如何實施及調整開發過程；與此相比，希望一開始就精確定義整個開發過程要做什麼事情以及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP中又兩個主要的相應過程：

軟體釋出計劃（ReleasePlanning）。客戶闡述需求，開發人員估算開發成本和風險。客戶根據開發成本、風險和每個需求的重要性，制訂一個大致的專案計劃。最初的專案計劃沒有必要（也沒有可能）非常準確，因為每個需求的開發成本、風險及其重要性都不是一成不變的。而且，這個計劃會在實施過程中被不斷地調整以趨精確。

週期開發計劃（IterationPlanning）。開發過程中，應該有很多階段計劃（比如每三個星期一個計劃）。開發人員可能在某個週期對系統進行內部的重整和優化（程式碼和設計），而在某個週期增加了新功能，或者會在一個週期內同時做兩方面的工作。但是，經過每個開發週期，使用者都應該能得到一個已經實現了一些功能的系統。而且，每經過一個週期，客戶就會再提出確定下一個週期要完成的需求。在每個開發週期中，開發人員會把需求分解成一個個很小的任務，然後估計每個任務的開發成本和風險。這些估算是基於實際開發經驗的，專案做得多了，估算自然更加準確和精確；在同一個專案中，每經過一個開發週期，下一次的估算都會有更過的經驗、參照和依據，從而更加準確。這些簡單的步驟對客戶提供了豐富的、足夠的資訊，使之能靈活有效地調控開發程序。每過兩三個星期，客戶總能夠實實在在地看到開發人員已經完成的需求。在XP裡，沒有什麼“快要完成了”、“完成了90%”的模糊說法，要不是完成了，要不就是沒完成。這種做法看起來好像有利有弊：好處是客戶可以馬上知道完成了哪些、做出來的東西是否合用、下面還要做些什麼或改進什麼等等；壞處是客戶看到做出來的東西，可能會很不滿意甚至中止合同。實際上，XP的這種做法是為了及早發現問題、解決問題，而不是等到過了幾個月，使用者終於看到開發完的系統了，然後才告訴你這個不行、那個變了、還要增加哪個內容等等。

結對程式設計

結對程式設計是指程式碼由兩個人坐在一臺電腦前一起完成。一個程式設計師控制電腦並且主要考慮編碼細節。另外一個人主要關注整體結構，不斷的對第一個程式設計師寫的程式碼進行評審。

結對不是固定的：我們甚至建議程式設計師儘量交叉結對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統熟悉，結對程式設計加強了團隊內的溝通。這與程式碼集體所有制是息息相關的。

可持續的節奏

團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們儲存精力，他們把專案看作是馬拉松長跑，而不是全速短跑。

程式碼集體所有

程式碼集體所有意味著每個人都對所有的程式碼負責；這一點，反過來又意味著每個人都可以更改程式碼的任意部分。結隊程式設計對這一實踐貢獻良多：藉由在不同的結隊中工作，所有的程式設計師都能看到完全的程式碼。集體所有制的一個主要優勢是提升了開發程式的速度，因為一旦程式碼中出現錯誤，任何程式設計師都能修正它。

在給予每個開發人員修改程式碼的許可權的情況下，可能存在程式設計師引入錯誤的風險，他／她們知道自己在做什麼，卻無法預見某些依賴關係。完善的單元測試可以解決這個問題：如果未被預見的依賴產生了錯誤，那麼當單元測試執行時，它必定會失敗。

編碼規範

XP開發小組中的所有人都遵循一個統一的程式設計標準，因此，所有的程式碼看起來好像是一個人寫的。因為有了統一的程式設計規範，每個程式設計師更加容易讀懂其他人寫的程式碼，這是是實現程式碼集體所有的重要前提之一。

簡單設計

XP中讓初學者感到最困惑的就是這點。XP要求用最簡單的辦法實現每個小需求，前提是按照這些簡單設計開發出來的軟體必須通過測試。這些設計只要能滿足系統和客戶在當下的需求就可以了，不需要任何畫蛇添足的設計，而且所有這些設計都將在後續的開發過程中就被不斷地重整和優化。

在XP中，沒有那種傳統開發模式中一次性的、針對所有需求的總體設計。在XP中，設計過程幾乎一直貫穿著整個專案開發：從制訂專案的計劃，到制訂每個開發週期（Iteration）的計劃，到針對每個需求模組的簡捷設計，到設計的複核，以及一直不間斷的設計重整和優化。整個設計過程是個螺旋式的、不斷前進和發展的過程。從這個角度看，XP是把設計做到了極致。

測試驅動開發

測試驅動開發的基本思想就是在開發功能程式碼之前，先編寫測試程式碼，然後只編寫使測試通過的功能程式碼，從而以測試來驅動整個開發過程的進行。這有助於編寫簡潔可用和高質量的程式碼，有很高的靈活性和健壯性，能快速響應變化，並加速開發過程。

測試驅動開發的基本過程如下：

①　快速新增一個測試

②　執行所有的測試（有時候只需要執行一個或一部分），發現新增的測試不能通過

③　做一些小小的改動，儘快地讓測試程式可執行，為此可以在程式中使用一些不合情理的方法

④　執行所有的測試，並且全部通過

⑤　重構程式碼，以消除重複設計，優化設計結構

簡單來說，就是不可執行/可執行/重構——這正是測試驅動開發的口號

重構

XP強調簡單的設計，但簡單的設計並不是沒有設計的流水賬式的程式，也不是沒有結構、缺乏重用性的程式設計。開發人員雖然對每個USERSTORY都進行簡單設計，但同時也在不斷地對設計進行改進，這個過程叫設計的重構（Refactoring）。這個名字最早出現在MartinFowler寫的《Refactoring:ImprovingtheDesignofExistingCode》這本書中。

Refactoring主要是努力減少程式和設計中重複出現的部分，增強程式和設計的可重用性。Refactoring的概念並不是XP首創的，它已經被提出了近30年了，而且一直被認為是高質量的程式碼的特點之一。但XP強調，把Refactoring做到極致，應該隨時隨地、儘可能地進行Refactoring，只要有可能，程式設計師都不應該心疼以前寫的程式，而要毫不留情地改程序序。當然，每次改動後，程式設計師都應該執行測試程式，保證新系統仍然符合預定的要求。

系統隱喻

為了幫助每個人一致清楚地理解要完成的客戶需求、要開發的系統功能，XP開發小組用很多形象的比喻來描述系統或功能模組是怎樣工作的。比如，對於一個搜尋引擎，它的Metaphor可能就是“一大群蜘蛛，在網上四處尋找要捕捉的東西，然後把東西帶回巢穴。”

持續整合

整合軟體的過程不是新問題，如果專案開發的規模比較小，比如一個人的專案，如果它對外部系統的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加（即使增加一個人），就會對整合和確保軟體元件能夠在一起工作提出了更多的要求-要早整合，常整合。早整合，頻繁的整合幫助專案在早期發現專案風險和質量問題，如果到後期才發現這些問題，解決問題代價很大，很有可能導致專案延期或者專案失敗。

持續整合是一種軟體開發實踐，即團隊開發成員經常整合它們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建（包括編譯，釋出，自動化測試)來驗證，從而儘快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發內聚的軟體。

現場客戶

在極限程式設計中，“客戶”並不是為系統付帳的人，而是真正使用該系統的人。極限程式設計認為客戶應該時刻在現場解決問題。例如：在團隊開發一個財務管理系統時，開發小組內應包含一位財務管理人員。客戶負責編寫故事和驗收測試，現場客戶可以使團隊和客戶有更頻繁的交流和討論。

極限程式設計的4個價值

除了XP實踐，極限程式設計還提倡四大價值：溝通、簡單、回饋、勇氣。

溝通

構建一個軟體系統的基本任務之一就是與系統的開發者交流以明確系統的具體需求。在一些正式的軟體開發方法中，這一任務是通過文件來完成的。

極限程式設計技術可以被看成是在開發小組的成員之間迅速構建與傳播制度上的認識的一種方法。它的目標是向所有開發人員提供一個對於系統的共享的視角，而這一視角又是與系統的終端使用者的視角相吻合的。為了達到這一目標，極限程式設計支援設計、抽象、還有使用者-程式設計師間交流的簡單化，鼓勵經常性的口頭交流與回饋。

簡單

極限程式設計鼓勵從最簡單的解決方式入手再通過不斷重構達到更好的結果。這種方法與傳統系統開發方式的不同之處在於，它只關注於對當前的需求來進行設計、編碼，而不去理會明天、下週或者下個月會出現的需求。極限程式設計的擁護者承認這樣的考慮是有缺陷的，即有時候在修改現有的系統以滿足未來的需求時不得不付出更多的努力。然而他們主張“不對將來可能的需求上投入精力”所得到的好處可以彌補這一點，因為將來的需求在他們還沒提出之前是很可能發生變化的。為了將來不確定的需求進行設計以及編碼意味著在一些可能並不需要的方面浪費資源。而與之前提到的“交流”這一價值相關聯來看，設計與程式碼上的簡化可以提高交流的質量。一個由簡單的編碼實現的簡單的設計可以更加容易得被小組中的每個程式設計師所理解。

反饋

XP團隊重視反饋，反饋越快越好。在極限程式設計中，“反饋”是和系統開發的很多不同方面相關聯的：

來自系統的反饋：通過編寫單元測試，程式設計師能夠很直觀的得到經過修改後系統的狀態。

來自客戶的反饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當前系統的狀態。這樣的評審一般計劃2、3個禮拜進行一次，這樣客戶可以非常容易的瞭解、掌控開發的進度。

來自小組的反饋：當客戶帶著新需求來參加專案計劃會議時，小組可以直接對於實現新需求所需要的時間進行評估然後反饋給客戶。

反饋是與“交流”、“簡單”這兩條價值緊密聯絡的。為了溝通系統中的缺陷，可以通過編寫單元測試，簡單的證明某一段程式碼存在問題。來自系統的直接反饋資訊將提醒程式設計師注意這一部分。使用者可以以定義好的功能需求為依據，對系統進行週期性的測試。用Kent Beck的話來說：“程式設計中的樂觀主義是危險的，而及時反饋則是解決它的方法。”

勇氣

極限程式設計理論中的“系統開發中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為今天的需求設計以及編碼，不要考慮明天”這條戒律。這是努力避免陷入設計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發人員在需要重構他們的程式碼時能感到舒適。這意味著重新審查現有系統並完善它會使得以後出現的變化需求更容易被實現。另一個勇氣的例子是瞭解什麼時候應該完全丟棄現有的程式碼。每個程式設計師都有這樣的經歷：他們花了一整天的時間糾纏於自己設計和程式碼中的一個複雜的難題卻無所得，而第二天回來以一個全新而清醒的角度來考慮，在半小時內就輕鬆解決了問題。

極限程式設計的5個原則

組成極限程式設計基礎的原則，正是基於上面描述的那幾條價值。在系統開發專案中，這些原則被用來為決策做出指導。與價值相比，原則被描述的更加具體化，以便在實際應用中更為簡單的轉變為具體的指導意見。

1. 快速反饋

當反饋能做到及時、迅速，將發揮極大的作用。一個事件和對這一事件做出反饋之間的時間，一般被用來掌握新情況以及做出修改。與傳統開發方法不同，與客戶的發生接觸是不斷反覆出現的。客戶能夠清楚地洞察開發中系統的狀況。他／她能夠在整個開發過程中及時給出反饋意見，並且在需要的時候能夠掌控系統的開發方向。

單元測試同樣對貫徹反饋原則起到作用。在編寫程式碼的過程中，應需求變更而做出修改的系統將出現怎樣的反應，正是通過單元測試來給出直接反饋的。比如，某個程式設計師對系統中的一部分程式碼進行了修改，而假如這樣的修改影響到了系統中的另一部分（超出了這個程式設計師的可控範圍），則這個程式設計師不會去關注這個缺陷。往往這樣的問題會在系統進入生產環節時暴露出來。

2. 假設簡單

假設簡單認為任何問題都可以”極度簡單”地解決。傳統的系統開發方法要考慮未來的變化，要考慮程式碼的可重用性。極限程式設計拒絕這樣做。

3. 增量變化

極限程式設計的提倡者總是說：羅馬不是一天建成的。一次就想進行一個大的改造是不可能的。極限程式設計採用增量變化的原則。比如說，可能每三個星期釋出一個包含小變化的新版本。這樣一小步一小步前進的方式，使得整個開發進度以及正在開發的系統對於使用者來說變得更為可控。

4. 擁抱變化

可以肯定地是，不確定因素總是存在的。“擁抱變化”這一原則就是強調不要對變化採取反抗的態度，而應該擁抱它們。比如，在一次階段性會議中客戶提出了一些看來戲劇性的需求變更。作為程式設計師，必須擁抱這些變化，並且擬定計劃使得下一個階段的產品能夠滿足新的需求。

5. 高質量的工作

沒人喜歡拖泥帶水，每個人都期望出色的完成工作。極限程式設計的提倡者認為範圍、時間、成本和質量這個四個軟體開發的變數，只有質量不可妥協的。