XP只能是成熟的团队采用吗？

我以前带团队做过这方面的实践，可以说是有成功的地方也有失败的地方。我觉得楼主在实施XP的时候，更应该更加实际情况考量，而不是盲目地对XP中所有的实践进行照本宣科的实施，那样很容易出现问题。
  正如楼上许多朋友所说，起码有几点是可以的，比如测试驱动、小增量迭代，用户故事、现场开发（或者客户代表跟随合作）等都是可以的。但是我也指出一些我个人认为并不太合适的XP实践，简单讲，也就是三个：代码代替设计（当然XP中并不是这个意思，只是被很多人倾向于这样理解）、代码全局共享（也就是非预留的check out操作）、以及双人合作编码。对于上述三个实践，我可以说我并没有看到哪个网友或者团队成功的全部实施过，相反，我所遇到的问题一直也没有得到很好的解答（楼主如果有兴趣，可以看看以前的关于XP的一些帖子）。
   所以说，适量裁减，合理运用才是项目成功的关键。

非常同意你的说法，我并没有完全按照XP的实践来做，主要是根据项目情况采用了测试驱动、迭代、结对编程这几个，用户现场开发我们采用的是业务人员代替的方式。现在比较难进行的可能就是结对编程。大家觉得结对编程有什么问题吗？怎么解决吗？
我觉得最大的问题还是开发人员的习惯问题

我也来凑凑热闹，^_^，在以前公司的时候偶的经理很推崇XP，个人也很推崇，在以前的团队实施XP的时候我们希望的是全盘实施，诸如TDD、Iterator、User Story、CRC、情景测试、PP、持续集成等等，觉得除了PP对于大多数来讲初期难以接受之外，其他的都接受的算比较好的，当然TDD的实施也不是那么的完美，开源的倒是很多的TDD做的挺不错的。我们当时实施的时候也采用了PP，实话说，在那一个月的PP时间里，开发效率得到了很大的提高，PP中最重要的是结对的问题，个人觉得如果真的象XP中所说的随意结对，这种在中国可能会挺有问题的，PP的好处还是更多一些吧，提高开发效率，相互学习编程技巧以及统一整个团队的风格。
在接触了CMM的一些思想后，觉得XP中的缺点在于对于知识的积累不够。
应该来说XP对于团队的要求还是比较高的。

为什么会觉得知识的集累不够吗？CMM知识集累是靠很多的文档把，而XP是靠团场成员的交流加强知识的传播，增强每个成员对项目整体的了解，那个更有效呢？

楼上各位，我非常想知道你们对于结对编程的经验，是否可以介绍一下。因为在我所进行的XP实施中，最持有疑问的也就是结对编程和代码全局共享。

我讲的知识的积累不够主要还是指公司级的，没错，XP自己团队的知识的积累还算OK，但公司级呢？
知识的积累是需要依靠文档的。

PP的话我们以前的推行模式是这样的：
1、User Story编写
2、Task分解
3、CRC设计讨论
4、挑选Partner
5、Begin

PP要求在Begin之前Task Owner的两个人需要达成共识。
我比较赞成的是一个编写测试代码、一个编写实现代码

PP的好处在于毕竟各人思考方式的方法是不太一样的，而且PP对于团队的交流、团队的融合是很有帮助的。

反正我觉得如果要在团队中推行，就要得到团队的共识，或者就是采取不共识的人就直接T掉的方法！

User Story 编写和CRC讨论是团队所有人员都参加吗？
工作量的估计是什么时候进行的？
没有经常进行结对的轮换

恩，User Story 编写、Task分解和CRC讨论是团队所有人员都参加，之后由团队成员自己挑选Task，工作量的估计在此时进行

之后在开始这个Task的早会上大家挑选各自的Partner，基本是会经常轮换的

还是那句话，在团队中不管推行一种什么软件过程，需要得到团队的认同。

XP其实是很讲纪律的，诸如代码规范、TDD、持续集成等都是需要很强的规范和纪律性的。

想了解pp的话，还是自己亲自尝试一下比较好。每个人的感觉是不一样的。

你们的迭代计划是怎么做的？每次迭代完成那些功能怎么定？怎么估计工作量？