极限编程

极限编程（XP）是一种软件开发方法，旨在提高软件质量和对不断变化的客户需求的响应能力。作为一种敏捷软件开发，提倡在较短的开发周期中频繁发布“版本”，旨在提高生产率并引入可以采用新客户要求的检查点。

极限编程的其他元素包括：成对编程或进行大量代码审查，对所有代码进行单元测试，直到实际需要时才进行编程功能，平坦的管理结构，代码简单明了，随着时间的流逝预期客户需求的变化问题得到了更好的理解，并与客户以及程序员之间进行了频繁的沟通。该方法的名称来源于将传统软件工程实践的有益要素带到“极端”水平的想法。例如，代码审查被认为是有益的做法；极端地讲，代码可以连续进行审查（即结对编程的实践）。

构成XP基础的原则基于刚刚描述的值，旨在促进系统开发项目中的决策。原则旨在比价值观更具体，并且在实际情况下更容易转化为指导。

如果频繁且迅速地进行极限编程，反馈将是最有用的。它强调，动作与反馈之间的最小延迟对于学习和进行更改至关重要。与传统的系统开发方法不同，与客户联系的频率更高。客户对正在开发的系统有清晰的洞察力，可以提供反馈并根据需要引导开发。在客户频繁反馈的情况下，在开发人员花费大量时间实施它之前，开发人员会迅速注意到并纠正错误的设计决策。

单元测试有助于快速反馈原理。在编写代码时，运行单元测试可提供有关系统如何对所做更改做出反应的直接反馈。这不仅包括运行测试开发人员代码的单元测试，而且还包括使用可以由单个命令启动的自动化过程针对所有软件运行所有单元测试。这样，如果开发人员的更改导致开发人员几乎不了解或一无所知的系统其他部分发生故障，则自动全单元测试套件将立即显示故障，并向开发人员发出与其更改不兼容的警告。系统的其他部分，以及删除或修改其更改的必要性。在传统的开发惯例下，由于缺乏自动化，全面的单元测试套件意味着，开发人员认为无害的这种代码更改将留在原地，仅在集成测试期间才出现，或者更糟的是仅在生产中出现；在集成测试之前的几周甚至几个月内，在所有开发人员进行的所有更改中，确定导致问题的代码更改是一项艰巨的任务。

这是关于将每个问题视为“极其简单”的解决方案。传统的系统开发方法说，要为将来做计划并为可重用性编写代码。极限编程拒绝了这些想法。

极限编程的倡导者说，一次进行大的更改是行不通的。极限编程会应用增量更改：例如，系统可能每三周发布一次较小的版本。当采取许多小步骤时，客户可以更好地控制开发过程和正在开发的系统。

拥抱变化的原则是不与变化作斗争，而是拥抱变化。例如，如果在一次迭代会议中，客户的需求似乎发生了巨大变化，程序员将接受此需求并为下一次迭代计划新的需求。

ThoughtWorks声称在多达60人的分布式XP项目上取得了合理的成功。

2004年，随着XP的发展，引入了工业极限编程（IXP）。它旨在带来在大型分布式团队中工作的能力。现在，它拥有23种实践和灵活的价值观。

2003年，Matt Stephens和Doug Rosenberg出版了《极限编程重构：XP的案例》，质疑XP流程的价值并提出了改进XP的方法。这在文章，Internet新闻组和网站聊天区域引发了漫长的辩论。该书的核心论点是XP的实践是相互依赖的，但是很少有实践组织愿意/能够采用所有实践。因此，整个过程将失败。该书还提出了其他批评，并以消极的方式将XP的“集体所有权”模式与社会主义相提并论。

自从极限编程的发行发布以来，XP的某些方面发生了变化; 尤其是XP，现在只要可以实现所需的目标，就可以对实践进行修改。XP还对流程使用越来越通用的术语。有人认为，这些变化使先前的批评无效。其他人则声称，这只是在简化整个过程。

其他作者试图将XP与较旧的方法进行协调，以形成统一的方法。其中一些XP寻求替代，例如Waterfall方法；示例：项目生命周期：瀑布式，快速应用程序开发（RAD）等。摩根大通公司（JPMorgan Chase＆Co.）尝试将XP与能力成熟度模型集成（CMMI）和六西格玛（Six Sigma）的计算机编程方法相结合。他们发现这三个系统相互加强，导致更好的发展，并且没有相互矛盾。