极限编程（英语：Extreme programming，缩写为XP），是一种软件工程方法学，是敏捷软件开发的一种方式。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。
极限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。
极限编程的创始者是肯特·贝克、沃德·坎宁安和罗恩·杰弗里斯（英语：Ron Jeffries），他们在为克莱斯勒综合报酬系统（英语：Chrysler Comprehensive Compensation System）的薪水册项目工作时提出了极限编程方法。肯特·贝克在1996年3月成为克莱斯勒系统的项目负责人，开始对项目的开发方法学进行改善。他写了一本关于这个改善后的方法学的书，并且于1999年10月将之发行，这就是《极限编程解析》（2005第二版出版）。克莱斯勒在2000年2月取消了实质上并未成功的克莱斯勒系统，但是这个方法学却一直流行在软件工程领域中。直到2006年，很多软件开发项目都一直以极限编程做为他们的指导方法学。
该书阐述了如下的极限编程的哲学思想：
把极限编程一般化并用于其它类型的专案称为极限专案管理。
极限编程的推广之一为把不同的敏捷软件实践和传统实践节奏地结合起来，弹性地合用于不同企业开发环境。这就是软件开发节奏（Software Development Rhythms）的中心思想
极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更（而这样的需求变更在一些发展极快的领域中是不可避免的）将导致开发成本急速增加。
极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
极限编程实践作业的核心可以被区分为以下四个范围（12个实践作业）:
在第二版的《极限编程解析》中，在主要实践之外，还列出了一系列延伸的实践。
核心实践源自被广泛接受的最佳实践，并且被推向极致：
极限编程描述了在软件开发过程中四种基本的行为，包括
极限编程的提倡者争辩说在系统开发过程的产物中真正重要的只有编码，并认为没有经过测试的代码什么都不是。如果你没有测试，客户可能感觉不到，很多软件在发布的时候没有经过完整的测试，它们还都在工作（或多或少的工作）。极限编程认为，在软件开发程序中，如果一个函数没有经过测试就不能认为它可以工作。
极限编程技术以沟通、简单、反馈、勇气和尊重为价值标准。
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。
极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为目前的需求设计以及编码，别为不可预期的未来做太多考虑”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试案例失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量，坚持通过重构的手段来为手头的工作找到最好的解决设计方案。
组成极限编程基础的原则，正是基于上面描述的那几条价值。在系统开发项目中，这些原则被用来为决策做出指导。与价值相比，原则被描述的更加具体化，以便在实际应用中更为简单的转变为具体的指导意见。
当回馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。与传统开发方法不同，与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他／她能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。
单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中，应需求变更而做出修改的系统将出现怎样的反应，正是通过单元测试来给出直接反馈的。比如，某个程序员对系统中的一部分代码进行了修改，而假如这样的修改影响到了系统中的另一部分（超出了这个程序员的可控范围），则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。
假设简单认为任何问题都可以"极度简单"地解决。传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样做。
可以肯定地是，不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度，而应该包容它们。比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员，必须包容这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。
在极限编程中主要的策划程序称为策划游戏，本节将通过程序模型介绍这个程序。
策划程序分为两部分：
这一阶段涉及成本、利润和计划影响这三个因素，包含四个部分：
业务方按照商业价值为用户故事排序。它们会被分为三类：
程序员按照风险对用户故事进行排序。他／她们将用户故事的风险划分成三类：低、中、高。以下是这种方式的一个示例：
为每个用户故事增加所有这些索引后，给这些用户故事指定一个风险索引：低（0–1），中（2–4），高（5–6）。
在作业阶段开发人员和业务人员可以“操纵”整个程序。这意味着，他们可以做出改变。个体的用户故事，或是不同用户故事的相对优先等级，都有可能改变；预估时间也可能出现误差。这是做出相应调整的机会。
反复计划中的探索阶段是关于创建任务和预估实施时间。
在反复计划的约定阶段以不同用户故事作为参考的任务被指派到程序员。
各个任务是在反复计划的作业阶段中一步步实现的。
结对程序设计的意思是所有的代码都是由两个人坐在一台电脑前一起完成的。一个程序员控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构，不断的对第一个程序员写的代码进行评审。
结对不是固定的：我们甚至建议程序员尽量交叉结对。这样，每个人都可以知道其它人的工作，每个人都对整个系统熟悉，结对程序设计加强了团队内的沟通。（这与代码集体所有制是息息相关的）.
集体所有制意味着每个人都对所有的代码负责；这一点，反过来又意味着每个人都可以更改代码的任意部分。结队程序设计对这一实践贡献良多：借由在不同的结队中工作，所有的程序员都能看到完全的代码。集体所有制的一个主要优势是提升了开发程序的速度，因为一旦代码中出现错误，任何程序员都能修正它。
在给予每个开发人员修改代码的权限的情况下，可能存在程序员引入错误的风险，他／她们知道自己在做什么，却无法预见某些依赖关系。完善的单元测试可以解决这个问题：如果未被预见的依赖产生了错误，那么当单元测试执行时，它必定会失败。
在极限编程中，“客户”并不是为系统付账的人，而是真正使用该系统的人。极限编程认为客户应该时刻在现场解决问题。例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。
单元测试是用以测试一小段代码的自动测试（例如：类，方法）。在极限编程中，在代码编辑前就编辑单元测试。这种方式的目的是激励程序员设想他／她的代码在何种条件下会出错。极限编程认为当程序员无法再想出更多能使他／她的代码出错的情况时，这些代码便算完成。
由于极限编程教条提倡编辑程序时只满足目前的需求，并且以尽可能简单的方式实现。有时会碰上一套僵硬的系统，所谓僵硬的系统，表现之一是需要双重（或多重）维护：功能变化需要对多份同样（或类似）的代码进行修改；另一种表现是对代码的一部分进行修改时会影响其它很多部分。XP教条认为当这种情况发生时，意味着系统正告诉你通过改变系统架构以重构代码，使它更简单、更泛用。参见重构。
极限编程方法的基本特征是：
极限编程也有其被争论的一面：
绝大多数设计活动都匆匆而过，并渐进式的，开始一个“最简单的可能工作的东西”并当其需要时（测试失败）才增加复杂性。单元测试促成为了设计纪律。
