前言
敏捷思想创建于上世纪后期，在本世纪得到很大的发展。关于敏捷的知识和优点大家可以到互联网上去搜索，介绍的内容很多。本文论述敏捷不是银弹，并不是说敏捷不好，而是比较客观地介绍敏捷不是适用于任何的产品。
正文
我们通过产品类型来分析敏捷不是银弹的原因。
1，嵌入式产品。从广义上来说，并不是所有的嵌入式软件都不适用于敏捷，最通常的比如智能手机，也可以看作是嵌入式软件，它是非常适合于敏捷开发的。而大部分嵌入式产品对于软件的固化是有限制的，所以这类产品是不适合用敏捷开发的。敏捷思想的精华在小步快跑，不断地进行迭代，这对于互联网产品起初需求不是很明确，为了得到很真实的需求，采取敏捷的方式，让客户（用户）尽早接触的产品的原型，敏捷的确是一种很好的思想。但是作为嵌入式软件，功能往往比较单一而且比较（相当）明确，又由于受到固化次数的限制，所以是不适于用敏捷的。另外硬件的成本是非常大的，一旦软件出现了问题，其损失是非常强大的。笔者亲自咨询过一家国内的智能电表生产企业，有一次由于嵌入式软件没有开发好，造成了成百上千件智能电表被召回，其损失巨大。另外据说新本田CR-V召回事件，其根本原因也在于软件设计上的缺陷。
2，维护中的产品。大家知道，软件开发包括需求、设计、实现、验证和维护阶段。而好些软件是处于软件维护阶段的，为什么我们说维护中的产品不适用于敏捷测试呢？
1） 在维护阶段，用户参与已经失去了作用。在敏捷宣言中有一条：“客户合作高于合同谈判”，在Scrum框架中专门有一个职位叫做PO（Product Owner），这个PO角色理论上应该是由客户参与的，但是在实际生产工作中，由开发团队内，类似于以前的产品经理或者需求分析师来承担。而处于维护阶段的产品客户往往不太愿意参与了。
2） 维护周期很长，必须要有一整套的系统文档。一般一个产品的维护周期为数年甚至数十几年，在这么长的时间内，必须建立起一套完备的文档体系。虽然敏捷宣称代码是最好的文档，但是代码的易懂性一般在程序员中也是很难达到的，况且产品的总体架构也不是通过代码可以了解的。
3） 敏捷是需要有一个相对稳定的团队的。正如上面所述，维护阶段通常持续很长的时间，在那么长的时间内保持稳定的开发团队是不太可能的。
我曾经从事过一个产品的测试工作，由于这个产品是电信级别的，测试必须使用脚本语言来实现，且该产品持续有五年多了，大部分模块处于维护阶段。通过这五年的时间测试用例积累多达数十万条，也只有在周末的时候才可以把分布在五台机器上所有的测试用例都运行完毕。每次CI运行完毕，调试没有通过的case，结果往往几乎一半是有由于特性发生了变化或者修改了其他Bug造成的由于测试代码的引起的（而不是产品代码的问题），那一段时间，为了保证每次发布必须有98.5%以上的测试用例都PASS的Hard Stone，测试人员的大部分时间都在维护老的测试用例，且没有时间去开发新的测试用例。最可怕的是对于一些三四年前编写的没有通过的测试用例，当时编写的用例维护性很差，且书写这段代码的同事去了其它产品组或离职，无从追溯，只能将这些测试用例抛弃，没有人知道这些测试用例到底有没有用。
3，对于医疗产品，航空航天等这些生命攸关或高投入的产品也不适合敏捷的方法。对于生命攸关的医疗产品投入使用就直接与人的生命依依相联系了，而敏捷的思想是精益，精益和核心是通过尽可能少的试错来达到软件最后使用，而这些软件是不允许一次甚至半次试错的，产品一旦被使用就要做到100%的安全。而对于航空航天产品，特别是某些航天产品就只有一次的使用机会，这些产品是不能用敏捷的方法来开发的。
历史上许许多多的教训告诉我们，世界上不存在银弹，所有东西都有它的两面性，包括敏捷也不是万能的，我们必须权衡其优点和缺点，结合我们自身的产品，合理地去使用。
参考阅读：
【1】“对敏捷开发的一些思考”http://www.51testing.com/html/00/n-867400-2.html
【2】“软件工程”伊恩萨默维尔(Ian Sommerville) Tenth Edition
