极限编程简称XP，主要适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学。
XP流派的主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。
如果做软件不能按时交付，也就不能创造价值，这不仅会造成经济损失，而且对当事人本身也有很大的影响。我们需要找一种新的方法来开发软件（非常有必要）。软件开发的基本问题是其风险，进度延迟、项目取消、系统恶化、缺陷率、业务误解、业务变更、错误特别多、人员调整。因为项目需求的极度不确定性，导致开发人员的工作变得极度复杂，做了又改，改了又全部否定，重做后发现还是第一版的好，再改回去。最后导致项目延期，缺陷率太高而发布失败，如果项目做到这种地步，不全是客户的原因，项目管理者也有责任。
控制项目的共有四个变量--成本、时间、质量和范围。其中，范围的控制最有价值，在这个模型中，软件开发的游戏规则是让外力（客户、管理人员）确定任意三个变量的值，而开发团队确定第四个变量的结果值。很多管理人员和客户认为他们可以确定所有四个变量的值。“你要用这个小组在下个月一号前达到所有这些需求。质量是这儿的首要工作，所以它应该达到通常的标准”，这种情况下，质量总是被抛在脑后，这是因为在太大的压力下，没有人能做好工作。时间上也可能会失控，最后你得到的是蹩脚的软件。解决的办法是，让这四个变量变得可见。如果程序员、客户、管理人员都能看到所有这四个变量，他们就能有意识地选择控制哪些变量。如果不喜欢第四个变量得出的结果，他们可以改变输入，或者选择控制另外三个变量。
做项目最重要的就是范围，客户不能告诉我们他们想要什么，而当我们给出他们所说的需要的东西时，他们又不喜欢，软件的开发会改变软件本身的需求。一旦客户见到第一个版本，他们就明白了在第二个版本中他们需要的东西。或者他们在第一版本中实际想要什么。要是我们把需求的这种“柔性”看作一个机会，而不是问题，会怎么样呢？那么，我们就可以选择将范围当作四个变量中最容易控制的。我们可以对它进行塑造，如果到发行日期的时间变得紧张，那么总会有一些东西可以延期到下一个版本。通过不去试图完成太多的功能，我们就可以保持能力按时实现满足质量的产品。然而，现实中的客户总是异想天开，要求即保证质量，又不断扩大范围，还要求按时发布版本，换来的就是无尽的加班，质量是最先被忽略的，也就意味着BUG在不断的被生产中，项目将陷入恶性循环。
项目会经常改变方向，这必须是一个容易包容变化的过程，我们也不想在没人使用的软件上浪费太多，必须将变化的成本保持在合理的范围内。为了避免丢弃重要功能，舍得是很有必要的，首先实现客户最重要的需求，这样如果不得不放弃别的功能，那么这个功能也不能比已经在这个系统的其他功能重要，这需要管理人员深刻地和客户沟通，否则客户就真理了，如果真的确定不了，等待要比现在实现它更好，避免无谓的劳作。