APP开发，软件开发，电商系统开发，开发模式（敏捷开发，瀑布式开发，螺旋型开发，迭代开发）

思维导图：

一. 敏捷开发

敏捷方法论采用迭代/增量开发的过程模型。是一种以人为核心、迭代、循序渐进的开发方法。组织上，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。时间上，相对于传统的瀑布式开发，迭代开发把软件生命周期分成很多个小周期（一般不大于2个月，建议2周），每一次迭代都可以生成一个可运行、可验证的版本，并确保软件不断的增加新的价值。

敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（LeanDevelopment）等等

步骤： 编写用户案例，架构规范，实施规划，迭代计划，代

码开发，单元测试，验收测试等等

个体和交互 重于过程和工具。

可以工作的软件 重于求全而完备的文档。

客户协作重于合同谈判。

随时应对变化重于循规蹈矩。

以人为核心、迭代、循序渐进的开发方式

简化文档，提取文档重点，主要在于人与人之间的沟通，

对开发产品进行迭代，终完成开发。

迭代：迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发的一种实现方式就是Scrum方式：

Scrum开发流程中的三个项目角色

产品负责人(PO)：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（SM）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队(ST)：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须有很强的自我管理能力，同时具有一定的表达能力。

sprint：是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以快的速度完成它，这个过程我们称它为 Sprint。

1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ，这是由 PO（Product Owner） 负责的

2.ST（Scrum Team） 会根据 PB 列表，进行工作量的预估和安排

3.有了 PB 列表，我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog

4.Sprint Backlog 是由 ST 去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）

5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）

6.做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员。

7.当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）

8.后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。、

二. 瀑布式开发

严格按照需求文档,明确个人目标的一种开发模式

需求非常明确，

工作量十分可控，

对质量要求比较低，

业务建模也比较简单，

功能构成较少

这种开发模式如果范围控制和风险控制做的比较好的话，就真的如瀑布一般，‘飞流直下三千尺’，迅速完成客户期望，部署运行，一般都是在外包公司常见

阶段：

1.计划

2.需求分析

3.概要设计

4.详细设计

5.编码

6.单元测试

7.测试

8.运维

瀑布模型是典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

优点：

调研开发的阶段性

强调早期计划及需求调查

确定了何时产生可交付的产品及何时进行评审和审查

强调产品测试

缺点：

依赖早期进行的需求调查，不能适应需求变化

流程单一，开发中的经验得不到反馈和应用于本产品的开

发中

没有反映出开发的迭代本质

不包含风险评估

风险往往在后期才显露，失去及早纠正机会

有个缺点就是瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑，上一个周期的结束需要输出本次活动的工作结果，本次的活动的工作结果将会作为下一个周期的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。

三. 螺旋型开发

螺旋开发：1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

尤其注重风险分析阶段，适用于庞大且复杂，高风险的项目，“螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。轻松上阵，定义重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的终产品。

通常由四个阶段组成

制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

风险分析: 分析评估所选方案，考虑如何识别和消除风险；

实施工程；实施软件开发和验证；

客户评估;评价开发工作，提出修正建议，制定下一步计划。

螺旋模型中，发布的个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，终得到一个更加完善的版本。很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。

“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的终产品。

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

5个步骤：

确定目标，选择方案和限制条件。

对方案风险进行评估，并能解决风险。

进行本阶段的开发和测试。

计划下一阶段。

确定进入下阶段的方法。

优点： 严格的全过程风险管理；强调各开发阶段的质量；提供机会评估项目是否有价值继续下去。

缺点： 可能难以使用户（尤其在有合同约束的情况下）相信演化方法是可控的；项目的成功依赖于风险评估专门技术，如果一个大的风险未被发现和管理，就会出现问题。

四. 迭代开发

也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

什么是迭代式开发？

每次只设计和实现这个产品的一部分,

逐步逐步完成的方法叫迭代开发,

每次设计和实现一个阶段叫做一个迭代.

迭代模式每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代. 在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

迭代式开发的优点：

　　1、降低风险

　　2、得到早期用户反馈

　　3、持续的测试和集成

　　4、使用变更

　　5、提高复用性

五. devOps开发模式

四者对比区别：

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到好。

特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以短的时间，少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.