极限编程简介
极限编程是以简单、沟通、反馈、勇气和尊重为价值观的软件工程方法学，是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。
极限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。它的工作原理是将整个团队聚集在一起，进行简单的实践，并提供足够的反馈，使团队能够看到他们的现状，并根据他们的独特情况调整实践。
创始者是肯特·贝克、沃德·坎宁安和罗恩·杰弗里斯，作为几种流行的敏捷框架之一，它已经被证明在世界各地不同规模和行业的多数公司都非常成功。
发展历史
Kent Beck在克莱斯勒综合薪酬系统（C3）工资项目中开发了极端编程。Beck于1996年3月成为C3项目负责人。他开始完善项目中使用的开发方法论，并写了一本关于该方法论的书（《极限编程解释》，1999年10月出版）。在《极限编程解释》第二版（2004年11月）中，即在第一版五年后，Beck添加了更多的价值观和实践，并区分了基础实践和必需实践。
许多极限编程实践已经存在了一段时间；该方法将“最佳实践”提升到了极致。例如，早在20世纪60年代初，美国国家航空航天局的水星计划就采用了“在每次微增量之前先测试开发、规划和编写测试的做法”。为了缩短总的开发时间，一些正式的测试文档（如验收测试）与准备测试的软件并行开发。在程序员编写软件并将其与硬件集成之前，NASA独立的测试小组可以根据正式要求和逻辑限制编写测试程序。XP将这一概念发挥到了极致，编写了自动化测试（有时在软件模块内部），即使是软件编码的小部分也能验证其操作，而不仅仅是测试更大的功能。
价值观
沟通，极限程序员经常与他们的客户和程序员同事交流。每个人都是团队的一分子，每天面对面交流，并且将在从需求到代码的所有方面进行合作，共同创造最佳解决方案。
简单，团队保持自己的设计简洁明了，做恰好满足需要和要求做的事情，致力于投资价值的最大化。通过采取简单的步骤来实现团队的目标，减轻失败带来的影响。创造我们引以为豪的东西，并以合理的成本长期维护它。
反馈，团队通过从第一天开始测试软件来获得反馈。团队将通过交付可工作的软件认真对待每一次迭代承诺，尽早展示软件，然后经常仔细聆听反馈，并据此做出任何需要的更改。团队将讨论每个项目，并使我们的流程适应它，而不是背道而驰。
尊重，作为一名有价值的团队成员，每个人都给予并感受到了应有的尊重。每个人都贡献价值，哪怕只是热情。开发人员尊重客户的专业知识，反之亦然。管理层也尊重团队对自己的工作承担责任和获得权力的权利。通过尽早将系统交付给客户，并根据建议实施更改。每一次小小的成功都加深了他们对每一位团队成员独特贡献的尊重。
勇气，有了以上的基础，团队能够勇敢地响应不断变化的需求和技术，也将能够说出有关进度和估算的真相，不会为失败记录借口，大家共同聚焦于为成功而计划。团队无所畏惧，因为没有一个人是单兵作战。一旦变化发生，团队会立即适应。
极限编程项目过程全貌
