在项目中正式的执行XP中的过程，除了PP由于暂时没实施，其他的都在实施中，虽然这点会被很多xper说，^_^，其实我也知道PP非常好，毕竟以前经历过，但由于某些原因，在现在的team中我还不好去执行，以后找到机会，呵呵.....
自己接触XP说起来也有两年多了，而且在以前的团队中也是采用这样的过程，但现在自己带team真的执行的时候却发现碰到一些问题，一方面可能是因为自己太久没温习XP，^_^，有些过程都不是那么记得了，另一方面是在执行的时候有些步骤确实不好走，在这样的情况下，回顾了手头的几篇XP的文档，从XP中对于整个软件过程的推行来看自己实施过程中的问题。
XP中对于整个软件过程的推行是这样的：
1、和客户一起分析需求，产生User Story，User Story的定义为用户对于需求的一段描述。
实际执行情况：由PM充当客户，由Team Leader根据PM的描述进行User Story的编写，而且由于User Story的定义不是那么明确，实际执行过程中有些迷惑，在这点上我现在的定义就是一个不可分解的独立、成功业务场景，此场景由场景过程和业务规则共同构成，现在的做法是根据Use Case，拿出其中那些不可分解的独立、成功的业务场景作为用户故事。
2、由团队中的Senior成员对User Story进行完成时间以及技术风险的评估，同时再给团队中的Junior成员对User Story进行完成时间以及技术风险的评估，最后合并两人的取平均值构成此User Story的完成时间以及技术风险的评估，如此时产生的User Story大于三周，则进行分解，如小于一周则进行合并。(注: 如出现无法评估的User Story，先进行Spike)
实际执行情况：之前对此过程不够明确，所以没有这么做，觉得以后可以考虑执行，不过疑问就在于Junior能做出评估吗？
3、由客户对用户故事进行商业价值以及商业风险的评估。
实际执行情况：恩，这步可行。
4、根据用户故事的技术风险、完成时间评估、商业价值、商业风险的评估来制定发布计划，制定的原则为商业价值优先。
实际执行情况：由于现在缺少步骤2，所以只是依照商业价值来制定。
5、根据发布计划以及用户故事团队共同想出系统隐喻。
实际执行情况：我认为系统隐喻其实就是架构设计，在这个步骤上在team中由架构设计小组完成。
6、根据发布计划制定迭代目标以及迭代计划，迭代控制在1－－3周。
实际执行情况：基本是这样的。
7、Team对迭代中的User Story进行CRC设计和任务分解，任务控制在大于一天小于三天的范围。
实际执行情况：由于没做步骤2，在迭代会议上首先是列出User Story，但并不进行完成时间的估计，而是先进行CRC设计，CRC设计中也有个疑点，可能是执行的不好，我对于CRC的做法是拿出用户故事中所出现的名词，并构成名词中的属性和方法，此时进行情景测试，此时自然就受架构约束才能完成，比如UI--->Action--->Service--->Dao这样一种过程才可通过情景测试(根据情景测试来弥补整个过程中不符合的设计)，就产生了CRC设计的UI、业务对象、Action、Service、Dao这些任务，在这个时候出现问题，就是在简单的User Story中这些任务就同样非常简单，甚至所有任务合在一起也才1天的这种情况，这对于XP来说其实是不符合的，这个时候再去做合并任务、合并User Story发现不是那么好做.......
8、由团队成员自行挑选任务。
实际执行情况：完整执行。
9、任务承担者进行TDD实现，每天挑选Pair一起进行。
实际执行情况：TDD方面由于我的理解不是很好，未良好执行，今天专门看了手头XP文档中TDD的部分，发现以前的做法确实很不正确，以后一定好好执行，就像编写一个简单的增加用户这样的方法，在TDD中首先应该考虑这个方法到底有哪些功能，然后在单元测试中进行编写，最后方法的实现完全根据单元测试来实现，而不编写超出单元测试范围的代码，PP由于目前team以及环境的原因，暂未执行，在将来我决定推行。
10、提交代码进行持续集成。
实际执行情况：完整执行，不过缺少TDD其实这块的意义已经不显得那么重要，不过我仍然觉得对于功能测试以及作为一个集成测试环境来讲非常重要，毕竟这是自动的。
11、迭代任务完成后发布迭代版本。
实际执行情况：完整执行。
12、进入下一个迭代。
上面只是对XP过程的一个简单描述，XP中还有很多重要的思想和原则都是值得分开了详细阐述和分析的：
简单、交流、反馈、勇气、站立早会、TDD等等。
以后有时间的时候一个一个来写写感触，呵呵。
在目前的团队实施的软件过程情况来看，个人觉得有几个方面是有非常好的效果的：
1、早会。耗不了多长时间却能起到很好的作用。
2、迭代会议。耗费时间是很长，但对于整个团队任务完成的情况来看是非常值得的，增加了团队的交流气氛，从而提升了整个团队的水平，让团队成员自行挑选任务可以让团队成员主动的去提高自己，提高工作方面的兴趣。
3、持续集成。非常有好处，至少避免总是要依靠一个人去做集成，而且项目组所有成员都能看到项目的进展，对于团队来说是种鼓励，呵呵，我在持续集成中还生成项目网站，觉得这个对于项目组以及领导层来说都很有效果。
4、xplanner进行任务跟踪。通过xplanner的任务跟踪提升整个团队对于任务完成时间的评估准确度，同时也比较准确的统计了团队的工作量。
ps：总体看下来，自己在XP整个实施上还是存在很多的问题，要吸取教训，以后努力改进，其实我一直坚持的一点，其实对于一个中小型项目来说，我真的不认为采用什么软件过程必然就是最好的，关键是需要一套适合团队的完整、规范的软件过程，这个很重要。