随便说说
先说什么样的情况不适合xp
1. 大型和超大型的软件项目
受限于沟通成本和人力资源限制， 大一点的软件项目很难有效实施xp，即便是把团队拆分成多个xp小组，随着规模的扩大，也会面临沟通机制失效而彻底失控的局面。
而xp强调以人为本，强调充分发挥个体程序员的能力，强调有效沟通，对程序员本身的综合素质（注意不是单纯的技术能力）是有相当要求的，对于大型项目，正如DEATH TO MARCH中的指出的， 人力资源永远都是一个问题， 规模越大的项目可以获得的合格程序员就越少， 越容易失控。

20个人在xp团队是个很尴尬的数字，对于一个团队来说，太大，拆分成2个团队，又有点多余，而对于新建的xp团队来说，应该从小规模做起，6-8人组比较妥当。


2. 做不到和用户穿一条裤子的项目

xp和很多人的想法完全相反，他真正的核心在于站在用户的立场上去考虑软件开发， 所以如果项目团队做不到这种立场的转换，则必然失败，而反过来，如果用户还是抱着那种收钥匙的态度做项目，不愿意或者没有能力在项目中全程参与，那么也基本意味着失败了， 用户缺乏合作条件时固然可以使用有经验的分析员或项目经理代表用户，但是可以预计大部分情况下，大部分项目会缺乏这样富有经验能有效抓稳用户需求的人。而更大的问题是，现在业界的一贯作风，包括18mo，hp这样的公司，对用户也是坚持一种坑蒙拐骗，软硬兼施的态度，效果可想而知，所以xp一般在企业内部会更容易实施。

这条实际是xp能否正确实施的关键，如果做不到这点，就不要玩xp。相当多的xp团队，实际上也没有做到这点， 很多人错误的把xp理解为程序员的狂欢，因此而极力鼓吹xp，这也是xp获得坏名声的一个原因。

3.  boss，qc，团队成员未能结成共识， 团队内部结构不合理也缺乏对敏捷开发的认可。

对于boss和qc部门来说， xp项目的初期往往呈现出一种极度的混乱，要把这种混乱过渡到正常的，有序的混乱，需要相当的时间，xp项目在初期因此很容易被cancel了。如果不能和boss，qc部门做有效的沟通，那么需要花很多的精力在这些无谓的工作上。比如说，xp团队是把qc做为开发人员的责任，要求qc全程融入开发过程，而一些大公司的qc部门，更习惯和开发团队分开工作，只承担过程检查和质量验收的工作，这是有问题的。

一个理想的团队结构是接近金字塔的结构，有层次，而层次和各层之间能紧密耦合（具有良好的沟通协商机制）， 但是很多中小公司往往不具备这样的结构。很多有经验的程序员，尤其在国内，往往缺乏有效沟通和交流的能力，他们更习惯于单兵作战，不擅长协作和团队学习，这些程序员在实施xp的过程中往往会成为巨大的阻力，直接导致xp项目实施的失败。我个人的经验，花费巨大的精力试图去转换这部分程序员，基本是不可能完成的任务。

国内程序员的文化里面， 以技压人是一个核心， 如果一个团队缺乏塔尖的技术leader，是很难组织起有效的沟通文化的，这和很多外包团队不同，他们的leader并不需要有太强的技术能力。而这个leader如果只是一个单纯的技术上的geek，不是一个不喜欢团队学习的人，或者还没学会如何把手下当牛使， 实施xp也有相当大的风险。

一个xp团队的建设，在早期leader需要花费大量的精力和大家达成共识，让大家认可和接受xp的工作模式，尽可能在项目的早期让成员体会到其中的好处，但是在国内缺乏有效的顾问团队的情况下， coach这个角色很难找到合适的，也只能完全靠摸索。所以项目的早期往往能决定成败。xp强调的是发挥人的主动性，如果无法让团队成员真正理解，支持这一点，同意自发的改变他们传统的工作模式，全靠boss或者leader的强制推行的话（这实际就是xp极力反对的），是注定失败的。

如果无法改变团队成员结构，无法和团队成员达成共识，则应该尊重团队人员的实际能力和意愿，采取更合适的开发方法。

国内的xper在推行xp的过程中，都很容易忽略一点，国内程序员文化和西方程序员文化是截然不同的 ，鬼子越是精英的人，越喜欢合作，国内刚好相反。所以在国内最容易组建的xp团队，往往是由1，2个骨干和大量菜鸟构成的，白纸最好画。一些彼此关系融洽，长期合作的老鸟，也很适合组成xp团队。

