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