开发模式

开发模式

敏捷开发

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

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

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

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

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

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

• 产品负责人(PO)

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

• 流程管理员（SM）

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

• 开发团队(ST)

  主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标

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的产品需求中

下面是运用 Scrum 开发流程中的一些场景图：

（每日站立会议，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图）

（任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）

（计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。

怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时）

瀑布式开发

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

• 需求非常明确，
• 工作量十分可控，
• 对质量要求比较低，
• 业务建模也比较简单，
• 功能构成较少

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

阶段

1. 计划
2. 需求分析
3. 概要设计
4. 详细设计
5. 编码
6. 单元测试
7. 测试
8. 运维

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

V型开发

开发过程与验证过程对应的对称型结构，

V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边的下划线分别代表了需求分析、概要设计、详细设计、编码。右边的上划线代表了单元测试、集成测试、系统测试与验收测试。看起来V模型就是一个对称的结构，它的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。

螺旋型开发

尤其注重风险分析阶段，适用于庞大且复杂，高风险的项目，

通常由四个阶段组成

1. 制定计划
2. 风险分析
3. 实施工程
4. 客户评估

螺旋模型中，发布的第一个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，最终得到一个更加完善的版本。

原型开发

原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。在实际的项目过程中，借助于组织过程资产以及快速模型软件，一般在需求分析的时候，就可以建立一些简单的原型，例如在第一家YH公司中，因为是“行业软件提供商”，所以拥有各个地域的行业解决软件方案，惯用的伎俩就是将其他地市的项目拿到本次项目实施地，作为原型化模型。原型化模型是极具意义的项目实践

文章参考于许大虾的博客