为什么敏捷没有成功： 关于敏捷的一点思考 (1)
敏捷在中国也火了几年，这一段感觉有些沉寂了，通常来说一种技术或者方法从铺天盖地的宣传变得悄无声息，一般有两种原因：
一是这个东西经过宣传和大家使用，觉得真是好，慢慢的沉淀成了大家必备的一种技能，例如设计模式，很难想象不懂设计模式在J2EE开发中怎么混。
另外一种情况就是经过宣传和普及，发现这种方法没那么好，或者说很难采用，慢慢的大家失去了兴趣
根据我个人的观察和经验，觉得敏捷开发在国内的现状很可能属于后者，而不是前者
我写这篇文章也是我自己针对敏捷的一些反思和以及困惑， 涉及到持续集成，测试驱动开发，结对编程，迭代开发，特性团队等，先从一些敏捷的技术类实践说起吧
1. 持续集成
Martin Flower的文章已经对持续集成做了详尽的阐述，这里不再重复
我相信持续集成绝对是敏捷开发的一个基石，通过不断的编译，打包，部署，测试，随时保证软件处于“安全”状态。
它的好处也是立竿见影的，自动化很多步骤，减少手工的重复劳动，降低出错的概率。
说实在的很多团队都很认可并重视它，很快就能用各种各样的工具把持续集成基本建立起来
注意，我说的是“基本”建立起来，因为很多的持续集成其实只是自动化的Build, 其中缺少了很重要的一个元素：自动化测试！
自动化测试是持续集成最有价值的部分，缺少了它，我们无法迅速的得知最新的代码变动是否安全，整个软件是否处于健康状态。
当团队试图往持续集成中添加测试时，经常会遇到这些问题：
(1)团队没有时间编写，进度压力大，代码都写不完还写测试？
(2)测试运行速度太慢，加入到持续集成会拖累Build 的速度
(3)测试容易失败，很难定位原因 ,运行不稳定的东西干脆拿掉
这些问题当然可以解决，但是都需要花费时间，在进度的压力下，最好的办法就是放弃自动化测试，把测试工作交个测试组去做，发现了Bug再花费更多的时间来修复，导致时间更加紧张 --- 一步步陷入泥潭
2. 单元测试
Scott Ambler 认为衡量一个团队是否做敏捷很简单： Show me the test， 可见测试的地位是多么重要
我们这里只聊一下UT(单元测试)，大牛说“编译器能检查语法错误， UT能检查语义错误，有了完善的测试套件，以后代码变化对软件的任何破坏都能迅速捕获到“
”好东西啊，我的团队也要写单元测试！“ 于是大家满怀激情的投入到单元测试中去。
对新代码还比较简单，不就是一些Setup,TearDown 和测试用例吗？
可一旦涉及到遗留代码，立刻就头大了，这些代码在编写时根本就没有考虑可测试性，结构不好， 充斥着代码的坏味道
为了写单元测试，不得不进行”重构“，对代码的依赖进行解耦，很多情况下，程序员对这种”重构“没有信心，不知道会不会把程序逻辑改坏
更让人沮丧的是，需要Mock很多很多的对象只是为了测试那么一点点代码，挫败感很强
但无论如何也得写下去，因为领导说了， 我们要达到80%以上的代码覆盖率！真是一把悬在头顶的利剑啊
终于我们费劲九牛二虎之力把测试写出来了，我们终于有一个保护网了！
每次改动一段代码，运行一下这个测试套件，看着一片绿色，感觉很爽啊
慢慢的绿色中出现了不和谐的红色，测试用例发现了错误！
为了改正错误，我们发现所用的时间越来越长，因为我们需要读懂测试用例，分析这个测试为什么失败，是代码的问题还是测试本身有问题。
更要命的是改动一点点似乎不那么相关的代码，都会导致大面积的失败，一片红色让人头大
程序员还要时刻小心，保持代码和测试的一致性，代码中某个接口有改动，一定要确保所有的测试用例也随之改动，这也花费很多精力
脆弱的测试用例带来了巨大的维护开销！
在进度的压力下，程序员对UT的激情慢慢消失，耐心会慢慢耗尽，花很大精力编写的测试套件会慢慢的落后于代码的变化，逐渐变成一块无人问津的、废弃的荒漠。
没有人会再去理会那触目惊心的红色，甚至没人会运行它们，它们完全被抛弃了
