瀑布式开发和敏捷式开发
1.瀑布模型
1.1 瀑布模型介绍
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。1.2 瀑布模型核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序， 如同瀑布流水，逐级下落。1.3 瀑布模型有以下优点
(1)为项目提供了按阶段划分的检查点。(2)当前一阶段完成后，您只需要去关注后续阶段。
(3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
1.4 瀑布模型有以下缺点
(1)在项目各个阶段之间极少有反馈。(2)只有在项目生命周期的后期才能看到结果。
(3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
(4)瀑布模型的突出缺点是不适应用户需求的变化。
2.迭代模型
2.1 什么是迭代模型
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。2.2 迭代模型的使用条件
(1)在项目开发早期需求可能有所变化。(2)分析设计人员对应用领域很熟悉。
(3)高风险项目。
(4)用户可不同程度地参与整个项目的开发过程。
(5)使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。
(6)使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。
(7)具有高素质的项目管理者和软件研发团队。
2.3 迭代模型的优点
与传统的瀑布模型相比较，迭代过程具有以下优点：(1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
(2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
(3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
(4)由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
3.敏捷开发模型
3.1 什么是敏捷开发
敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本。能够很好地适应需求变化的代码编写和 团队组织方法，也更注重软件开发中人的作用。敏捷建模（Agile Modeling，AM）的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。3.2 敏捷开发特点
(1)人和交互 重于过程和工具。(2)可以工作的软件 重于求全而完备的文档。
(3)客户协作重于合同谈判。
(4)随时应对变化重于循规蹈矩。
项目的敏捷开发,敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果:关注业务优先级； 检查与调整。最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
4.螺旋模型
5.快速原型模型
快速原型模型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。6.几种模型间的对比
- 瀑布式开发
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。
- 迭代式开发
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。
然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
- 螺旋开发
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
- 敏捷开发
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的 需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
一、什么是瀑布式开发
瀑布式开发的基本流程是 需求 → 设计 → 开发 → 测试 ， 是一个更倾向于严格控制的管理模式 。 要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B 端的项目。
不得不说瀑布项目失败率会比较高，因为它有一个很大的缺陷， 就是受各种条件的制约。当产品研发完成后， 到了产品测试阶段 万一发现问题 ，或者发现其无法满足市场需求， 那么就需要重新开发，甚至需要重新规划产品，这 间接导致了产品延期发布的高发性 与不确定性。
微软 的瀑布式开发模式就是个很好的例子。随着用户对软件的需求越来越苛刻，微软的软件产品曾经遭受了大家的不满，原因并非是产品的使用问题，而是其更新周期太过漫长 。
比如微软Office 、 Windows 等主打产品的更新周期长达 3 年左右，软件延期发布实属家常便饭，此时微软的瀑布式开发模式已经难以满足新型软件的开发要求，不得不改变产品的研发策略。
随着网络的逐渐兴起，软件交付模式发生了巨大变化，也正是在 那 个时候，“敏捷开发”模式被国外的软件先行者们探索出来了。
二、什么是敏捷式开发
简单的说，敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把 用户（客户 ）最关注的软件原型做出来，交付或上线，在实际场景中去 快速 修改弥补需求中的不足，再次发布版本。通过一些敏捷实践方式，细化story ，提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确、创新性或者需要抢占市场的项目。
还是拿微软来说，微软的Visual Studio 2010是公司内部首个因敏捷开发模式而受益的Visual Studio版本，该软件发布于2010年4月，耗费了两年的时间完成开发，但随后研发团队发现软件中的许多模板对于敏捷开发者来说太过笼统，几乎没有太大的实际意义，微软的软件研发策略也就从此开始发生了巨大变化。以往的产品更新周期为两到三年，目前的版本更新速度已经缩短至一个季度左右，这在瀑布式开发模式下是难以想象的。
敏捷式开发在国外大放异彩， 当然在国内也不例外，国内很多研发者们结合当下软件市场环境，也有了新的研发策略。
国产开源的禅道项目管理软件，2009 年开始遵循Scrum （ 敏捷式开发中比较流行的一种方式）的管理思想，发布了第一个产品版本 。自发布以来，禅道曾数次打败JIRA 及其他强有力的竞品，连续四年荣膺国内外软件测试行业最常用测试管理工具第一名 ，也算是国产软件 的骄傲了。
在产品开发过程中， 禅道研发团队认为Scrum方法虽然注重实效，操作性强，非常适合软件研发项目的快速迭代开发 ，但它只规定了核心的管理框架，还有很多细节流程没有完善。于是禅道团队结合国内研发现状，整合了Bug管理、测试用例管理、发布管理、文档管理等功能，完整的覆盖了软件研发项目的整个流程。
在禅道软件中，明确将产品、项目、测试三者概念区分开，产品人员、开发团队、测试人员，三者分立，互相配合，又互相制约，通过需求、任务、Bug来进行交相互动，终通过项目拿到合格的产品，是敏捷式开发的优秀案例。
（禅道软件界面图）
三、瀑布式开发与敏捷式开发对比
很显然，敏捷式开发与瀑布式开发有着质的区别，但总的来说，在管理项目过程中，都不会严格的按照完全的敏捷或者完全的瀑布模式进行开发，而是各自掺杂了其他的方式。
可见，项目管理过程中，过于强调模式并没有意义，重要的是要能预防问题的发生，在问题发生之后，能用最小的成本解决，模式起到的更多是一个参考作用。
瀑布开发模式：
瀑布开发模式有以下显著的特点：
1.严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
2.重视和强调过程文档，在开发的中后期才会看到软件原型，早起只能通过文档来了解系统的模样。
在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
3.瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段的工作。
好处是：可以让开发人员能够更专注于本职工作，提高阶段效率。
坏处是：
a.由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
b.对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解偏差）。
4.瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
5.既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大的多。
代价比较大的主要原因还是每个开发阶段的步子过大，每一次调整都可能伤筋动骨。
6.更适合需求相对稳定的大型项目。
敏捷开发模式：
核心是快速迭代，拥抱变化。
因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
敏捷开发模式有以下显著的特点：
1.story细化。
2.简单设计，避免过度设计。
3.重复迭代。
4.减少不必要的文档。
5.客户最关心的功能最先完成。
6.要求客户有时间对每次迭代的成果进行确认，提出改进意见。
7.showcase。
8.沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。加强团队之间和客户之间的沟通。
9.测试驱动开发（TDD）
10.需要更强的个人和团队能力。
11.敏捷的管理是团队的自我管理和项目经理的服务式管理。
12.敏捷开发不能在一开始就给出项目完整的成本计划。
13.在有技术问题还没有解决的情况下不适合展开迭代。
14.敏捷实践：晨会，deadline，负责人制等等。
瀑布+敏捷开发模式：
核心是减小瀑布模型的粒度，采用敏捷开发的优秀实践方式，提高开发的沟通效率，提供项目的全景视图。
1.瀑布模型
1.1 瀑布模型介绍
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。1.2 瀑布模型核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。1.3 瀑布模型有以下优点
(1)为项目提供了按阶段划分的检查点。(2)当前一阶段完成后，您只需要去关注后续阶段。
(3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
1.4 瀑布模型有以下缺点
(1)在项目各个阶段之间极少有反馈。(2)只有在项目生命周期的后期才能看到结果。
(3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
(4)瀑布模型的突出缺点是不适应用户需求的变化。
--------------------------------------------------------------------------------------
2.迭代模型
2.1 什么是迭代模型
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。2.2 迭代模型的使用条件
(1)在项目开发早期需求可能有所变化。(2)分析设计人员对应用领域很熟悉。
(3)高风险项目。
(4)用户可不同程度地参与整个项目的开发过程。
(5)使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。
(6)使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。
(7)具有高素质的项目管理者和软件研发团队。
2.3 迭代模型的优点
与传统的瀑布模型相比较，迭代过程具有以下优点：(1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
(2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
(3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
(4)由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
--------------------------------------------------------------------------------------
3.敏捷开发模型
3.1 什么是敏捷开发
是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本。能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。敏捷建模（Agile Modeling，AM）的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。3.2 敏捷开发特点
(1)人和交互 重于过程和工具。(2)可以工作的软件 重于求全而完备的文档。
(3)客户协作重于合同谈判。
(4)随时应对变化重于循规蹈矩。
项目的敏捷开发,敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果:关注业务优先级； 检查与调整。
最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，
因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
4.螺旋模型
详见 http://baike.baidu.com/view/551040.htm5.快速原型模型
详见 http://baike.baidu.com/view/1449532.htm6.几种模型间的对比
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
一、什么是敏捷开发
敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。
怎么理解呢？首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。其次，敏捷开发都具有以下共同的特征：
- 迭代式开发
- 增量交付
- 开发团队和用户反馈推动产品开发
- 持续集成
- 开发团队自我管理
二、具体方式
上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？
Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。这些方法还需要结合业务选择并实践，目前还没有深入学习~
三、敏捷开发宣言和准则
《敏捷宣言》
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者
敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。
敏捷开发十二原则
在敏捷开发中，我们遵循以下准则：
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
