極限編程（XP）是一種軟件開發方法，旨在提高軟件質量和對不斷變化的客戶需求的響應能力。作為一種敏捷軟件開發，提倡在較短的開發周期中頻繁發布“版本”，旨在提高生產率并引入可以采用新客戶要求的檢查點。

極限編程的其他元素包括：成對編程或進行大量代碼審查，對所有代碼進行單元測試，直到實際需要時才進行編程功能，平坦的管理結構，代碼簡單明了，隨著時間的流逝預期客戶需求的變化問題得到了更好的理解，并與客戶以及程序員之間進行了頻繁的溝通。該方法的名稱來源于將傳統軟件工程實踐的有益要素帶到“極端”水平的想法。例如，代碼審查被認為是有益的做法；極端地講，代碼可以連續進行審查（即結對編程的實踐）。

構成XP基礎的原則基于剛剛描述的值，旨在促進系統開發項目中的決策。原則旨在比價值觀更具體，并且在實際情況下更容易轉化為指導。

如果頻繁且迅速地進行極限編程，反饋將是最有用的。它強調，動作與反饋之間的最小延遲對于學習和進行更改至關重要。與傳統的系統開發方法不同，與客戶聯系的頻率更高。客戶對正在開發的系統有清晰的洞察力，可以提供反饋并根據需要引導開發。在客戶頻繁反饋的情況下，在開發人員花費大量時間實施它之前，開發人員會迅速注意到并糾正錯誤的設計決策。

單元測試有助于快速反饋原理。在編寫代碼時，運行單元測試可提供有關系統如何對所做更改做出反應的直接反饋。這不僅包括運行測試開發人員代碼的單元測試，而且還包括使用可以由單個命令啟動的自動化過程針對所有軟件運行所有單元測試。這樣，如果開發人員的更改導致開發人員幾乎不了解或一無所知的系統其他部分發生故障，則自動全單元測試套件將立即顯示故障，并向開發人員發出與其更改不兼容的警告。系統的其他部分，以及刪除或修改其更改的必要性。在傳統的開發慣例下，由于缺乏自動化，全面的單元測試套件意味著，開發人員認為無害的這種代碼更改將留在原地，僅在集成測試期間才出現，或者更糟的是僅在生產中出現；在集成測試之前的幾周甚至幾個月內，在所有開發人員進行的所有更改中，確定導致問題的代碼更改是一項艱巨的任務。

這是關于將每個問題視為“極其簡單”的解決方案。傳統的系統開發方法說，要為將來做計劃并為可重用性編寫代碼。極限編程拒絕了這些想法。

極限編程的倡導者說，一次進行大的更改是行不通的。極限編程會應用增量更改：例如，系統可能每三周發布一次較小的版本。當采取許多小步驟時，客戶可以更好地控制開發過程和正在開發的系統。

擁抱變化的原則是不與變化作斗爭，而是擁抱變化。例如，如果在一次迭代會議中，客戶的需求似乎發生了巨大變化，程序員將接受此需求并為下一次迭代計劃新的需求。

ThoughtWorks聲稱在多達60人的分布式XP項目上取得了合理的成功。

2004年，隨著XP的發展，引入了工業極限編程（IXP）。它旨在帶來在大型分布式團隊中工作的能力。現在，它擁有23種實踐和靈活的價值觀。

2003年，Matt Stephens和Doug Rosenberg出版了《極限編程重構：XP的案例》，質疑XP流程的價值并提出了改進XP的方法。這在文章，Internet新聞組和網站聊天區域引發了漫長的辯論。該書的核心論點是XP的實踐是相互依賴的，但是很少有實踐組織愿意/能夠采用所有實踐。因此，整個過程將失敗。該書還提出了其他批評，并以消極的方式將XP的“集體所有權”模式與社會主義相提并論。

自從極限編程的發行發布以來，XP的某些方面發生了變化;?尤其是XP，現在只要可以實現所需的目標，就可以對實踐進行修改。XP還對流程使用越來越通用的術語。有人認為，這些變化使先前的批評無效。其他人則聲稱，這只是在簡化整個過程。

其他作者試圖將XP與較舊的方法進行協調，以形成統一的方法。其中一些XP尋求替代，例如Waterfall方法；示例：項目生命周期：瀑布式，快速應用程序開發（RAD）等。摩根大通公司（JPMorgan Chase＆Co.）嘗試將XP與能力成熟度模型集成（CMMI）和六西格瑪（Six Sigma）的計算機編程方法相結合。他們發現這三個系統相互加強，導致更好的發展，并且沒有相互矛盾。