XP让人感觉很不舒服，人们会抵制它。这种抵制来自恐惧和骄傲。通过将使用XP作为一种战略，可以客服这些情绪，增加获胜的机会。
1968年奥林匹克运动会，Fosbury带着他的“Fosbury跳”一路过关斩将，获得金牌并创下了新的奥运会记录。“Fosbury跳”不同于以往面对横杆劈腿跳的方式，而采用后背过杆并且肩膀先着地。坦白说，这看上去很蠢！但是，人们很难用传统方式击败使用非传统方式的获胜者。
XP就是一种非传统战略！使用它，可以开发出按时交付并具有很高商业价值的伟大软件，而且不需要开发人员加班加点的工作！使用XP，会增加获胜的机会！
最后，不要只为XP而关注XP，不要成功一个狂热的XP追星族，反而忽略了产品方面的问题！
XP只是手段，而不是目标！
克服来自经理的抵触
——经理们会反对使用XP，因为他们在方法选择上有着错误的假设。将问题的焦点放在降低软件开发费用上，他们就不再反对了。
1、了解经理的目标，帮助经理成功
2、开发成本——研发和修改的金钱、时间；留住高级开发人员；普通开发人员的贡献。
3、可能的反对意见：
XP不成熟——不试过又怎么知道呢？实践是检验真理的唯一标准！现在的状态就没有风险么？就是最好的么？穷则变！
XP过分简单——kiss，简单就是美；XP简单，但是不过分；大部分文档不必要。
结对编程成本太高——一个臭皮匠，弄死三个诸葛亮:-)
全职现场客户难以应付——防止开发人员等待客户或者猜测需求；典型的需求文档只有15%是完整的，7%是正确的。
XP太不正式——不要试图用有趣的PowerPoint幻灯片和PDF文档来掩盖问题。提供足够的文档，但绝不要提供不必要的文档：计划游戏、系统隐喻、需求故事、测试用例（关注结果）。
“XP的局限”——不要将XP当做百宝箱，什么都从里面拿，要知道他是一个整体，单一的实践可能立即产生正面的影响，从而让人们接受随后采用的其他实践，但是有可能造成不良后果。如：开发人员仅偶尔结对编程、不再编写文档，这样会缺少有价值的反馈。
克服来自开发人员的抵触
——开发人员会反对使用XP，因为他们可能看不到XP的优势。将问题的焦点放在XP的支持环境上，他们就不再反对了。
1、开发人员，喜欢跟机器交流，不喜欢跟人沟通。
2、开发人员希望：
开发软件，而不是编写文档或整日开会；
为自己开发的软件产品而自豪；
工作中得到乐趣；
一旦软件发行，再也不用去维护该产品。喜欢新的挑战，而不是给老代码补补丁。
3、可能的反对意见：
XP过分简单——真正含义是：“我学过其他软件方法，我的工作也因此取得了成绩，我不想再倒退。除此之外，在编程上我已经不像以前那么出色了，因为我还要花很多时间做一些‘更高级别的事情’。”
我不喜欢结对编程——开发人员不习惯成群的狩猎；而且认为没有个人代码的拥有权，就很难成为编程英雄。强调知识共享、改进代码质量及增强士气。(开发人员不喜欢代码被审查，也不喜欢审查别人的代码，尽管审查已经被证实在保证软件质量方面起着巨人的作用。几项研究同时表明，代码审查是对代码质量的最大贡献，甚至超过了测试！)结对编程比同行评审有过之而无不及！
XP稀奇古怪——编写代码前先编写测试用例并运行测试用例–代码变简单，因为仅需要通过测试即可，也不再担心别人修改自己的代码，测试用例也被当做很好的文档；允许不断改进设计以符合变化的需求–渐进的递增的设计，需求中的变化不是大量修改的借口；结对编程，经常要共享单个键盘和鼠标。
XP没有提供足够的信息——开发人员不喜欢创建文档，甚至一个都不想创建，但是他们喜欢有足够的信息指导工作。经常有没有足够的设计文档，过分依赖需求故事代替规格说明书，XP导致失败！把代码当做最好的文档！XP不是建议不编写文档，而是说不应该花时间去创建不毕业的文档。
——必要的文档：面向维护——wiki风格的常见问题数据库（10个类一页）；技术备忘录（20个类一页）；清晰一致的验收测试规则；测试用例和代码
——每天一个短会；测试用例针对逻辑而不是UI；需求和估算写在卡片上。