欢迎发表不同意见。

误区：敏捷开发 == 极限编程/Scrum/…

敏捷开发是一种方法论，只是一些基本原则的集合，并非具体流程。

极限编程、Scrum等流程是具体的实施方法，它们都声称符合敏捷开发的思想，但执行起来是否真的“敏捷”，还得看参与者究竟思想上是否真的接受敏捷开发的原理。

如果把结对编程、daily scrum当做是敏捷开发的表现，那更是本末倒置，可悲的是，不少人还真是这么认为的。

误区：敏捷开发 == 简化流程

敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷。敏捷开发最重视的是拥抱变化，至于怎么拥抱，只能随机应变。实际应用中，既有流程相当简单的经典Scrum过程，也有极为冗繁、不亚于CMMI的RUP，根据应用场景不一样，项目组应该使用最适合的流程。

选择敏捷开发流程时也应带着敏捷开发的思维去选择，即快速响应项目实际的流程需求、拥抱流程应用过程中遇到的各种变化。没有银弹，也没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。

误区：敏捷开发 == 快速开始编码

敏捷开发强调迭代，鼓励开发人员用代码说话，不过绝对不鼓励没想明白就写代码。

符合敏捷开发思想的流程往往主张在一个稳定的基础之上迭代完成各种功能。如果基础都不牢固，迭代就无法进行，整个开发过程就退化成不断重写的过程，浪费开发时间。敏捷开发实际非常重视“设计”，并且对开发人员的设计水平提出了极高的要求，既要“持续重构”又不能“过度设计”，稍有不慎就会陷入反复推翻已有代码的窘境。对于内功不够的开发人员最好还是想好再写代码，设计的时候慢一点没关系，尽量少的做无用功才是最重要。

误区：传统开发能随时转变成敏捷开发

敏捷开发过于诱人，很容易让深受传统软件开发思想折磨的开发人员感觉敏捷开发就是灵丹妙药。

要想转变，首先需要从思想上正确认识敏捷开发的含义，了解它能解决什么问题、会带来什么新的问题、对现有软件/硬件资源有什么要求等。

例如在原先采用CMM的团队中，想利用敏捷开发简化冗余的文档、降低沟通成本，那么敏捷开发确实能在一定程度上缓解这些问题，但也会造成内部文档缺失、沟通不够深入的问题，在应用敏捷开发之前需要先确定适合团队的新的文档流程（代码注释能够自动/半自动的变成团队需要的文档么？），并且确定沟通的一些原则（比如，对于一些重要的沟通，是否还是用邮件来进行，不要过于“敏捷”？）。

有趣的是，有可能在回答这几个问题之后会发现，敏捷开发并不能解决项目中遇到的问题，反倒是其他方面出了问题。

举例来说。如果之前开发方法是简单的目标管理，遇到的问题是项目进度不可控、开发+测试的周期较长、不能及时响应需求变化，那么敏捷开发能解决的是快速响应需求变化，对项目进度和开发测试周期帮助不大（没有一种流程能够承诺改善项目的开发效率！），但前提是开发人员必须懂得怎样正确的去迭代开发，并且必须认识到一次迭代的结束是以完成测试为标准的。

在这个例子中可以看到，敏捷开发能带来的好处非常有局限性，如果开发人员达不到一定的层次是很难受益的。与其号召使用敏捷开发，不如想想如何增加执行力，以及找到周期偏长的根本原因（是因为设计不充分而返工？还是因为没有可以快速回归的测试用例？等等）。