Scrum敏捷开发模式介绍与实践
文章目录
- 前言
- 一、开发模式
-
- 1. 瀑布流开发模式
- 2. 迭代开发模式
- 3. 螺旋开发模式
- 4. 敏捷开发模式
- 二、敏捷开发模式
- 三、敏捷模式
-
- 1. Scrum
- 2. Kanban
- 3. XP
- 4. Lean Startup
- 四、Scrum 敏捷开发模式
-
- 1. 框架图
- 2. 角色
-
- Scrum Master，SM
- Product Owners， PO
- Software Developers， SD
- 3. 术语
-
- Product Backlog
- Sprint
- Sprint Planning
- Sprint Backlog
- Scrum Team
- Daily Scrum
- Increment
- Sprint Review
- Sprint Retrospective
- 五、迭代实践
-
-
- 需求阶段
- 开发阶段
- 提测、发版阶段
- 回顾阶段
-
- 总结
前言
在当今信息爆炸的时代，软件系统种类繁多、网络环境瞬息万变、行业竞争异常激烈场景下，软件企业如何在较短的生命周期中提高软件的开发效率、交付质量，降低研发和交付成本是首先要考虑的。敏捷开发模式就是注重软件的持续交付和快速应对需求的变化，通过固定的短周期的迭代开发方式和快速的反馈保证产品和项目的质量，并且规范了管理敏捷团队的策略和模式。
一、开发模式
1. 瀑布流开发模式
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。
2. 迭代开发模式
迭代式开发也被称作迭代增量式开发或迭代进化式开发，每次只设计和实现软件的一部分，逐步完成整个软件的开发，弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
3. 螺旋开发模式
瀑布模型和快速原型（快速创建一个可以运行的软件原型，后期慢慢根据客户需求完善软件）模式结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
4. 敏捷开发模式
二、敏捷开发模式
敏捷开发模式，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力模式。相对于传统开发模式，其更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
三、敏捷模式
1. Scrum
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum 是一种可以让人们将复杂的问题解决的同时保证生产率，创造性地交付最高可能价值的框架。
2. Kanban
KanBan is an approach to change management that employs a Kanban system onto an existing process context in order to provoke evolutionary and incremental change.
Kanban可以被引入进任何开发框架去支持和推动持续性软件开发，不管你的开发模式是敏捷的(比如：XP)，还是传统的开发方式(比如：waterfall)。
Work In Progress，细分的工作流程。
3. XP
Extreme Programming，极限编程。特点：快速反馈、假设简单、增量变化、包容变化。
4. Lean Startup
精益创业，是一种用于开发产品和服务的方法论，旨在缩短产品开发周期，并快速发现产品创意构思是否可行。最小可行产品（MVP）是“一个新产品的版本，它允许团队以最少的努力收集关于客户的最大验证学习量”（类似于试点实验）。
四、Scrum 敏捷开发模式
官网
1. 框架图
2. 角色
Scrum Master，SM
定义：开发团队负责人
职责：负责团队管理，交付执行。
Product Owners， PO
定义：产品需求负责人
职责：负责需求录入。
Software Developers， SD
定义：开发成员，前端、后端、测试
职责：开发。
3. 术语
Product Backlog
定义：产品需求清单
活动：PO 输出产品需求清单，组织迭代计划会议。
Sprint
定义：冲刺、迭代
活动：一个迭代周期，一般2 - 4周。
Sprint Planning
定义：迭代计划会议
活动：评估需求风险、优先级、复杂度，根据迭代团队规模划分每个迭代的需求清单，确定迭代各个阶段的时间点（设计、开发、测试、发版），环境资源准备（迭代分支、技术支持等）。
Sprint Backlog
定义：迭代需求清单
活动：需求分析，评估工作量、设计实现方案、拆分任务、分配需求任务，根据需求工作量的评估确定每个需求的提测时间点，让测试可以提早介入。
Scrum Team
定义：完整功能的交付能力的团队，开发、测试、设计。
活动：SM 负责整个团队的管理、协调及敏捷交付模式的执行。
Daily Scrum
定义：日常迭代活动，
活动：日例会，早晚可各一次，10分钟左右，跟踪迭代需求开发进度，发现、解决风险，SM 更新需求清单表、燃尽图，跟踪、协调风险。
Increment
定义：产品增量，经过一个迭代交付的产品需求增量
活动：演示，验收。
Sprint Review
定义：迭代评审会议
活动：迭代评审会议，2个小时，讨论迭代开发中的优缺点，总结、改进。
Sprint Retrospective
定义：迭代回顾会议，产品发展一个里程碑的交付
活动：迭代回顾会议，回顾多个迭代中的敏捷交付规范是否认真落实，改进建议。
五、迭代实践
需求阶段
输入：迭代需求清单
内容：需求分析、需求设计、工作量评估、确定团队成员、需求分配、任务拆分。
输出：迭代需求进度表
| 需求编号 | 父需求编号 | 需求描述 | 工作量（人/天） | 负责人 | 状态 | 优先级 | 冒烟测试 | 开始时间 | 提测时间 | 测试完成时间 | 实际提测时间 | 实际完成时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10011 | 1001 | 人员管理列表页面 | 3 | 张三 | 待处理 | 中级 | 2022/04/30 | 2022/05/02 |
开发阶段
输入：迭代需求清单、进度表、设计方案、任务清单
内容：日例会、提测、发版。
输出、更新：迭代需求进度表、燃尽图、风险点
迭代需求进度表（进度1）
| 需求编号 | 父需求编号 | 需求描述 | 工作量（人/天） | 负责人 | 状态 | 优先级 | 冒烟测试 | 开始时间 | 提测时间 | 测试完成时间 | 实际提测时间 | 实际完成时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10011 | 1001 | 人员管理列表页面 | 3 | 张三 | 待测试 | 中级 | 通过 | 2022/04/30 | 2022/05/02 | 2022/05/02 |
迭代需求进度表（进度2）
| 需求编号 | 父需求编号 | 需求描述 | 工作量（人/天） | 负责人 | 状态 | 优先级 | 冒烟测试 | 开始时间 | 提测时间 | 测试完成时间 | 实际提测时间 | 实际完成时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10011 | 1001 | 人员管理列表页面 | 3 | 张三 | 已发布 | 中级 | 通过 | 2022/04/30 | 2022/05/02 | 2022/05/03 | 2022/05/02 | 2022/05/03 |
燃尽图（迭代日期与未完成任务数）
风险点
| 序号 | 风险描述 | 影响 | 解决方案 | 状态 | 更新时间 | 负责人 |
|---|---|---|---|---|---|---|
| 1 | 后端接口提供延迟 | 前端联调进度阻塞 | 需求整体提测时间延后 | 已解决 | 2022/05/03 | 张三 |
测试用例
| 编号 | 标题 | 优先级 | 类型 | 冒烟用例 | 作者 | 创建时间 | 负责人 | 状态 | 通过时间 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 人员列表页面数据显示正常，点击分页正常 | P0 | 功能测试 | 是 | 李四 | 2022/05/02 | 张三 | 通过 | 2022/05/02 |
提测、发版阶段
输入：测试用例
内容：回顾会议
输出：测试报告、发版计划、迭代回顾会议经验总结表
迭代回顾会议经验总结表
| 编号 | 优点 | 总结 |
|---|---|---|
| 1 | 缺陷率低 | 开发质量提高，严格遵守了开发规范 |
| 编号 | 缺点 | 总结 |
|---|---|---|
| 1 | 提测延后率高 | 前后端开发进度不协调，缺少沟通 |
回顾阶段
| 编号 | 新加的规范 | 去掉的规范 |
|---|---|---|
| 1 | 代码评审 | 无 |
总结
总的来说，Scrum 敏捷开发模式还在深入实践中，慢慢在实践中改进。