跟人介绍敏捷的时候，很多人都会对敏捷有怀疑。一个必问的问题是敏捷的限制是什么？或者什么样的项目适合敏捷开发？
做敏捷的人一般都会回答，任何项目都适合敏捷开发，因为敏捷只是一组原则和价值观的组合，更是一种精神而不是流程。无论如何，精神总是适用的。说得稍微具体一点，敏捷或者Scrum基于不断的迭代获得反馈（产品的反馈和流程的反馈），然后从反馈中不断吸取教训获得提高。这种理念无论如何，也是对任何产品和项目适用的。
但从另外一个角度说，要获得敏捷带来的高效，需要付出的代价是不同的。如果是小型产品，或是基于Web的，或是Java这样面向对象的高级语言，使用敏捷会比较容易。因为，要构建working software本身就比较容易。已经有很多现成的工具支持自动化构建，自动化测试等等。那获得快速反馈的成本就相对较低。相反，如果大型产品，技术比较老，语言也比较老，那使用敏捷就需要先花出一些代价。要在每个迭代交付working software需要很多设备和工具的支持。而在这些产品的开发环境中引入这些设备和工具，并非易事，需要花很大的人力和物力来实现。
打个比方，一个人本身跑得比较快，那要让他跑得更快的方法只是去除他身上的一些负重。就像是本身很敏捷的产品，去掉一些传统流程的限制那就好。但是如果一个人本身跑得不快，那去除负重并不一定能达到效果，而是要提高他本身的能力，那就需要投入成本帮助他的提升。就像一些传统大型产品，本身遗留代码等问题就比较多，开发这些产品本身的速度就很慢，还没有自动化测试的保障。那首先要做的是开始构建自动化测试环境，慢慢减少遗留代码，使他本身有敏捷的基础才行。
而值不值得投入这些成本达到快速开发交付？那就要看公司自己的衡量了。产品本身的底子如何，要花多大力气才能让他本身敏捷起来，能获得多大的利益，产品的life cycle如何，等等等等都是需要考虑的因素。这可能是很多人怀疑敏捷是否适用的原因吧。
