自从其诞生以来，极限编程一直在发展，并且极限编程实践在其他敏捷方法中也被认为是有效的。

下表显示了极限编程实践是如何演变的。

现场客户–整个团队

极限编程依赖于一个以团队为中心的方法的项目社区。极限编程项目的所有贡献者，包括客户，都是一个团队。

客户提供需求，设置优先级并指导项目。这使客户能够了解开发的实际细节，并据此设定优先级和期望。这从“当客户要求开发时”变为“当客户理解并合作开发时”。

项目目标是共同的责任，开发是整个团队之间的持续对话。这是发明与交流的合作游戏。发现面对面交流是发展路径上最有效，最有效的方法，它消除了等待时间和延迟。

规划游戏–发布和迭代规划

发现增量项目计划是有效的，因为它可以促进准确的计划。随着开发的进行，将根据实际性能获得更多更好的信息。首先制定一个粗略的计划，然后逐步完善。

发布计划设定了长期目标，并掌握了总体情况。客户提供所需的功能，开发人员估计和发布日期是双方同意并承诺的。由于每次发布后都会对发布计划进行修订，因此随着项目的进行，发布计划将变得更加精确。

迭代计划设置带有迭代的短期时间范围，通常为1周到1个月。迭代计划的主要目标是在每次迭代结束时都可以使用的软件。开发人员选择迭代的功能/故事，将其分解为任务，估计任务并提交分配的任务。考虑每周40小时的工作量，通过平衡整个团队的工作量来确保可持续的步伐。

验收测试

客户为一项功能编写一个或多个自动验收测试，以确保系统正确实现所需的功能。验收测试与故事一起编写，并在实施之前提供。

团队会自动执行这些测试，以验证功能是否正确实施。测试运行后，团队将执行之前执行的所有验收测试，以确保此后在回归之时正确运行。

验收测试提供功能需求的明确说明。此外，通过验收测试的百分比可衡量发布完成情况，而不会在最后一刻出现意外。

该系统始终在改进，并且从未出现过下滑。

单元测试

开发人员编写足够覆盖的单元测试，并结合代码模块和方法的意图和用法。单元测试是自动化的，通过/未通过明确。大多数语言都有xUnit框架(例如，nUnit，jUnit)。

所有单元测试都非常频繁地执行，并且在所有单元测试通过之前，无法检入代码。单元测试结果也有助于重构。

测试驱动开发

测试驱动开发被认为是最具创新性的极限编程实践。

在“测试驱动开发”中，开发人员在编写代码之前先编写单元测试。目的是使单元测试失败。由于代码尚未实现，因此单元测试失败。开发人员只编写足够的代码以使单元测试通过，然后，开发人员进行重构以确保该代码简单，干净(没有重复和复杂性)。

开发人员进行迭代，直到编码完成并且验收测试通过。

单元测试全部收集在一起，每当一对测试集成并向存储库发布代码时，他们就需要确保每个测试都能正确运行。如果任何测试失败，那对夫妇就会知道，在通过先前的集成而没有任何缺陷的情况下，需要更正其代码。

测试驱动开发往往会导致100％的单元测试覆盖率，并确保代码简单而最少。

重构–设计改进

重构使设计可以逐步发展，使其保持简单，消除重复和复杂的情况。它改进了现有代码的设计，而无需通过重构来更改其功能。

重构应该通过学习新的实现来驱动。建议在编写新代码后立即进行重构。重构将代码驱动到更高级别的设计模式，并得到测试的支持。

40小时工作周–可持续发展步伐

工作可以无限期地持续下去。考虑到以下事实，可持续步伐确保了人类对项目成功的贡献：

• 疲劳和压力会降低生产率，还会降低产品质量。这可能导致人员流失。

• 发展不止于冲刺，而应着眼于长期目标

• 除非团队同意期望，否则就不会有承诺和责任感。

• 确切的时间不如表现能力那么重要。

• 应避免进行微观管理，同时确保按需提供可用性