敏捷开发和敏捷测试这两年自从从国外引进后，在国内很火，很多人都在谈论。无论是项目延期，失败，质量低下等等，你总能听到分析的原因是：“看看，你没有敏捷了吧”。所以一下子敏捷成了包治百病的灵丹妙药。很多项目组公司开始学习敏捷，采用敏捷，转向敏捷。但是遗憾的是很多人尝试过后发现以前的问题并没有被敏捷所解决掉，反而带来了很多新的问题，于是也有人就得出结论：敏捷又是一个大忽悠。读了很多网上关于敏捷的辩论，我想起一个故事：
话说清朝的时候慈禧太后听说西方国家有个新的交通工具，汽车，它坐在舒服跑的很快。于是就叫人买了一辆回来。但是用的时候没有人会开，于是不得不把汽车用几根柱子绑起来做成了轿子，让几个人抬着。因为汽车太沉，几个轿夫步履蹒跚，走不了几步就得歇歇。结果以前半个时辰的路走了好几个时辰。而且到了后因为门很窄，汽车做的轿子过不去，她也不得不老远就下来自己走一段。慈禧太后很不高兴就得出结论：
- 汽车前期投入大，维护成本高。
- 没有轿子走的快。
- 很多地方汽车都不适用。
- 汽车是个大忽悠的东西，根本不管用。
那么我们现在对敏捷的认识是不是和慈禧对汽车的认识类似呢？是因为我们不会用敏捷呢，还是因为敏捷就是个忽悠？
在国外通常一个概念出来之前已经有很多年的实践积累，然后为了大家交流方便或者提高普及度给其一个名字。所以是先有实践，再有概念。但是在国内正好相反，我们先把国外“先进“的概念引进来了而把产生概念的多年实践忽略掉了。但是概念又太虚不能当饭吃，最终还是需要具体东西和具体做法。所以不得不根据概念来设计出各种各样的做法来。这些做法听起来不错，非常符合概念，但是在项目中一使用就不灵了，旧的问题没有解决，新的问题一大堆。最终得出汽车是个大忽悠的结论。
敏捷和云计算是两个非常典型的例子。很多人为了敏捷，文档不要了，计划不要了，测试用例也不要了，认为几个人站在走廊里沟通沟通就把一切都搞定了，因为敏捷了嘛。但是问题并没有因为“敏捷“了而被解决掉，于是乎得出敏捷是个忽悠的结论。云计算也一样，很多人认为云计算就是数据中心，所以大家大兴土木建立数据中心。但是建完数据中心以后呢？没啥用处呀。那大家都在吹捧云计算，不就是个大忽悠吗。殊不知，人家是因为业务需要很多年了已有数据中心，为了提高数据中心的使用率，开始对公众开放资源，所以才有了云计算。
先有概念再造实践的做法违背了事物发展规律，不仅解决不了现有问题，而且带来新的问题。敏捷是个好东西，在特定情况下。我们需要搞明白的是它要解决什么问题的？它是如何解决的。而不要在乎它叫什么名字或则防止生搬硬套。还有越是先进的东西对人和基础设施的要求越高。比如飞机再好，没有飞行员或则没有机场也没有用。高铁跑的越快对铁道的要求越高。
软件测试也是一样，做质量控制不是为了赶时髦。如果你的项目只做3个月就彻底结束了，而且就3－5个人，不会有人离开也不会有人进来，也不需要和其它任何项目打交道，或则你的产品在早期实验阶段，你可以不要文档，不要计划，不要记录bug，完全靠口头交流。否则的话：
- 不能没有文档：但是要减少不必要的文档，避免过于详细的文档，使用易于更新和维护的动态文档。
- 不能没有计划：距离现在越远计划越模糊，但是距离现在越近计划越详细。
- 不能没有纪律
与其在琢磨如何敏捷测试，不如一步一步把自动化做好，把持续集成做起来，创建更多的测试工具以提高测试效率，把质量反馈系统做起来，把dev提交代码前的质量检查做起来，把在产品中测试做起来， 把测试工程师的素质提高上去。
等到这些都建立起来了后，你发现自己其实已经很敏捷了。