在“计算机程序的蛮荒时代”，人们对于程序的设计、编写是随想随写、灵活变化的。正如我们初学各种编程语言时那样，似乎把程序写对也不是什么很难的事情。然而，这种程序设计模式或许适用于几百行至几千行的小程序，而当我们面对更大的软件规模、更多的代码行数以及更复杂的人员架构时，这种随想随写的程序开发模式似乎不再适用，于是使人们遇到了「软件危机」，进而促使了软件工程这样一门学科的产生。
在我上一门程序设计的课程的时候，老师讲过，当我们学习各种语言、算法和数据结构时，我们学习的是怎样进行“程序的设计”，而很多人会产生一个误区：程序=软件。然而并非如此，软件是程序的更上一层结构，即软件=程序+模板。暂且不考虑这个等式的右侧是否仅仅是「程序」和「文档」，我认为前半句话十分正确，即软件是比程序更广的概念。程序仅仅是软件的实现的一部分，虽然可以说是很重要的一部分，但不是全部，软件还包括了辅助编写、理解程序的文档等一些列辅助元素。而软件工程，正是为了从算法、数据结构和语言等以外的角度来探讨如何编写出正确、高效的软件；如何对这些程序进行高效的编写和组织。
随着软件工程的发展以及生产环境的多变，软件工程逐渐演化出各种各样的门派以及方法论。这些方法论不关乎对错，只是在不同的情况下有不同的适用情况，以及不同的开发团队对不同的方法论有着不同的喜好。而这些适用情况的不同和喜好的不同正是因为这些方法有着不同的特性。
大体上来说，当下软件工程可以分为两种明显区分开的流派，即传统软件工程方法和敏捷开发方法。其中传统软件工程开发方法产生较早，较为成熟；而敏捷开发方法比较年轻，但最近更加受到青睐。本文接下来就对两种软件开发方法进行对比，并试图解释敏捷开发方法——这一近期发展出来的热门方法论的产生的背后的因素。
1968年，北约在学术会议中创造了「软件危机」一词，并且首次提出了「软件工程」的概念，以应对「软件危机」。由于程序变得越来越复杂，可用的工具越来越多，需求越来越难以实现，以及参与编写软件的人员越来越多，计算机软件不再像是以前那样用砖瓦搭一个小房子那样简单——虽然这也是个技术活——而变成了搭建一座摩天大楼，这需要很精密的计划、规范标准以及坚实的技术支持。
瀑布模型的提出时间很早，更像是一个理想的软件工程模型。瀑布模型以一个线性的工作流来组织软件开发的过程，从沟通、策划、建模、构建直到部署[2]。瀑布模型指出要在进行构建之前进行完整的探讨、设计和分析，并形成大量的文档。每一步均在完整的前一步的基础上进行，并且形成大量的文档。瀑布模型过于理想，以至于其不能适应变化。由于后一个阶段完全在前一个阶段的基础上进行，如果前一个阶段无法顺利完成或需要返工，例如需求的不明确、改变等，会导致瀑布模型的整体性返工，造成大量需要修改的文档和浪费的文档，以及系统的遗留问题，最终使得整个系统的崩溃。事实上也几乎没有人使用瀑布模型，瀑布模型无法避免地需要进行返工[3]。
增量过程是瀑布模型的改进与进化。增量过程将软件开发过程定义为若干个增量（通常以不同的功能、组件来划分）。每个增量各自以线性开发过程来进行。增量过程模型的好处在于它能够不断地（至少是按部分地）产生可以使用的程序原型。
演化过程也是对瀑布模型的改进，也可以称为是迭代开发过程。瀑布模型不能适应需求的不确定和改变，而演化过程可以先出产一个原型，并根据开发情况和用户需求的确定、改变已经用户的反馈进行迭代式开发，并且每次迭代依旧按照线性模型来进行。演化过程模型可以较快地产生原型产品并进行试用。与增量过程模型不同的是，增量过程模型着眼于模块化的划分与迭代，而演化过程模型着眼于软件的「深度」上的迭代。演化过程模型也可以应对需求的变化，但为了实现原型产品可能会生成许多历史遗留问题，这往往会导致大量的时间和生产效率的消耗。
螺旋模型是一种特殊的迭代开发模型，但是它的地位十分重要。螺旋模型一般用大型的、重要的软件开发，并且从概念开发一直延伸到了软件的整个生命周期。在每一层螺旋中，螺旋模型使用瀑布模型，而每一圈代表软件的一个层次：最中间代表原型，外面代表软件的完整实现、改进、维护直至进化。
螺旋模型还有一个特点，就是它一定要在每一轮循环迭代中进行风险评估以消除风险、说服客户接受迭代式的产品演化，因此也被成为风险驱动型开发方法[4]。
上述传统软件开发方法，无论是瀑布模型这种线性模型，还是增量、演化和螺旋模型，都离不开先进行完整的评估、设计阶段，再进行实现、测试。而每一步的评估、设计都需要形成诸多的文档以及不可改变（至少在当阶段不可改变）的各种要求、约束。
敏捷软件开发从1990年代开始逐渐引起广泛关注。2001年，敏捷方法的推崇者在美国犹他州雪鸟滑雪圣地进行了一次聚会，形成了「敏捷联盟」并发表了《敏捷宣言》，在这个宣言中，最重要的部分即以下几条：
与之相对地，传统软件开发方法被称为是「非敏捷」的。与传统方法相比，敏捷方法更注重人与人的直接交流，更注重软件的快速迭代，更注重紧凑的自我人员组织，最重要的一点：更注重变化。
敏捷开发方法将文档视为一种软件开发的记录，而非软件开发的指导，当然也就更加优先处理软件的实现，即产生工作的软件。敏捷方法的支持者认为，完备的设计、规划及其文档是对后续进度的约束，并且不能适应变化。因此，敏捷开发方法由于将更多的精力放在真正的软件的实现上，能够更快地进行迭代。
敏捷开发方法最典型的特点即拥抱变化。当用户的需求模糊、善变时，敏捷开发方法由于其极短的迭代流程和极快的迭代速度，可以很方便地相应用户的变化。而敏捷开发方法快速迭代的特性，使得其具有更加关注人与人，包括开发人员之间和开发者－用户之间的时时交流、反馈。试想以下场景：用户委托你进行一些改进，而你需要进行完备的讨论、设计、编写文档、实现与测试，而你的用户需要等待很久的话，你和用户之间的交流是不连续的；而在敏捷开发方法中，由于迭代非常迅速，使得你和用户、你和同事之间的交流是连续的，因此需要更加关注人的参与以及用户的不断反馈。在敏捷开发方法中，用户似乎成为了开发团队的一份子，也在为软件的完善而出力。因此，敏捷开发方法非常注重客户的合作。
从上述特性来看，敏捷开发方法并非那么容易实现。如果敏捷开发方法实现得不好，很容易退化为「随想随写」模式，因此需要很高的人员素质。因此，敏捷开发方法非常注重「人的因素」。敏捷过程中要发掘出开发人员的潜力，开发人员要一直工作在一起，具有非常全面的能力，包括程序的编写和合作、决策能力。因此，敏捷开发过程也是一种人员的组织方法，要求人员充分信任、组织文化好、开发人员决定能得到充分支持（包括来自客户的支持）以及精干的队伍（因此敏捷开发方法一般适用于小型团队）。
敏捷开发方法之下也有许多的更加具体的方法论，例如极限编程XP、Scrum和测试驱动设计等。这些方法是对敏捷开发方法的更进一步定义与约束，并且提供了一些实用的「工具」来进行管理。
总的来说，敏捷开发方法不只是流程如何分布这么简单，其综合了传统开发方法的许多精华，去掉了不适合他们的部分，形成了自己的一套包含软件开发流程、人员组织、管理、日常任务分配和如何管理人员的思想的一系列方法的体系。
传统开发方法更加注重前瞻性、计划性以及工程化，即在充分的预见、设计和准备下，开发人员的开发工作可以变得简单和有条理。传统开发方法更加适用于不易更改的需求、超大型的软件和难以迭代的软件。传统开发方法更像是传统制造业，例如，硬件的开发过程中无法进行“敏捷开发”，因为硬件的难以迭代的特性使得其无法适用敏捷开发方法——除非有一天科技的进步使其成为可能。传统开发方法的适用条件也是如此，例如火箭发射程序等，这类程序需要十足的前瞻和稳定性，传统开发方法是其不二选择。
而软件毕竟是软件，其「软」的特点使其有别于硬件。软件易于更改，易于发布，因此也就易于迭代。敏捷开发方法比迭代式开发方法的迭代周期更短，也不许要螺旋式开发方法对风险的完整评估——只需要不断地迎接变化。通过前文的分析，敏捷开发方法更适用于那些人少但精炼、高素质的开发团队，并且适用于那些市场更新快速、需要快速做出反应的软件领域。
敏捷开发方法不只是工作流程，更是一套完整的管理体系。一个成熟的敏捷团队可以拥有非常高的工作效率，但这需要很高的管理水平和技术水平（敏捷开发原则注重开发人员的不断学习）。因此，当今许多团队仅仅是吸收敏捷开发方法的一些原理、精华并舍弃一些不适用于自身的原则，形成一套自己的方法来自我管理。
敏捷开发方法出现时间比传统方法的时间要晚，其背后必然有一定的历史原因。个人认为，这是因为软件开发环境的不断进步、软件市场的竞争不断激烈何互联网的发展等因素所造成的
参考文献
[1] Report about the NATO Software Engineering Conference dealing with the software crisis
[2] （美）普雷斯曼（Pressman, R. S.），《软件工程：实践者的研究方法》
[3] https://en.wikipedia.org/wiki/Waterfall_model
[4] https://en.wikipedia.org/wiki/Spiral_model
[5] https://en.wikipedia.org/wiki/Agile_software_development
[6] https://www.agilealliance.org
原文地址：http://www.cnblogs.com/basun/p/5986593.html
