再说说XP方法的来源吧，XP的历史比敏捷开发宣言(2001)的历史要久，Kent正式提出这个方法并且出版书籍的时间是1999年，书的名字叫做《极限编程解析-拥抱变化》（Extreme Programming Explained-Embrace Change），看过这本书的人都喜欢说“拥抱变化”，而不是通常的响应变化或则适应变化。
在Kent Beck正式提出这个方法之前，他曾负责克莱斯勒公司内部的一个薪酬管理系统，在这个项目中，他采用一些与传统软件工程”相悖”的实践，加速的项目的进度，得到一些好的效果。所以他在1999年将这些好的实践，总结为极限编程。有趣的是，他所做的酬管理系统在2000也因为业务原因取消了，其开发方法却一直流传至今，成为重要的敏捷开发方法。Kent Bech非常喜欢软件开发，并且涉猎颇广，他写过书籍包括SmallTalk,Refactor,设计模式，Eclipes开发原则，测试驱动的开发，XP等等。
那么什么是极限编程呢？下面就是一些从他书里找到的答案:
我总结了一下，就是一种人性化开发方法，用于快速响应变化的情景。
XP在内容形式上很复杂，他在软件开发都不同周期都有很多具体的实践
1）小规模回馈(Fine Scale Feedback)
- 测试驱动开发
- 策划游戏
- 全部人员的合作和反馈
- 成对编程(peer programming)
2) 持续的流程(Continuous process)
- 持续集成
- 重构和设计改进
- 小型发布
3）达成共识(Shared Understanding)
- 简单的设计(Simple Design)
- 系统隐喻 (System Metaphor)
- 代码的集体负责制
- 程序设计标准
4)程序员的利益
- 持续发展的步骤(例如每周40小时工作）
那么在实践中具体实施的程度和效果如何呢？
XP从实施的可行性来说，全面实施的可能性很小，因为XP的规则贯穿在整个开发周期，很多原则的具体操作性不是很强。比如说Refactor，XP强调了重构的重要性，但是它不可能告诉你什么时候做重构，如何做；再比如说”成对编程”，概念挺好的，但是不是每个公司运行好这种模式，而且这种模式最后往往简化成Code Review。再如系统隐喻(System Metaphor，简单说就是代码本身中的方法名，变量名很好的解释了其功能)，众所周知，这是好的实践，但是如何保证它全面执行确实一个大难题。
XP的执行，其实对软件测试是有很大的挑战的，其原因如下：
在XP模式中，测试人员的定位模糊。 由于XP实际上大多都是开发的实践，其理念是将测试任务贯穿在开发过程中，尽量由开发人员完成，而不是专职的测试人员。这导致在执行当中，测试人员和开发人员的职责区分不是很明显。
XP强调的”拥抱变化“，实际上给测试进度和质量管理带来挑战。在很多应用下，虽然采用了XP开发方法，但是测试管理还是传统方式，导致管理上有很多不协调和冲突。
XP模式下，由于缺少专业测试人员的投入，软件的质量不容易把握。
其它相关文章
