敏捷方法开始在软件企业中流行了，应用后大家褒贬不一。结合我在多家企业的观察，提出如下意见。

1.敏捷方法产生的主要初衷是为了应对需求的不确定性，希望通过这种方法来减少出现的大量变更而带来的“干冤枉活”的情况。所以，如果软件的需求是比较可预见的，是可以通过前期更多的深入讨论、分析、借助现有系统和可视化工具进行需求的定义的，则使用敏捷方法必要性不强。如果使用不当（如轻视了对需求的深入分析而采用“先做再说”的做法）反而得不偿失。如某互联网企业在开发团队中推广了敏捷方法，使用了该模式的负责人有的高兴、有的抱怨。抱怨的人说文档量是减少了、代码前的工作量是减少了，但代码的工作量大大增加了，后期扯不清的矛盾增加了，在时间有限的情况下很难说所谓“敏捷”真的能快捷得起来。

很多项目的不确定性是来自于外部意见的不确定性，如来自于强势客户的意见、来自于市场趋势的变化莫测等。如果需求主要是来自于内部，那前期深入的分析讨论、使用可视化手段辅助需求定义等，均有助于减少需求在开发过程中才发生重大变更。

2.敏捷方法强调用更频繁、充分的沟通来提高效率、减少反复，如果使用了敏捷方法而又没有加强沟通，则结果很可能是敏捷本应带来的益处没得到，反而增加了反复、降低的效率。

3.敏捷同样要求要按计划执行，反对无计划地“走到哪算哪儿”，只不过在它的观点中没必要对一个大型项目在开始阶段就编制一个完整的包括所有阶段的、尽善尽美的计划，而是在项目推进过程中不断细化下阶段的计划。按PMI的观点，这就是所谓“滚动计划法”，PMBOK中也列举了一些各种不同项目生命周期模型的例子。项目管理的方法与敏捷方法并没有矛盾，敏捷方法是项目管理方法的一种具体做法。

实施敏捷不能成为不写文档、不作分析、不作计划、不深入分析需求的理由。如果这样，则项目未来的未知性就会过大，资源使用会粗放而无保障，管理的不确性会增大。为了适应需求的不确定性而不适当地增大了管理的不确定性，其结果可能就是省下了写文档、讨论需求、编制计划的时间，却导致了开发工作的反复过多，反而大大增加了项目开发周期。

包括项目管理方法在内的管理方法是人类在自然界生存的过程总结出来的做事规律，违反自然规律当然是会受到惩罚的。