在网上查了许多资料，也看了国内许多人对敏捷开发的看法，大致写一下自己的理解。

传统软件工程是在OS/360的失败后逐渐发展形成的。最开始的软件开发更像是艺术创作，十分依赖程序员个人的技术，软件的质量也基本靠程序员的责任心保证。但随着软件规模越来越大，越来越复杂，开发周期与成本也越来越不受控制，同时软件的可靠性也很难保证。

为了解决这些问题，软件开发行业开始学习工程中的管理方法，为软件开发制定了一套规范，管理软件生存周期的各个阶段。比如广泛使用的瀑布模型，核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，规定了相互的衔接次序，如同瀑布流水，逐级下落。传统的软件工程可以保证软件开发过程的可靠与可控，并且能够依靠文档有效的整合很多人的工作，像操作系统，搜索引擎这些有很多人参与的项目，都是在软件工程的帮助下顺利开发的。

然而，传统的瀑布模型也有她的弊端。多数情况下客户并不知道自己真正想要什么，只是有大致的想法。而且现在的软件行业，发展太快，不管先前的需求分析做的多么细，交到客户手中，总会有各种各样的问题，很可能最后得到的产品和客户的期望相差甚远，而这时候修改已经十分困难。

所以就有了迭代开发这样的方法。在迭代式开发方法中，整个开发工作被组织为一系列的小项目，被称为一系列的迭代。每一次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。这样可以更早的得到用户反馈，修改开发中的偏差，降低风险。

敏捷像是进行了改进的迭代开发方法。同以前的软件管理方法相比，更加注重人这个因素在软件开发中的作用。敏捷开发强调面对面的沟通，不管是开发团队还是客户。通过频繁交付新的软件版本，以及自组织的团队，来适应需求的变化并完成项目。

人和交互 重于过程和工具。

可以工作的软件 重于求全而完备的文档。

客户协作重于 合同谈判。

随时应对变化 重于循规蹈矩。

敏捷开发相对于传统软件工程，降低了文档的作用，而加强了人在开发过程中的地位。强调团队的高度协作，优先完成重要的任务，充分发挥人的主观能动性。从而相对于传统的软件工程，敏捷开发对变化有着更好的适应性，更适合于创新型软件的开发。但相对的更加依赖于人，团队如果出了问题，相应的开发进度也会受到影响。

实际的工作中，每种开发方法都有其适用的地方。当竞争特别激烈的时候，往往需求变化也很迅速，敏捷开发可以快速适应环境抢占市场。但敏捷开发也会遗留一些问题，比如团队的人员变动，以及凝聚力都会影响软件的后续生存，传统软件工程更擅长于软件的长期管理，以及质量的控制。传统软件开发方法与敏捷开发各有侧重，所以，更好的办法是根据具体的情况在多种开发方式中进行选择。

（机器和人的区别大概也是这种情况，机器一丝不苟定下计划就几乎不会出错，但是对于预料之外的情况几乎无法做出反应，而人脑灵活而富有创造力，但常常会犯错，也有偷懒的时候。也许这中间可以找到一个平衡灵活性与正确性的点，软件工程今后的探索道路，应该也是在灵活性与稳定性之间找到平衡）

参考：

百度百科《瀑布模型》

百度百科《迭代式开发》

百度百科《敏捷软件开发》

以及知乎上关于敏捷开发的讨论

来源：博客园