今天在网上查了下XP（eXtreme Programming）极限编程的使用时机发现我们以前做了的、现在正在做的、以及以后很长一段时间内将做的项目都符合条件，都可以使用极限编程，但是为什么不用呢？
先来看看来自UML工程组织的原文《XP(极限编程)应该在什么时候使用》
http://www.qualitytd.com/information/AboutXP.htm
文章不长直接引用如下：
[极限编程（XP）适用于需求经常发生变化的项目。你的客户对系统应该做什么可能没有一个固定的想法；一个系统每隔几个月其功能就要求进行一定的改变。大多数软件项目的需求都处于这样的动态变化之中。与其它的方法相比，XP能够更好地适应这种情况。
XP适用于高风险的项目。 如果客户需要一个新的系统，而且要求在某天前完成，这里的风险就比较高；如果你的开发组没有做过类似的系统，风险就更高了；如果该系统对整个软件业来说都是一个新的挑战，那这风险就可想而知。使用XP可以降低风险和增加成功的可能性。
XP适用于小规模的项目组，一般在2到10人之间。使用XP不需要拥有博士头衔的开发人员，一般的开发人员就可以。但不能在一个大型的项目组中采用XP。我们注意到，对于一个需求动态变化和高风险的项目而言，一小组XP开发人员要比大的开发组更加有效。
XP对项目组的组成人员有要求。组内不仅包括开发人员，还包括经理和客户，所有人员肩并肩地战斗在一起。软件开发中问题的讨论，项目范围和进度的协商，以及功能测试的创建仅靠开发人员是不够的。
XP对可测试性有要求。你必须建立自动的单元测试和功能测试。虽然在某些情况下这个要求不能满足，但事实上你会惊讶地看到通过某种方式仍然可以达到这个要求。比如可以通过修改系统的设计以使之已于测试。记住，只要你愿意就可以找到一种测试的方式。
XP对生产力也有要求。从已有的报告中，在相同条件下，所有采取XP的项目组都无一例外地比其它项目组的生产力高。但这从来不是XP的目的。XP的真正目的在于按时交付客户需要的软件。如果这对于你的项目而言很重要，你就可以尝试一下XP……]
首先看“XP适用于需求经常发生变化的项目”，目前国内软件环境可以说极大的一部分都是客户想把自己要求的系统做成什么样，连他们自己也说不清楚，在做需求分析的时候往往是一句“你们做出来我们看看是不是合适”搪塞，既然他们是衣食父母就应当满足他们的这些“不合理”要求，所以我们面对的大多数项目都是需求经常发生变化的项目，与其它的方法相比，XP能够更好地适应这种情况。
再看“XP适用于高风险的项目”， 我们的客户往往都是希望今天跟你谈业务明天最好你就能把他们想要的系统给他们，如果不是关系处理的好他们很难接受项目延期，风险当然可高可低，但是既然xp能降低风险为什么不试试呢？
接着来“ XP适用于小规模的项目组，一般在2到10人之间”，目前国内的软件行业以小公司居多，毋庸置疑的可以使用了，但是同样是该组织提供了一文章《大型项目的XP(极限编程)》http://www.uml.org.cn/SoftWareProcess/rjgc6.htm，我觉得上面的经验教训很好，值得借鉴。
还有“XP对项目组的组成人员有要求”，组内不仅包括开发人员，还包括经理和客户，所有人员肩并肩地战斗在一起。唯一难办到的是客户不能与组员并肩战斗，只有定期的叫他们来参与例会了。
再就是“XP对可测试性有要求”，自动的单元测试和功能测试，目前有很多提供测试的软件，如junit、nunit等，应该可以满足要求；
最后“XP对生产力也有要求”，从已有的报告中，在相同条件下，所有采取XP的项目组都无一例外地比其它项目组的生产力高。但这从来不是XP的目的。XP的真正目的在于按时交付客户需要的软件。这方面只能引用了，因为目前没有任何xp实践。
但是我们为什么会没用XP（eXtreme Programming）极限编程呢？