请教几个关于xp实践中遇到的具体问题

呵呵，这可是千真万确的，：）最终用户对于使用不是最终的发布版本不感兴趣。
多半情况下，都希望在你都测试好了以后再使用。在多数情况下用户是为了工作才会使用开发的系统，而不是兴趣。
不过不要紧，把你们的测试员当作用户就是了，他会负责的使用迭代完成的产品，并给出相应的反馈。

xp相关的书和文章其实我也看过不少了，很多都是理论上的，看着好，但操作起来就有问题。不过你说的那本书我到还真没看过，有机会一定买一本。


呵呵，因为整个项目组水平参差不齐，有些人是TDD，有些人还不是，虽然我要求了，也讲过大道理，但他们暂时还做不到，主要是他们还没有亲身体会到TDD的好处，但不管怎样，测试代码还是有的。


这一点partech已经说得比较清楚了。很多情况下，用户对于让我们开发的系统并没有很迫切的需要。甚至有时候他们根本就不需要这样的系统。也许你会奇怪了，那他们还花钱作系统干吗？国家的钱不花白不花，搞政绩呗。所以在整个的开发过程中，没有人（主要是说话算话的人）来配合，来提需求，一般都是在最后快验收的时候才会有人来说上一大堆废话  。也许你又会问，既然用户根本就不重视，那糊弄一下就完了呗？唉，要是那样就好了，因为用户都怕担责任，即使验收了也没有人来用的系统，在验收的时候他们也会百般挑剔的。


这点主要是公司的老总不同意呀，他们认识不到这样做的好处，甚至很多技术人员也认识不到，周围没有一家公司采用结对编程，所以至少我们公司是不敢第一个吃这个螃蟹的。再说采用结对编程，弄不好还会出现很多新的管理上的问题也说不定呢。

如果没有现场客户，而且可能对于进度可见性要求不强烈（从你说的情况来看就是如此），交给他们testcase就可以了。
关键还不是知识的共享，而是可以把知识转化为生产力。PP是一种方式，当然还可以可以采取代码共享，定期总结（密度要大一些，比如一周一次），集体设计，任务共享，多种方式促进知识的传递。

首先你的认识要提高，至少我发现多数人还希望能从整体上对项目有一个理解和把握（至少他们这样做以后，发生冲突他们可以有更多阐述自己做法的理由）。而且需求如果只是一些文档，我想任何人都不会有太多的兴趣看，你需要组织需求建模头脑风暴会议，以使大家从开始就对需求能够有一个大概的理解。
需求应该是所有的人的，你不应该从开始就设定个别人只完成个别的需求，而是要把需求划分为细小的颗粒，并且大家共同参与这个划分的过程。在中国结对编程其实是最容易实现的一个方法，主要还是在于管理者是不是可以支持。你可以采取鼓励共享任务的方式，也就是两个人共同完成他们的任务，这样他们会有机会去PP。
所以你需要PP，你可以从自己开始和一个菜鸟结对。而且重构也是解决问题的一个方法。

其实对于一个还没有太多XP经验的组织，而且也没有专门熟悉XP过程的教练，你们可以从持续集成、重构、TDD这三个最佳实践开始。然后在引入其他。

我们现在其实也大致是这么做的，可总觉得这样已经变味了。毕竟测试人员不是真正的用户啊，他们也只能测试有没有bug，跟需求相关的他们肯定测试不出来。到验收之前给用户作汇报的时候，用户肯定又会提出大量的需求变更，然后自然又是延期，呵呵。有时候真的感觉很无奈~~
因为我觉得不论是xp也好还是rup也好最核心的东西还是需求，用户的配合，这点保证不了应该一切都是美好的愿望了。

呵呵，对付这种用户，早期交付仍然是一个比较好的策略。
你应该在你的计划内安排好预先的迭代。
比如整个项目为12个月，你应该在3个月的时候就提交第一个版本，就说已经基本开发完毕了，要求用户初验……

TDD是解决需求问题的目前最好的一个技术手段。当然如果你们能够有一个强力的业务专家系统，那么需求问题也好解决。
实际上需求并不是最重要的，既便你能够完全理解用户的需求，也并不代表你们能够完成他们的目标。实际上客户需要的是究竟如何可以完成他们的业务目标，而具体的需求对于他们来说只是手段而已。因此SAP这样的公司才能成功。

一个精通业务的需求人员，不管是在XP还是UP中都很重要，后面的设计、测试和实现都要依赖于它，哪里出的问题就需要加强哪里，需求出现问题，不可能通过测试来弥补，测试错误的需求是在浪费生命。

关于XP的实践，我个人认为能够做到并且能够切实感受到带来好处的原则，就可以
慢慢尝试一下，最好自己先熟练了，再介绍到团队，这样心里就有底了。