当下敏捷开发和敏捷测试，是灵丹妙药还是又一个忽悠？

敏捷开发和敏捷测试这两年自从从国外引进后，在国内很火，很多人都在谈论。无论是项目延期，失败，质量低下等等，你总能听到分析的原因是：“看看， 你没有敏捷了吧”。所以一下子敏捷成了包治百病的灵丹妙药。很多项目组公司开始学习敏捷，采用敏捷，转向敏捷。但是遗憾的是很多人尝试过后发现以前的问题 并没有被敏捷所解决掉，反而带来了很多新的问题，于是也有人就得出结论：敏捷又是一个大忽悠。读了很多网上关于敏捷的辩论，我想起一个故事：

话说清朝的时候慈禧太后听说西方国家有个新的交通工具，汽车，它坐在舒服跑的很快。于是就叫人买了一辆回来。但是用的时候没有人会开，于是不得不把 汽车用几根柱子绑起来做成了轿子，让几个人抬着。因为汽车太沉，几个轿夫步履蹒跚，走不了几步就得歇歇。结果以前半个时辰的路走了好几个时辰。而且到了后 因为门很窄，汽车做的轿子过不去，她也不得不老远就下来自己走一段。慈禧太后很不高兴就得出结论：

1. 汽车前期投入大，维护成本高。
2. 没有轿子走的快。
3. 很多地方汽车都不适用。
4. 汽车是个大忽悠的东西，根本不管用。

那么我们现在对敏捷的认识是不是和慈禧对汽车的认识类似呢？是因为我们不会用敏捷呢，还是因为敏捷就是个忽悠？

在国外通常一个概念出来之前已经有很多年的实践积累，然后为了大家交流方便或者提高普及度给其一个名字。所以是先有实践，再有概念。但是在国内正好 相反，我们先把国外“先进“的概念引进来了而把产生概念的多年实践忽略掉了。但是概念又太虚不能当饭吃，最终还是需要具体东西和具体做法。所以不得不根据 概念来设计出各种各样的做法来。这些做法听起来不错，非常符合概念，但是在项目中一使用就不灵了，旧的问题没有解决，新的问题一大堆。最终得出汽车是个大 忽悠的结论。

敏捷和云计算是两个非常典型的例子。很多人为了敏捷，文档不要了，计划不要了，测试用例也不要了，认为几个人站在走廊里沟通沟通就把一切都搞定了， 因为敏捷了嘛。但是问题并没有因为“敏捷“了而被解决掉，于是乎得出敏捷是个忽悠的结论。云计算也一样，很多人认为云计算就是数据中心，所以大家大兴土木 建立数据中心。但是建完数据中心以后呢？没啥用处呀。那大家都在吹捧云计算，不就是个大忽悠吗。 殊不知，人家是因为业务需要很多年了已有数据中心，为了提高数据中心的使用率，开始对公众开放资源，所以才有了云计算。

先有概念再造实践的做法违背了事物发展规律，不仅解决不了现有问题，而且带来新的问题。敏捷是个好东西，在特定情况下。我们需要搞明白的是它要解决 什么问题的？它是如何解决的。而不要在乎它叫什么名字或则防止生搬硬套。还有越是先进的东西对人和基础设施的要求越高。比如飞机再好，没有飞行员或则没有 机场也没有用。高铁跑的越快对铁道的要求越高。

软件测试也是一样，做质量控制不是为了赶时髦。如果你的项目只做3个月就彻底结束了，而且就3－5个人，不会有人离开也不会有人进来，也不需要和其它任何项目打交道，或则你的产品在早期实验阶段，你可以不要文档，不要计划，不要记录bug，完全靠口头交流。否则的话：

• 不能没有文档：但是要减少不必要的文档，避免过于详细的文档，使用易于更新和维护的动态文档。
• 不能没有计划：距离现在越远计划越模糊，但是距离现在越近计划越详细。
• 不能没有纪律

与其在琢磨如何敏捷测试，不如一步一步把自动化做好，把持续集成做起来，创建更多的测试工具以提高测试效率，把质量反馈系统做起来，把dev提交代码前的质量检查做起来，把在产品中测试做起来， 把测试工程师的素质提高上去。

等到这些都建立起来了后，你发现自己其实已经很敏捷了。