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

这个讲起来话题就大一些了，已经不再只是XP的概念了，迭代计划一般来说是根据产品或者项目的需求的策划或者分析，之后形成技术方面的文档，相应的对此进行划分，划分的每个阶段自然的就构成了迭代。

工作量的估计是比较困难的，特别是对于一个新组建的团队，这个主要还是通过经验的积累和task分解、CRC设计来实现，经验的积累的话主要是通过以往task的完成情况、时间来积累，在task的完成时间上我们严格要求在每天开始task之前在xplanner上记录下时间，停止不做这个task的时候再到xplanner上记录下时间，之后我们可以通过这些task的实际消耗时间来做数据分析，评估每个人的情况，软件方面要做到完全的量化是不太可能的，只是尽量的减小估算的误差;task分解的方面的话要尽量把task划的可控，基本是1--2天；结合CRC设计、情景测试就能更好的估算工作量了，如果在CRC设计时还有些迷惑的地方，那么就得做spike先。

除了XPlanner以外，大家还使用了什么其他的支持工具吗？

maven

结对编程给我的印象是不能用纪律约束，要凭一种心态来约束，大概的意思可能是结对双方都真正为团队的目标用力。因为纪律无法约束一个人是否和别人沟通，看的那方就闲呆着，你也没有证据判定他有没有投入，留一手之类的更无从判定。

总之团队成员差异过大，这里的差异指的是技术水平，思考方式甚至是生活态度的情况下，实施xp就变成一场灾难，讨论可能变为争吵，灵活可能变为无纪律，文档少不意味着交流多……

总之，团队成员的素质很大程度上决定着你们团队对于xp实施的成败

PP对于一个希望进步的人是多么的重要啊~
手把手得获得经验~~

通过最近的pp实践，发现在系统设计阶段结对，帮助项目组所有的成员对系统架构都有了明确的认识，收获很大
但是架构明确下来以后，剩下的工作就是具体需求的实现，很多都是重复性的编码工作，pp有没有意义还需要检验

跟楼上有同感。 我认为项目开始的时候，小组成员对项目的框架设计和编程规范通过讨论和PP 会有直接明确的认识。 后面很多体力活是没有必要PP的。 我们现在后期主要通过code reivew来保证规范和质量的保持。

PP之间合作得好的话，要比code review的效果好。关键还是要看是不是真正的PP，PP不是一个人写代码一个人在旁边看这么简单。要做到两个人同时思考一个问题还是比较有难度的，如果坚持做下来，就会有很大的收获了。

pp的三个主要目的是，1是增加项目成员的交流，2是增加项目成员对系统整体上的了解和知识的传播，3是加强产品的质量。开发初始阶段这3个目的还是很有效的达到的，但是后期第2个目的的效果就不是很明显了