现在说到互联网软件产品的研发过程等，基本都少不了聊到敏捷开发，就和说到企业人员管理离不开扁平化一样，敏捷开发也成为了开发项目中的一个“流行”。但是实际工作中，我们是否适合或是应该使用某种方法，如果一味跟风，往往会出现不少弊端。
最直接的就是没有正确认识，而对采用的方式认知不对，亦或在操作过程中出现不少失误。
错误理解
1、并非所有需求阶段都适用于敏捷开发
使用敏捷开发最广泛的行业就是互联网，这主要有两个原因：一是产品的功能升级更新换代非常快，大家都必须要在最短的时间内抢占市场，吸引用户，而需求往往又不是非常的明确，甚至有时只是一个idea，需要市场的反馈;二是产品的升级一般是可控的，即便是带着一定缺陷的产品发布(又称为“灰度发布”)，我们都可以在后台悄悄的升级系统或修改BUG，对于用户来说，任何时间打开浏览器都可以看到最新的产品，因此对用户的影响是最小的，甚至用户是不感知的。
但是，即使是同行业，对于那些需要安装到用户使用的终端(电脑、手机、平板等)的应用来说，这样的升级方式可能就会导致客户的反感、投诉和客户流失。对于软件提供商来说，还必须要考虑客户拒绝升级情况下，后台系统必须要同时支持多个版本的运行，否则就会遭到客户的投诉，甚至会引发负面影响的广泛传播。
因此对于不同形式、不同需求阶段、不同质量要求的产品，对于敏捷开发的实际应用是需要谨慎研究的，而不是绝对的生搬硬套和教条主义。
2、敏捷并不是“一个”过程
我们知道项目管理是一个过程，因此不少人会同样的认为敏捷是一个过程，但是事实并非如此，敏捷不是一个过程，是一类过程的统称，它们需要符合敏捷价值观、遵循敏捷的原则。
那么符合敏捷开发的原则有哪些要求呢?
首先，我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意;即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
然后，在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。而在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
其次，每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
易犯失误
1、绝对自由的错觉
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是我们应该清楚，凡事都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。
敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了。
2、流程简化，确实分析于设计
敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷。敏捷开发最重视的是灵活应对变化。选择敏捷开发流程时应带着敏捷开发的思维去选择，即快速响应项目实际的流程需求，适应流程应用过程中遇到的各种变化。没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。
虽然敏捷开发强调简单设计，团队每个成员都从接触客户到分析设计，到编码，全部承担。但是实际上团队成员的素质参差不齐，如果只有简单设计、立即编码，而没有后续的持续重构等实践，将导致设计混乱不一致，尤其是对老系统的功能升级，如果对原有系统的影响分析不够，弱化了分析设计，将导致很多工作在后期频繁变更，使得团队的挫折感增强，产生较多的重复工作和浪费。因此，必要的系统架构和设计从来都是非常重要的。
所以任何时候，我们都不能纯粹依靠经验和教条主义，每个项目甚至具体工作任务都是不同的，所以只有根据实际情况灵活应对处理才是正确选择研发模式的有效之法。