上面说的是什么样的情况不适合做xp，实际上，我用了2，3年的时间才逐渐明白这些东西。至于如何做好xp，那是一个很长很长的话题，而正如我前后所提，大部分项目并不适合做xp， 图壁哦闹得图壁，你需要先考虑清楚这个问题。

顺便解释一下xp的某些误区

1. xp很适合做engineering的项目，很多xp项目都是这个类型的， 实际上，我最早接触的xp概念来自hp， 国内最早开始推广xp的人也来自hp的电子商务团队。不过因为前面2的原因， xp最适合做大企业内部的项目，或者产品研发性质的项目。

2. xp和scrum没有等同关系， xp和scrum，iconix，crystal，fdd都是Agile运动的主力， 如果说他们之间有关系的话，那个关系就是agile的核心，软件开发以人为本。
scrum和icons相对xp没有那么激进，更适合那种传统上已经建立了过程管理机制的团队。fdd是个很好玩的东西， 创建者更是一个传奇，有兴趣的同学可以找找看看。 弄清楚xp和agile的区别，你会明白，你其实还有很多选择。

【G：xp算是agile中最激进的一种了，有个老板曾经说过，辛辛苦苦几十年一下回到解放前】

3. 大部分号称是xp的项目实际都不是xp，原因请对照上面3条和下面的6。基于国内程序员文化和国外的巨大差异，还有业界的生存空间的惨烈状况等等，单纯的xp很难玩。在我看过的几个公司，所谓的xp都变成老板玩程序员的游戏或者变成程序员玩老板的游戏。xp在国内已经变成一个符号，一种时尚。 有个笑话，我以前一个同事管理的项目，某人要辞职回家去研究xp，说要花半年时间在家里独自刻苦钻研，彻底掌握xp精髓再出来工作，弄得我哭笑不得。


4. 国内大公司做CMMI，CMM是主流， 表面上 CMM和xp是完全对立的东西，最容易引起直接冲突的是文档问题，但是实际没有根本意义上的冲突，可惜能真正理解到这一层的人不多，所以对于实施CMM、CMMI或者强调过程化的公司，XP注定是很容易失败的。玩rup平稳的多，虽然罕见有人能玩好，但是至少能多解决一些人的就业问题

5. 传统的软件工程和学院派，最主要是服务商强调的是通过制度和工具来回避人力资源的问题，不管好汗孬种全部螺丝钉花，大家都流水线。而xp强调的是极度发挥个人的能力来提高软件开发效率间接解决人力资源的问题， 这2者代表了解决方式的两个极端，所以xper和传统教授学者整天打架。 有趣的是，我认识的一个很有见地的一个美国名牌商学院的教授，也极力支持前者，并再三鼓吹工具终究能代替一般程序员，呵呵，我觉得有趣的原因是他在技术问题上发表过一些相当有水准和这个观点根本是对立的文章，看来还是屁股决定了脑袋的立场。
[G:其实人家是商学院的，当然要支持了，这叫市场策划]

6. xp的那些最佳实践都不是xp首创的， 这些实践只是业界对软件开发过程中的一些有效经验的总结，所以同样可以使用在其他类型的开发过程中，并取得很好的效果。 xp中最难接受的2个实践TDD和PP也是如此，用在别的过程里一样困难，但是用好了一样舒服。而xp的独特在于强调这些实践的综合利用，利用彼此之间是互补和互相推动关系来达到最佳效果，所以一直有不实践所有最佳实践就不是xp的说法。 比如TDD和PP, 某些人对TDD方式产生的代码质量有质疑，而xp中实际是通过PP来弥补单纯TDD的代码覆盖率问题的。 所以我个人觉得，选择什么样的开发方法， 都应该看一下xp和rup的相关东西，能开阔你的思路，当然里面的大量问题，都只能通过实践才能吃透。

作为一个项目管理者应该明白一点， 没有任何方法和过程是万能的，有效的项目管理应该关注的是如何用好手中的牌，尽可能的玩好这一局， xp只是其中的一种可能性选择而已。

xp的精髓在一些传统的著作里面都可以找到，推荐看一下人月神话， Death to MARCH ， xp中文系列书籍里面有一本玩者致胜（play to winning？），对我帮助很大，可以看看， 另外国内有个人写了一本关于xp实践的书，里面的经验教训总结的非常好，基本都是当年我曾经碰到过的，也绞尽脑汁要解决的，很值得读，好像叫极限编程的实践与镜像之类的吧。不好意思，离开软件开发这个行业好几年了， 记不准确了。 另外如果下定决心要这么玩的话，现在已经有条件可以请顾问了，建议请TW中国的人来顾问一下，这可以省掉很多弯路，否则，可能光为怎么做是xp都pk半年。