在敏捷软件开发方法引入之前，人们已经发展出了一整套的相关理论，这些理论在项目开发中起到了重要作用。传统软件开发最显著的特点就是自上而下的开发模式。简而言之，就是先进行上层建模，画出各类的UML图，然后根据已经设计好的上层架构，也就是流程图，类图等各种UML图进行模块化的实现。在这样的开发模式中，上层架构的设计就变得极其重要的，因为具体的实现都依赖于这个架构设计。然而，上层架构的设计往往并非一帆风顺，软件不像其它工业产品，要一次性设计出一个不需要修改的完美架构方案几乎是不可能的事情。主要的困难有两个，首先是由于互联网时代的日新月异，客户对软件的需求往往会发生变化，从而不断地提出新的需求。其次就是软件产品本身的性质就已经决定了设计出一个完美的架构几乎是不可能的。原因是多方面的，但最重要的原因就是这种自上而下的开发模式，在设计上层架构时缺乏实践的指导和检验。上层架构完成之后，一旦在编码实现的时候发现某一部分的设计是不合理的，必须要改进或者完全推翻重新设计，那么依赖此部分的上层设计都将失效，往往会引起雪崩效应，影响到项目的整体。
上层的架构中缺乏有效的实践会导致不可预测性，重复的错误，以及努力的白白浪费。延期的进度，增长的预算，和低劣的质量使得客户对开发团队失去信心。更长的工作却生产出更加低劣和不稳定的软件产品，也使得开发人员失去信心。
为了防止上述的情况发生，我们希望软件开发能够在一个框架中进行，这个框架越精心越好，这样，软件开发就在一个受约束的道路上进行，开发人员也就按照一系列事先定义好的活动来执行就可以了可以根据现在所知道的把这些活动称为指令软件过程，也称为重量级软件过程。
对于开发人员来说，指令性过程虽然在开始时是会好好遵守的，但一旦遇到难以实现的困难时，往往会彻底抛弃它，这样一来，“雪崩”效应往往就开始了。
一般的，我们根据过去的经验来挑选那些在以前的项目中看起来好像工作得不错的方法来构建我们这些“指令系统”。
我们会对错误进行诊断，并在过程中增加了更多“指令”来防他以后重犯这样的错误。经过多次这样的增加以后，我们就会不堪巨大、笨重的过程的重负，极大地削弱我们完成工作的能力，同时过于笨重的过程会降低团队的相应能力，极大地削弱了我们完成工作的能力，同时过于笨重的过程会降低团队的响应能力，大大增加出错的几率。
在软件开发陷入到不断增长的过程的泥潭情况下，敏捷软件开发联盟出现了，这个联盟概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。
·个体和交互高于过程和工具
·可以工作的软件高于详尽的文档
·客户合作高于合同谈判
·响应变化高于遵循计划
过程和工具，面面俱到的文档，合同谈判和遵循计划这些都是传统软件工程中所强调的，在 敏捷开发的理念中，并没有抛弃这些东西，而是将这些条条框框给弱化了。
个体和交互高于过程和工具:
人是任何项目能完成的最终载体，是获得成功最重要的因素，从某种程度上来讲，这个原则也反映了以人为本的思想。但是如果只是一些厉害的程序员各自为战，没有好的过程管理，面对复杂项目的开发也是无能为力的，过程当然重要，但是开发者应该将精力更多地集中在人员和他们怎样一起工作上去。沟通问题是一个项目成功最重要的因素之一，尽管一个项目可能缺乏正式的软件过程，但是只要团队成员之间的沟通有效，项目成功的可能性依然不低，但是如果开发人员各自为战，那么就算个体的技术出众，也无法将力量汇集在一起，也就难以完成项目了。再说工具，工具始终是给人用的，是服务于人的，过分地夸大工具的作用，将精力放在工具上，最后只会被庞大，笨重的工具所拖累。庞大的工具往往需要更多地上手时间，有时候带来的麻烦比好处还要多得多。能用记事本就不要用word,能用草图就不要用visio,能用vim+gcc解决就不要去安装vs。团队的构建比环境的搭建重要得多，软件开发不同于工厂的流水线，买来机器，随便招来一批工人就可以开始生产了，作为纯智力产品的软件，需要以人为本，以团队至上。
可以工作的软件高于详尽的文档
软件开发需要文档，这是不可或缺的。传统软件在文档的编写方面可谓是达到了登峰造极的程度，以至于很多时候，开发人员进行的好像不是软件开发，而是文档开发，这就有点本末倒置了。
规范的编码风格是可以在很大程度上取代文档编写的，规范的编码风格，如驼峰命名法，能够大大增加代码的可读性，以甲骨文公司为例，他们对代码的规范要求非常苛刻，他们的数据库产品的底层核心代码中任何一个接口乃至于变量的命名都得由一个专门的小组来协商完成。
如果可以在不看注释，文档的情况下读懂代码，那么注释和文档的重要性就被削弱了，也就没有必要再书写冗长的文档了。
从另一方面来看，保持文档的同步性也是一个麻烦的问题，代码不同于建筑，往往需要不断修改，重构，而代码出现改动之后，相应的文档也需要进行改动，而文档的同步往往是非常容易被人忘却的，这样往往会导致开发人员之间沟通的障碍，客户与开发团队之间的矛盾。因此，最好的文档就是代码本身，而文档应该只有在确实需要的时候才进行编写。
·客户合作高于合同谈判
客户提出需求然后就做甩手掌柜，这种传统的软件开发思维需要改进。只有客户最清楚他们到底想要什么，但是他们对软件开发一无所知，很有可能一两次的谈话并不能够精确地定义他们的需求，更何况客户随时都会改变主意，因此客户和开发人员密切地工作在一起，而不是依赖于合同或者关于需求的纸面上的定义，才能开发出客户所需要的产品。
·响应变化高于遵循计划
项目的计划当然是极其重要的，传统的软件开发习惯于在编码之前就做好严格的软件设计，但是一句老话说得好，计划往往赶不上变化，客户的需求会变化，业务环境在变化，技术也在变化，开发人员往往不得不拥抱变化，因此，过于详细的软件方案设计往往只会导致时间的不断浪费。正确对待计划的态度应该是在代码设计优化的同时保持简单的原则，让项目计划具有可塑性，面对变化，必须要有变通的余地。因此，较好做计划的策略是:为下两周做详细的计划 ，为下三个月做粗略的计划，而对于一年以后要做什么，有个粗略的想法就行。
两者的对比:
传统软件工程主要有: 瀑布式、迭代式和螺旋开发这几种开发方式，下面介绍敏捷开发和这几种开发方式的区别。
首先，相比迭代式开发，相同的是两者都强调在较短的开发周期提交软件。基于 Scrum的迭代开发一般会在一个比较长的一个迭代周期频率下不断交付，同时迭代中不允许有变化的需求，这样就有一些场景让这种迭代很困难，例如紧急的技术支持、临时增加的非常高的优先级的需求等等，另外项目的估算非常难，导致不容易承诺。相比较，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。正如前面所提到的，相比于迭代开发，敏捷开发更加重视个体和交互以及与客户的升入交流。
敏捷开发区别于瀑布式的特征很明显，敏捷开发是以一种迭代的方式推进的，而瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行，步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。敏捷开发过程中，软件一直处于可使用状态，它将项目分成若干相互联系、可以独立运行的子项目，因此，每个阶段软件都是可见的，客 户可以直观的体验并提出意见。如果按照瀑布式流程，客户可能在签订开发合同3个月 后，看到的还只是各种文档（需求文档、设计文档、详细设计文档等等），客户心理或许会不踏实。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进 行过程中可能变化的情况下基本是不可行的。在瀑布式开发中，需求修改的时间越靠后，成本越大，所以需求分析人员的压力很大。由于敏捷开发是迭代式的，并且迭代周期较短，因此很容易相应新需求或是对旧需求的修改。瀑布式开发有很多文档，但敏捷开发不是没有文档，而是轻文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论，比如概念设计文档、架构图、SWOT分析文档等等，这些文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。
和螺旋开发方法相比，敏捷方法强调适应性而非预见性。螺旋开发将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”的核心就在于开发者不需要在刚开始的时候就把所有事情都定义的清清楚楚，开发人员轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到使客户满意的最终产品。螺旋开发很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之 前，都必须首先进行风险评估。而敏捷开发，针对软件开过程中诸多的不可预见性，强调的是适应性，适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
参考文献:
[1]杜岳升.敏捷软件开发原理和项目中的应用[D]. 天津:南开大学,2004
[1]梁永幸.浅谈敏捷开发与传统开发方式的区别[J].电子世界,2012年第24期