零雨其蒙

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

测试驱动开发

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

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

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

    2、单元测试是用户手册

   3、帮助设计

   4、有助解耦

   5、观测性能

  6、界定特性是否完成

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

 8、是重构的保护伞

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

10、提高产品质量

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

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

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

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

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

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

 重构

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

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

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

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

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

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

结对编程

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

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

以人为本

在Fowler的《新方法论》中，Fowler认为敏捷最重要的两个特性之一就是以人为本，而非以过程为本。如果听到下列言论，我觉得意味着你的组织文化可能不是以人为本的：

1、随便找几个人进行简单的培训（这些人只使用过VB开发过课堂作业程序），就可以很好的编程了

2、制定一个执行步骤规范，人手一本，只要按照上面一步步操作就可以了

3、谁离开了，马上找一个人来就可以来替换他的工作。

我觉得这已经表明老板认为程序员只不过是生产线上可替换的零件了。

我觉得不以人为本的团队，也体现了对于如下几个价值观的不认同：

1、信任。程序员不值得信任，并不是像Fowler所说的程序员是担负责任的专家。

2、沟通和反馈。虽然通常他们会强调沟通的重要性，但是他们很少强调反馈的重要性。他们所谓的沟通是单向的下命令，而非交互式的。

3、尊重。团队中其他人的工作是不值得尊重的，架构师可以有一万个理由瞧不起编写代码的程序员，在这样的团队中，架构师通常都是不参与编程的。

迭代，小步前进

我非常喜欢Kent那个开车的比喻，可是领导认为每天总结（站立式会议）或者每隔一段时间进行总结都是没有必要的。

设立短小的、可控的计划是无用的。

还有一个最根本的

我觉得敏捷开发最根本的一个观念就是实事求是，也就是Kent在《解析极限编程》中所说的，XP就是将有益的事情做到极致。所以敏捷方法都是一堆实践原则的集合。

Johnson讲的循证框架也是在强调这点。我们可以笼统的说自己在实践敏捷开发，或许不是那么纯粹的XP，Kent的说法也是建议循序渐进的使用XP，但是觉得有用，可以解决你遇到的问题，又不会有很大的副作用，那么就把它引进来，即使这个方法是CMMI阵营的。

    我认为每件事都要经过科学的论证，而不是猜测，可是这一点也得不到认同。

敏捷叫停

我们的团队请了一个日企的强调使用V模型，严格文档驱动的顾问，意味着我们的敏捷之旅结束了。

我想我们之所以没有沿着敏捷的道路走下去，并不是因为实践的问题，也不是因为原则的问题，而是价值观的问题，总结如下：

1、我们的老板觉得程序员就是可替换的零件

2、质量不重要

3、开会就是下达命令

4、简单就是把所有的代码都写到一个文件里

5、对于大家不信任

6、个性不应该被尊重，服从命令是第一位的，海军陆战队风格

7、实事求是

Kent说，如果你的团队的价值观是与XP抵触，那么就不要使用XP。

我觉得透过种种敏捷实践的实施不力，其背后隐藏的其实是价值观的难以统一，至少我觉得我在项目中推行敏捷，挣扎了一个半月终于要搁浅，原因就在于实在难以在价值观上达成共识，最困难的是难以说服老板改变观念。

Ps：我是研究生一年级的学生，我们的项目很大，可是人不多，我觉得非常适合使用XP。我认为XP是非常好的天才的想法，可以解决很多问题，可是今天来给我们做指导的那个日企的人说在大公司做大项目都是要听话的，不会用敏捷之类的新方法。可是我看到的那些软件开发大师的书，和论坛上各位的讨论，都觉得这个方法应该是经过很多大型项目的验证了，可是我们导师询问了几个公司里的人，却都没有用过，他们也觉得TDD很好，但是就是没用过。

  我是作为我们团队的技术主管，其实就是矬子里面拔大个，但是这是我接触敏捷1年来，并且在这个项目前期时使用敏捷的想法，或许我的所有观点都很幼稚，所以还请各位有工作经验的多多指点~