由Kent Beck提出，是Agile方法中最引人注目的一个，名称中Extreme的含义是将好的开发实践（Practices）运用到极致。XP最初实践于1997年Crysler公司的C3项目（人员薪金管理），采用Smalltalk语言开发。适用于10人以下项目组、开发地点集中的场合，现已成为小组开发方法的一个典型，被业界广泛用于需求模糊和挥发性强的场合。XP基于四个价值(values)提出了十二个核心实践（Practices）。
3.1.1 XP方法的四个价值:
l 交流（Communication）。项目相关人员之间充分、多渠道（最好面对面）的沟通。
l 简化（Simplicity）。在系统可运转的前提下，做最简洁的工作；在开发中不断优化设计，时刻保持代码简洁、无冗余。
l 反馈（Feedback）。强调各种形式的反馈，如小交付、短迭代、先考虑测试再编码等。
l 胆识（Courage）。面对压力做正确的判断并敢于付诸行动，如，敢于丢弃设计不良的代码，疲惫时立即休息等。
3.1.2 XP方法的十二个核心实践：
l 工作团队（Whole Team）。所有的小组成员应在同一个工作地点工作。成员中必须有一个用户代表（On-site User）,由他/她来提出需求，确定开发优先级，把握开发的动向。通常还设一?quot;教练"（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。小组每个成员都应围绕用户代表，充分贡献自己的技能。
l 计划（Planning Game）。包括两类：交付计划和迭代（Iteration）计划，前者是在项目开始时对软件交付日期的粗略估计，后者是在每个迭代开始时对本次迭代的工作安排。二者都可在执行时调整，只不过迭代计划要更为具体和准确。
l 系统比拟（Metaphor）。系统比拟是待开发软件系统的一个形象化比喻，这个比喻必须是每个组员都熟悉的，它相当于一个粗略的软件体系结构（Architecture），使用户和开发人员建立一个一致的框架，从而指导开发的进行。
l 小交付（Small release）。经常交付可运行的、具有商业价值的小软件，供用户代表评估或最终使用。这里的"小"意味着软件模块能尽快（可在一个迭代内完成）、不断地交付。
l 测试（testing）。XP要求先开发测试用例(可自动执行)然后进行编码（testing then coding），而且测试要不断进行，保证代码测试要100%通过。分两种测试：单元测试和验收测试(Acceptance test)。单元测试由开发人员负责，验收测试由用户代表负责。
l 简洁设计（Simple Design）。有两个含义：一是设计只考虑当前定义的功能而不考虑以后需求的变化，二是指该设计是完成目前功能所需的最简洁的设计，要简单易懂、没有冗余。
l 结对开发（Pair Programming）。开发人员两人结一对，在一台机器前进行开发，一人打字编程另一人查看其编码，配对的两人是不固定的，建议每天轮换。
l 设计改进（Design Improvement）。在整个开发过程中，应对程序结构进行持续不断的梳理（Refactoring，在不影响程序的外部可见行为的情况下，按高内聚松耦合的原则对程序内部结构进行改进）, 保持代码简洁、无冗余。
l 持续集成（Continuous Integration）。保持项目组中所有开发的模块始终是组装完毕、集成良好且可执行的，一旦新的模块通过了单元测试，应立即将其组装、集成，形成新的可执行系统。
l 代码共享（Collective code Ownership）。任何结对开发者在任何时候都可改进项目组中的任何代码。
l 编码标准（Coding Standard）。对编程风格（命名、注释、格式等）要有一个大家认可的、共同遵守的标准，使整个程序如同一人编写。
l 可持续步调（Sustainable Pace）。整个项目的开发节奏应该是可长期维持的，XP提出每周40小时工作制，即不要加班，以使开发人员能长期保持工作的高效率。
3.1.3 XP开发过程：
l 整体开发过程
如图1所示，用户代表提出用户故事（User stories，类似于用例，但更简单，不超过三句话即可，一般只涉及功能要求），项目组据此进行讨论提出系统比拟，在此活动中有可能要进行体系结构的刺探（Spike,意在试探解决有关技术难点，走通技术路线）。在系统比拟和用户故事的基础上，根据用户设定的优先级制订交付计划（制订计划中可能需要对某个技术难点进行刺探），然后开始多个迭代过程（每个迭代一般为1~3周），在迭代期内产生的新用户故事不在本迭代内解决，以保证开发不受干扰。经验收测试通过后交付使用。
l 迭代过程
如图2所示。根据交付计划和项目速率（Project velocity,实际开发时间和估计时间的比率，如估计1天完成的工作实际为2天，项目速率为2），选择要优先完成的用户故事或待消除的Bugs，将其分解为可在1~2天内完成的任务，制定本次迭代计划，然后通过每天的站立会议（Stand up meeting,参加人员站着开会以缩短时间\提高效率）解决碰到的问题、调整迭代计划，会后是代码共享式的开发工作，开发人员要确保新功能100%通过单元测试，并立即组装形成新的可运行版本，由用户代表进行验收测试。
l 代码共享的编程
如图3所示。
3.1.1 XP方法的四个价值:
l 交流（Communication）。项目相关人员之间充分、多渠道（最好面对面）的沟通。
l 简化（Simplicity）。在系统可运转的前提下，做最简洁的工作；在开发中不断优化设计，时刻保持代码简洁、无冗余。
l 反馈（Feedback）。强调各种形式的反馈，如小交付、短迭代、先考虑测试再编码等。
l 胆识（Courage）。面对压力做正确的判断并敢于付诸行动，如，敢于丢弃设计不良的代码，疲惫时立即休息等。
3.1.2 XP方法的十二个核心实践：
l 工作团队（Whole Team）。所有的小组成员应在同一个工作地点工作。成员中必须有一个用户代表（On-site User）,由他/她来提出需求，确定开发优先级，把握开发的动向。通常还设一?quot;教练"（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。小组每个成员都应围绕用户代表，充分贡献自己的技能。
l 计划（Planning Game）。包括两类：交付计划和迭代（Iteration）计划，前者是在项目开始时对软件交付日期的粗略估计，后者是在每个迭代开始时对本次迭代的工作安排。二者都可在执行时调整，只不过迭代计划要更为具体和准确。
l 系统比拟（Metaphor）。系统比拟是待开发软件系统的一个形象化比喻，这个比喻必须是每个组员都熟悉的，它相当于一个粗略的软件体系结构（Architecture），使用户和开发人员建立一个一致的框架，从而指导开发的进行。
l 小交付（Small release）。经常交付可运行的、具有商业价值的小软件，供用户代表评估或最终使用。这里的"小"意味着软件模块能尽快（可在一个迭代内完成）、不断地交付。
l 测试（testing）。XP要求先开发测试用例(可自动执行)然后进行编码（testing then coding），而且测试要不断进行，保证代码测试要100%通过。分两种测试：单元测试和验收测试(Acceptance test)。单元测试由开发人员负责，验收测试由用户代表负责。
l 简洁设计（Simple Design）。有两个含义：一是设计只考虑当前定义的功能而不考虑以后需求的变化，二是指该设计是完成目前功能所需的最简洁的设计，要简单易懂、没有冗余。
l 结对开发（Pair Programming）。开发人员两人结一对，在一台机器前进行开发，一人打字编程另一人查看其编码，配对的两人是不固定的，建议每天轮换。
l 设计改进（Design Improvement）。在整个开发过程中，应对程序结构进行持续不断的梳理（Refactoring，在不影响程序的外部可见行为的情况下，按高内聚松耦合的原则对程序内部结构进行改进）, 保持代码简洁、无冗余。
l 持续集成（Continuous Integration）。保持项目组中所有开发的模块始终是组装完毕、集成良好且可执行的，一旦新的模块通过了单元测试，应立即将其组装、集成，形成新的可执行系统。
l 代码共享（Collective code Ownership）。任何结对开发者在任何时候都可改进项目组中的任何代码。
l 编码标准（Coding Standard）。对编程风格（命名、注释、格式等）要有一个大家认可的、共同遵守的标准，使整个程序如同一人编写。
l 可持续步调（Sustainable Pace）。整个项目的开发节奏应该是可长期维持的，XP提出每周40小时工作制，即不要加班，以使开发人员能长期保持工作的高效率。
3.1.3 XP开发过程：
l 整体开发过程
如图1所示，用户代表提出用户故事（User stories，类似于用例，但更简单，不超过三句话即可，一般只涉及功能要求），项目组据此进行讨论提出系统比拟，在此活动中有可能要进行体系结构的刺探（Spike,意在试探解决有关技术难点，走通技术路线）。在系统比拟和用户故事的基础上，根据用户设定的优先级制订交付计划（制订计划中可能需要对某个技术难点进行刺探），然后开始多个迭代过程（每个迭代一般为1~3周），在迭代期内产生的新用户故事不在本迭代内解决，以保证开发不受干扰。经验收测试通过后交付使用。
l 迭代过程
如图2所示。根据交付计划和项目速率（Project velocity,实际开发时间和估计时间的比率，如估计1天完成的工作实际为2天，项目速率为2），选择要优先完成的用户故事或待消除的Bugs，将其分解为可在1~2天内完成的任务，制定本次迭代计划，然后通过每天的站立会议（Stand up meeting,参加人员站着开会以缩短时间\提高效率）解决碰到的问题、调整迭代计划，会后是代码共享式的开发工作，开发人员要确保新功能100%通过单元测试，并立即组装形成新的可运行版本，由用户代表进行验收测试。
l 代码共享的编程
如图3所示。
3.1.4 XP的实践和发展
XP方法引起了世界各地广泛的注意，越来越多的项目组采用或正考虑采用XP方法。2001年7月，在美国北卡莱罗纳州举行了XP国际研讨会，会议上SEI、IBM、SAS等知名机构的专家作了专题演讲，表明了XP的活跃程度。
对XP的批评主要有两个：一是XP中的文档问题（几乎没有文档），对此Ron Jeffries的解释是，XP中的系统比拟、用户故事、和测试用例都是传统方法中的文档，另外，XP紧紧围绕用户代表展开，他可决定文档制作的程度；二是XP只强调共享与合作，另一个推动社会进步的因素-竞争并没有体现，为此许多XP的实践者对该方法作了一定程度的变通。
