乱弹XP !

估计很多人都读过Robert C. Martin著的< Agile Software Development > -- <敏捷软件开发>

。很多读者都对这本书提到的原则，模式赞叹不已，但是对于真正想学习XP并实践XP的读者来说，我想这其中可能会有很多人没有捉住要点（包括我，555），因为被那些占去80%篇幅的设计模式吸引了注意力。

理论高于实践，实践出理论。

其实，对于真正想向Robert大叔学习XP经验的读者来说，最有意义的文字是第三章和第四章。这里，我向大伙提个小小的建议：请大家再仔细的思考（而不是看）一下4.1.2 和4.2 章节。

经历了一次实际的项目实践后，我对XP有了新的认识。

下面是一些流水帐式的总结：

1）对于Xp实施的PM来说，他必须清楚XP实施下的项目管理方法，懂得用哪些工具能够真正融入到XP开发中的。Potian对此有独到而深刻的见解。 参照他在javaeye上发表的帖子：http://forum.iteye.com/viewtopic.php?t=8355

     对他的这个帖子我提些个人的补充/意见（别拿罐头砸我啊！）：

1.        用户故事卡，任务卡，编码卡可以用一个好的XP项目管理工具来替代，我推荐Xplanner。编码卡可以用Word文档编写，这些卡片文档的格式可以在项目开始时统一定制一个简单模版。这些所有的卡片文档必须方便大家随时查阅和修改，我们一般把它们作为附件发布在整个项目管理中。

2.        PM选择合适的方法提供一个能够直观反映整个项目进度的图示，以便任何一个项目组成员都能够直观了解整个项目的进度。

3.        具体的验收测试（功能测试）的方法（指客户/业务代表所写的测试脚本）需要根据具体的项目来制定，而且这个选择应该作为整个项目基础设计的一个基础要素考虑在内，因为它对整个架构设计有重大的影响。具体的分析在后面。

2） 测试在具体的XP开发中，具有举足轻重的作用。它可以影响设计，反过来，设计也会影响它。在具体的设计中，务必考虑代码的单元测试的可测性和易测性。比如，在传统的ORM开发中，很多人喜欢把DAO和业务逻辑Service （这里不讨论富含业务逻辑的领域模型） 放在一起，类似这样

         Public class ***ServiceImpl extends Abstract***DAO implements ***Service{

         …

         }

，如果考虑到对复杂Service的单元测试，我们需要单独抽取一个DAO出来，形成这样的组合关系：

         Public class ***ServiceImpl implements ***Service{

              DAOInterface dao;

              …

         }

     Service-->DAO-->ORM Engine

     当然，可能具体实现上不一定非得要这么做，我举这个例子出来仅仅为说明问题。

3） 测试自动，快速的运行至关重要。避免手工进行验收测试。这里的测试是指功能测试。在测试如此重要的原则上，对于XP的认识程度 完全可以等价于 对测试的认识程度。抛开那些敏捷原则，计划，迭代等等而言，对整个项目影响最直观，意义最重大的就是测试的认识和具体的设计。设计测试，设计持续集成这是我们必须要在项目整体设计是考虑清楚的东西。

     很多经典的XP书籍都建议在Web层中作功能测试，并列举了很多成熟的工具：比如HttpUnit,Cactus等等。

4） 界面的测试：对于web层的界面测试，还是脱离不了用户的手工体验的，但是我觉得很多人还是混淆了这个用户体验式的界面测试和单个的功能测试之间的差别的。而且界面的测试没必要重复进行，一般让用户在每一个迭代的末期手工去体验界面，登记需要改进的条款，然后作出整改。在以后的迭代中，对已经体验过的界面，我们就可以不用在强迫测试人员去手工再重新走一遍页面操作。



5） 每一个迭代的完成必须以一个可运行的最终版本为基准。



6） 在整个项目环境中，迅速培养一种快速，广泛的交流氛围。能够快速响应变化的能力。

这个一定要支持一下。
我们也是用这本书做XP教材的。

用户故事卡我们用真正的白纸版，
确认后转入TARGETPROCESS.

我怎么觉得这本书的重点并不是XP如何实践

呵，没错，这本书的重点并不是XP的规则。
它不是给XP的管理者看的，而是给XP的程序员看的。

它深入讲解了OO的基本原则， 比《设计模式》更实用。
它让程序员理解如何“简单设计”，如何TDD，为什么UAT最重要。

就算是非XPER的程序员， 在理解了OO的基本理论后，也强烈建议读这本书，它虽然没有什么新的理论，却是最实用的OO教程。

我怀疑任何形式的引入工具，除非有明确的理由！
目前项目处于初始阶段，人不是很多，我们使用一个wiki来，进行交流，
感觉很方便，几乎可以满足能想到的需求，比如：编写用户故事，任务分配，知识交流等。

因为我们带领的是两个xp team, 每个team有10-15人。

人数多少不是理由阿。
Xplanner提供了什么你们必须用到，然而使用通过其他途径不能方便的得到呢？

纪录每个user story, task, 结对, 跟踪每个task的完成时间。 XPlaner并不是一个必不可少的工具，而且xplaner的使用效果也一般。

这个项目也是一个实验性的项目，多达10对（非有敏捷经验的开发人员，多是新手）以上的结对和并发任务。极大增加的沟通的成本完全抵消人力上的投入。

观察的结果是3-5对是一个比较好的合理人数。