1. 计划的制定

制定计划的目的是确定本次迭代的范围。

本步骤的重心应该放在决定什么是对客户来说最重要的任务和如何首先完成这些任务。

计划的制定包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。

2. 小版本

小版本这一实践背后的观点是：

• 用最少的代码工作量带来最大的业务价值。
• 程序的特性必须有原子性（不可分解）。
• 一个特性必须实现足够的功能来实现它的业务价值。
• 这个步骤可能是违反直觉的，但这样做是为了使项目尽快转化为产品。

发布小版本可以从客户那儿得到反馈和通过让客户确认这就是他们需要的软件来降低项目的风险。 基本上，这个步骤使用Paredo规则：20%的努力能带来80%的业务价值。

小版本在计划的制定下，一版接一版地发布来决定何种特性将带来巨大的影响，同时这也配合保持简单设计这一实践的实施。

3. 简单设计

简单的设计能保证代码的简单。

• 最简单的设计并不通过预测未来的需求来尝试未来的问题。
• 最简单的设计将软件的一个可测试版本交付给用户。
• 最简单的设计通过所有测试，没有重复和费解的逻辑代码，但能够表达每一个程序员的意图。
• 这个步骤伴随着小版本的发布。
• 如果你的系统架构不能够很好的表达和满足预期的需要，你将不能够尽快的交付。

我们是程序员，不是占卜者。我们没有水晶球，所以预测客户未来的需求最好的方法是给他们一个可以工作的系统，并且从他们那儿得到反馈。大多数客户不知道如何准确表达他们的需要，你交付一些他们能够切实可用的东西有助于缓解这种问题。记住，一幅图片胜过千言万语，一个工作模型抵得上一千幅图片。

4. 测试

测试是极限编程的核心。

测试应该是自动的，这样你会有信心和勇气来改变和重构代码，同时不破坏系统。这与瀑布开发模型正好相反。

5. 持续集成

持续集成是一个至关重要的概念。

为什么我们要等到项目的最后才检查系统的每一部分是否都能正常工作？ 每几个小时（至少一天一次）系统必须构建和测试一遍。通过经常这样做，你将能够知道何处的改变破坏了系统并作出调整，从而避免浪费时间一直等到修改已堆积成山并且你自己都忘记了修改的细节。

6. 重构

重构的使用确保程序员加入新的功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试。

这个实践的思想是不复制代码，也不写“丑陋”、“发臭”的代码。重构的重心在于测试能够验证代码仍然具备需要的功能。测试和重构交替进行。自动单元级（unit-level）测试给你勇气来重构和保持代码的简单和表现力。

7. 结对编程

结对编程大概是极限编程中最具革命性的实践—这通常是管理者最花时间来习惯的地方。

在表面上，他们的反应很容易理解：如果我们的项目进度落后了，那么怎样在同一个任务中使用两个程序员来提高开发速度呢？为什么需要两个程序员使用一个键盘和一个显示器呢？

首先，它增加了团队成员之间的交流。我们工作的很大一部分需要依靠其他程序员的工作。这个程序员今天和你在一个团队，不一定明天还有必要和你在一个团队。同样，如果一个人知道许多特定的技术（如：EJB或是Oralce）或者掌握专业领域的技能，试问有其他更好的方法比和那个人结对能更好地向对方学习吗？什么是质量？结对编程能提供持续的信息反馈和确保正在编程的人进行重构、测试和遵守编码标准。

8. 代码共享

代码共享这一极限编程中的实践表明任何一个人都能够对系统作出修改。

每个程序员都拥有系统的所有权和需要对系统负责。如果没有人了解某一特定细节，那么单元测试负责检验API和检查你的改变有没有破坏系统。 因此，你没有必要等到团队中的另一个成员来修正这个错误。如果不采用代码共享，并且在系统中有一些错误，那么每一个人必须停下来等待直到你将这个错误修复。

9. 每周只工作40小时

充分利用时间。

这一规则的隐含意思是统计的时间是处于高效率工作的有效时间和必须从你的工作时间中得到最大的收益。长时间的仁义应该避免。任何妨碍在下一个发布版本中提供最大商业价值的行为都应该被避免。劳累过度的程序员将犯下许多错误。

10. 现场客户

如果有可能，客户应该与程序员直接接触。

客户必须阐明需求的功能。客户也参与到计划的制定中，记录客户需求时，用程序员和客户都能理解的语言编写。

11. 隐喻

记录客户需求时，用程序员和客户都能理解的语言编写。

12. 编码标准

极限编程的实行者应该遵守编码标准这一实践。你必须能够明白其他程序员写的代码。