项目组采用XP的实践开发已经有一个多月了，主要是采用了测试驱动开发，重构，结对编程，还要引入持续集成。经过这么长时间的实践，我觉得组建敏捷团队，开始敏捷开发的关键问题是要统一价值观。

　　测试驱动开发

　　我发现实际上掌握这些实践其实并不是困难的，比如测试驱动开发，虽然我也是个初学者，但是我知道，只要经历一个学习和实践的过程，我们能掌握这项技术。我们使用JUnit测试，开始将整个Spring框架和Hibernate一起都测试了，后来发现这样做是不对的，单元测试应该不依赖于框架。于是我们改了。这个很容易改。

　　可是我发现比较难改的是大家编写测试的习惯。虽然使用着JUnit，但是他们依然会在产品代码编写完之后写测试，而非在其之前；他们依然是写了大量产品代码之后写测试，而非写一点测试，写一点产品代码。起初我觉得是因为大家不明白测试驱动开发的好处，因为先写测试　　有以下几个好处：

　　1、单元测试是需求说明书

　　2、单元测试是用户手册

　　3、帮助设计

　　4、有助解耦

　　5、观测性能

　　6、界定特性是否完成

　　7、系统集成出现问题便于排错

　　8、是重构的保护伞

　　9、在大多数情况下不需要调试，只需要测试，节省时间

　　10、提高产品质量

　　应该还可以举出很多好处，这些在很多著作，讨论中都已经重复千万遍了，不必细说，重点是，我发现即便人们都明白所有这些，但是依然会回到过去的方式。我觉得其根本问题在于对于敏捷背后的两个价值观他们是不认同的：重视质量和小步前进。他们并不认为质量对于系统的开发会有怎样的作用，认为质量是无关紧要的。质量的重要性其实已经不需要说了，Fowler等人的论述已经够多了，可是他们依然还是坚持自己的观点，这类人有以下几个表征：

　　1、认为测试驱动开发会增加成本。因为他们觉得测试驱动开发时编写的测试是多余的，如果不采用测试先行，这些测试是可以不编写的。这实际上是对质量的不重视。

　　2、认为测试脚本和测试数据是难以编写的。因为他们觉得使用完整的一套测试数据来进行测试是不可行的，而在我看来这是必须的，用户必须提供平时他们使用的典型数据来进行测试，以保证质量。

　　3、认为有了集成测试和用户测试，不需要单元测试，这样做是非常冗余的。

　　诚然，QA等级和软件成本是挂钩的，但是单元测试保证的质量应该是必须的。

　　如果上述观念无法达成共识的话，TDD中所说的，当遭遇失败时，首先写一个测试，对于他们而言更是天方夜谭了。<o:p></o:p>

　　重构

　　虽然我们使用Eclipse内置的重构工具完成一些典型重构，比如抽取接口，rename，move，提取方法等，但是为什么要进行重构的价值观却很难建立。具体现象是：

　　1、在代码很混乱的情况下继续添加新的代码，而不是考虑先将代码重构

　　2、认为重构会降低开发效率

　　我觉得其背后隐藏的依然是对于敏捷价值观的不认同：重视质量和简单。

　　他们通常觉得只要能运行不要去破坏它，质量问题是后要考虑的问题（有一部分人还会将重构和性能调优画上等号）。

　　重构可以获得一个简单的设计，而简单设计意味着没有重复，有充分理由的依赖关系和继承体系。可是我发现，没有重复这样一件事情，很难达成共识，有的人认为重复代码是代码重用的一种方式。

　　结对编程

　　结对编程的有效进行也对于提高质量和使设计简单有同样的好处，这个不必细说。

　　问题还在于大家是否对于这两个价值观认同。