看到这个题目的第一时间我们需要考虑几个问题：传统软件工程的工作模式是什么样的？敏捷软件开发的工作模式是什么样的？其次是它们的区别是什么？各自的优劣之处在哪里？现在的应用情况如何？
找到问题后，笔者便带着问题去寻找答案。
关于软件工程，广义上讲，包括构建管理、源代码管理、软件设计、软件测试、项目管理、用户体验和UI设计在内及其相关内容，他的主要开发方法是结构化的开发方法，具体的开发流程以瀑布模型最具有代表性，而在这一类中，又以RUP（Rational Unified Process）为集大成者，这里我们以RUP为对象进行介绍。RUP把软件开发的各个阶段整合在一个统一的框架里，以工作流（业务建模——需求——分析和设计——实现——测试——部署——配置和变更管理——项目管理——环境）作为纵轴，以开发流程（初始阶段——细化阶段——构造阶段——交付阶段）作为横轴，通过不同的阴影面积表示不同角色在各个阶段的参与度，最终绘制出一个驼峰图，其重要特点是重计划，重设计和重文档。而敏捷软件开发这一概念是自敏捷联盟宣言始的，面对许多软件公司陷入“焦油坑”的事实，一批业界专家共同概括出了一些可以让软件开发团队具有快速工作，响应变化能力的价值观和原则。
图 1
在这个价值观下，引出了12条基本原则，这些原则就是敏捷开发区别于传统软件开发的特征所在，具体内容略（可自行查询百度、维基等）。而敏捷开发的主要核心在于打破了膨胀循环，它关注那些能够使得团队目标完成的简单的事情。以Scrum为例，它的理论设计如下：
图 2
这看起来非常的简洁和高效，而它的操作流程也同样的简单，分为三步：先找到Product Backlog、然后决定Sprint Backlog，最后Sprint，整个过程三个阶段都具有很强的目的性和相对的独立性，其中在最后一个阶段，团队成员每天开会（Scrum Meeting），每一位成员报告三件事：昨天的工作，今天准备进行的工作，遇到的问题，确保遇到的问题能被团队的每一个成员所知悉，此外，在冲刺阶段中，外部人员不能与除了Scrum大师（Scrum Master）之外的任何内部人员产生交流，任何需求的变更只能在Sprint结束后讨论。
了解完了二者的基本思想，我们来聊聊他们的区别，粗略的概括一下，对于传统软件开发而言，核心是一个“稳”，在一开始就花大量的工作做设计、做需求分析、做模块构建等工作，确保能实现客户需求，然后开发阶段则成了按图索骥，逐步的实现之前规划阶段所给出的功能，直到最终向客户交付产品，这样一套流程下来，不止对于开发者要稳（按照计划不出纰漏的执行），对客户也有稳的要求，如果是一个不断变更需求的开发任务，那么这种模式几乎不能够做出好的产品，因为每次需求的变更都要对此前所做的工作做大量的修改，而这带来的成本的升高几乎是不可接受的，不管是时间成本还是资金成本，此外，传统的软件开发是没有迭代过程和反馈过程的，就像瀑布一样“一去不复返”，文档是联接不同阶段的唯一接口。相对而言，敏捷软件开发的核心可以简单概括为一个“变”，这一点在敏捷开发宣言中也有所体现，通过接受变化后的快速应对和短时间，高频率的迭代交付确保产品能打到客户的预期，此外敏捷软件开发还有一个核心的要素“team”，这一开发方法能明显的感觉到对team内部的交流的重视，同时还扩充了传统的“team”的构成，他们把客户也拉入了“team”的结构中，具体的例子可以参考《敏捷软件开发：原则、模式与实践》中的极限编程一节。当然，敏捷软件开发也不全是我们看起来的那么高效和美好，在某种情况下，它也会出现我们不愿意出现的现象，邹欣老师在《构建之法》中就举了一个很形象的例子，如果在Sprint的每日立会中出现如同狗熊一样的成员，那么几乎可以断定，这个项目会受到很大的影响。
在应用方面，这两者目前都广泛存在于软件开发行业中，当然随着社会节奏越来越快，敏捷开发也似乎更被人们所青睐，学习敏捷开发也似乎成了一种潮流，敏捷开发本身也在不断的出现新的模式，比如Scrum、比如极限编程、比如OpenUP、比如精益、比如特征驱动开发、比如水晶方法等。敏捷开发思想被更多的企业认同带来的是更多软件公司极力向敏捷开发转型的客观事实，虽然这中间出现了许多转型失败的例子，但是这一大趋势应该不会改变，同样的，发展的同时也出现了更多的问题，例如大规模敏捷的问题。
图 3 (图片转自[4])
参考文献
【1】 构建之法.邹欣
【2】 敏捷软件开发体系.宁德军，李春林，张忠等
【3】 敏捷软件开发：原则、模式与实践.Robert C.Martin
【4】 http://geek.csdn.net/news/detail/96977