在讲敏捷开发之前，我们先来看一下，开发模式都有哪些。开发模式包括：瀑布式开发(也叫线性开发模式)、快速原型开发、螺旋开发、迭代式开发(也叫迭代增量式开发)以及敏捷开发。那接下来，我们就来看一下，这四种开发模式的特点。
1. 瀑布式开发(也叫线性开发模式)：
定义：软件开发领域，传统瀑布式开发是最典型的预见性的方法，对于产品研发的过程定义非常明确，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
特点：1. 长反馈链；2. 按过程分工，每个环节只关注自身的过程，缺少对产品整体的认识；3. 瀑布式开发也有适用的领域。
图1：瀑布模型流程图
瀑布式开发规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
优点：严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。
现状：瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
-
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
-
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
-
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；
-
各个软件生命周期衔接花费时间较长，团队人员交流成本大。
瀑布式开发的主要问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式开发在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交，大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交猴的成本损失就越少。
2. 螺旋开发：
定义：1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。
特点：1. “螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品；2. 螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
图2：螺旋模型概念图示
优点：
-
通过原型的建立，使软件开发在每个迭代的最初明确方向；
-
通过风险分析，最大程度地降低软件软件彻底失败造成损失的可能性；
-
在每个迭代阶段植入软件测试，使每个阶段的质量得到保证；
-
整体过程具备很高的灵活性，在开发过程的任何阶段自由应对变化；
-
每个迭代阶段累计开发成本，使支出状况容易掌握；
-
通过对用户反馈的采集，与用户沟通，以保证用户需求的最大实现。
缺点：
-
过分依赖风险分析经验与技术，一旦在风险分析过程中出现偏差将造成重大损失；
-
过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调；
-
由于只适用大型软件，过大的风险管理支出会影响客户的最终收益。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
3. 迭代式开发(也叫迭代增量式开发)：
定义：迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
解读：每次只设计和实现这个产品的一部分，逐步完成的方法叫迭代开发，每次设计和实现一个阶段叫做一个迭代。
特点：1. 降低风险；2. 得到早期用户反馈(短反馈链)；3. 持续测试和集成；4. 适用变更；5. 提高复用性。
图3：迭代式开发概念图示
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交，然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
4. 敏捷开发：
定义：1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
四个核心价值观：
-
人和交互重于过程和工具
-
可以工作的软件重于求全而完备的文档
-
客户协作重于合同谈判
-
随时应对变化重于循规蹈矩
注：位于右边的内容虽然也有其价值，但是左边的内容最为重要
人员彼此信任，人少但是精干，可以面对面的沟通。
十二条原则：
-
我们最终要的目标，是通过持续不断地及早交付有价值的软件使客户满意；
-
欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势；
-
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期；
-
业务人员和开发人员必须相互合作，项目中的每一天都不例外；
-
激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标；
-
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈；
-
可工作的软件是进度的首要度量标准；
-
敏捷过程倡导可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定延续；
-
对技术精益求精，对设计不断完善，将提高敏捷能力；
-
以简洁为本，极力减少不必要工作量；
-
最好的架构、需求和设计出自于自组织的团队；
-
团队定期地反思如何能提高成效，并依次调整团队的行为。
图4：敏捷开发流程示意图
迭代开发和敏捷开发的区别：
-
敏捷开发也有迭代过程，但是与迭代开发模式相比，敏捷开发的迭代周期更短，往往是1—2两周，而迭代模式中，迭代周期较长，一般为1个月，也就是4周，甚至更长；
-
敏捷开发强调“敏捷”，它强调团队的交流与沟通，而文档并不是最重要的；迭代模式中每个迭代都需要有详细的文档。
敏捷开发理解：
-
传统(瀑布式、螺旋式、迭代)开发看中交付，敏捷开发强调协作；
-
传统开发注重文档，敏捷开发强调交付物(可以工作的软件)
-
这里必须说明，敏捷开发并非不要文档，而是将文档融入到交付物中，如碎片化的敏捷向的需求(被拆分的用户故事)，清晰的代码注释，完备的单元测试等。
-
-
敏捷开发的大忌就是按部就班
敏捷开发小组主要的工作方式可以归纳为：
-
作为一个整体工作；
-
按短迭代周期工作；
-
每次迭代交付一些成果；
-
关注业务优先级；
-
检查与调整
敏捷开发有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷开发强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。