首页  思维导图  详情

Scrum敏捷研发流程分享&培训

2025-06-09 16:15:51   9  举报





AI智能生成

Scrum敏捷研发流程分享&培训

Scrum

敏捷

敏捷开发

敏捷培训

作者其他创作

大纲/内容

软件生命周期模型

瀑布

特点

从无到有的将软件的制作过程工程化、流程化、标准化

将软件研发划分为多个阶段，按顺序开展各个阶段的工作

每个阶段都有详细的准入/准出条件，指导各个阶段的开始和完成

可对研发成本作出相对准确的预估

缺点

前一个阶段完成前，后一个阶段在资源闲置

前期工作存在错误，会在后续工作中出现错误的放大效应

无法有效的应对变更风险，当出现变更时，研发成本可能会大幅上升

客户只能在研发工作全部完成后，才能看到系统功能，无法早期得到用户反馈

增量

特点

将瀑布模型中的完整需求拆分成多个增量/模块需求进行增量开发

每个增量具备独立的分析、设计、开发、测试，然后与已有部分进行集成

相比瀑布模型提高了项目成功率、降低项目延期率

相比瀑布模型，各个环节的资源的利用率显著提高，甚至可以多个增量/模块并行开发

相比瀑布模型，提高了一定的应对变更风险的能力

缺点

需要“系统架构师”角色，承担将完整需求合理的拆成多个增量需求的重要工作

人才要求高

犯错成本高

沉默成本高

相对瀑布模型，每次增量开发工作完成需进行集成回归测试，测试工作量增加

相对瀑布模型，应对变更的能力依然有限，尤其涉及架构方面的变更，成本甚至更大

相对瀑布模型，系统的交付时间依旧是需要研发工作全部完成之后，无法早期得到用户反馈

迭代

RUP
（每行工作内容的彩色块是不同阶段工作量分布）

特点

将研发过程划分为多个阶段，每个阶段由一个或多个独立的瀑布模型组成

每个阶段内的一个小的瀑布研发过程成为一个“迭代”，包含需求、分析设计、编码、测试、部署等

每个阶段结束都会提供一个可演示用的“半成品”系统给客户体验试用，获取用户反馈

相对瀑布模型，客户定期参与阶段性研发成果的评估，应对变更风险的能力显著提高

相对瀑布模型，迭代模型的适用性更广，不只适合纯软件研发，也可用于软硬件结合的产品研发，如数码、汽车等

缺点

阶段内部依然是瀑布模型，前一个环节工作完成前，后一个环节的资源依然存在闲置

随着市场和用户对软件质量的要求越来越高，类瀑布模型的软件质量问题逐步凸显——测试介入晚、修复成本高、测试不充分

相对瀑布模型，研发过程管理复杂度更高，对管理者的管理能力要求高，可能需要独立的管理人员

敏捷

Scrum

软件开发中Scrum框架的起源

敏捷思维深受日本产业最佳实践的影响，尤其是丰田和本田推出的精益原则，以及竹内博之和野上裕次郎开发的知识管理策略。
受上述思想和全球软件项目研究的影响，Jeff Sutherland于1993年首次在Easel为软件开发行业定义了Scrum流程并开始实施。

1986年 – Takeuchi＆Nonaka在哈佛商业评论中创造了Scrum产品开发
1993年 – Jeff Sutherland首次使用Scrum进行软件开发。
1995年 – Jeff Sutherland和Ken Schwaber对Scrum框架进行了标准化，并在OOPSLA 95上公布。
2001年 – 发布了敏捷宣言和原则，并建立了敏捷联盟。Scrum是一种敏捷方法。
2002年 – Ken Schwaber和Mike Beedle推出了第一本Scrum书籍Scrum Agile Software Development。
2002年 – Ken Schwaber和Mike Cohn共同创立了Scrum联盟。

补充：精益、敏捷、Scrum、XP关系

（不要误解成敏捷Agile是精益Lean的一个子集或 Scrum是敏捷Agile的一个子集）
此图的四个层级是“适用范围”大小的区别：

精益Lean方法涵盖的范围要广泛得多，“将工作限制在能力范围内”和“持续流程改进”等原则几乎适用于任何环境。
敏捷是更高层次——只是一堆价值观和原则，根本没有实践。
Scrum介于两者之间——不限于软件开发，但要求使用时间盒事件（Sprint/迭代/冲刺）和产品待办事项列表。
XP更具体，仅限于软件开发中的工程最佳实践领域。

特点

在一个时间周期内（时间盒），完成一批需求的研发工作，即迭代/冲刺/sprint

每个迭代的产出是一个完整的潜在可交付的系统产品

不同于传统模型的几个新概念

Sprint 冲刺，即“迭代”

ProductBacklog 产品待办列表，即“需求池”

SprintBacklog 冲刺待办列表，即“迭代需求”

Story 用户故事，即用户视角的“需求”

Epic 史诗，即“大型用户故事”，可以分解为许多小故事

Task 任务，即“任务”，任务更具技术性，往往由一个人完成

轻文档（不是没有文档！），just enough——“刚好够”

从组织方式上解决了瀑布模型存在的资源闲置问题，各个环节全角色及时沟通反馈，应对变更风险能力极强

缺点

需要全员参与，团队里的每个人都需要理解敏捷研发

培训

流程管理规范

需要培养Scrum Master

TL/资深兼任

独立SM

需要专业的敏捷项目管理工具支持

缺少有效工具支持，效率低且容易混乱

推荐Jira，但需培养Jira后台管理员

回归测试将成为一项挑战，自动化测试是必要的

敏捷的精髓

试错

一个字：快！

快速发布

CI/CD

快速感知

热部署、灰度发布、监控、异常处理（自动回滚……）

快速修复

快速优化

有错就改

敏捷是一种态度，试错是一种信仰。

沟通

如何沟通？

沟通级别

工具&流程

消息/邮件

电话/语音/视频

面谈

正式会议

及时沟通

<8H

发现问题

解决方案

计划

执行

检查

PDCA

Plan

Check

Action

好的沟通？

Talk is cheap. Show me the code.

流程管理

研发流程

节奏

例：Intel公司的Tick-Tock模式

周一到周五？

连续工作5天，效率越来越低，最后一天发布，风险放大

周末利用不上

休息、松弛有度

缓冲、突击、冲刺，而非“救火”

迭代周期为1周？

高度成熟的研发团队

迭代周期4→3→2→1

可靠且高效的发布控制

定期发布→每日发布→随时发布

快速试错

DevOps、CI/CD

手工→自动化→容器化→容器自动化

麻雀虽小

需求/设计/用例的评审

需求变更控制

缺陷跟踪

通过成功的敏捷开发实践逐步提高效率至1周一个迭代，而非“拍脑袋”决定1周一个迭代

非敏捷

流程缺失

过程混乱

质量不可控

“埋雷”

人员情绪

团队关系

无限“救火”

恶性循环

迭代周期2周+多个发布窗口

流程图

敏捷研发流程总图

甘特图

【按阶段】

【按角色】

注：
1、原则上，排期计划里的最后发布日前2天不给开发排新任务，专注debug和准备发布相关工作；
（即便bug较少也不可随意插入新需求，不允许任意打乱排期计划，开发可用于安排自研任务）

2、回归测试是敏捷开发的一个重要工作内容，发布日前1~2天是迭代回归测试的执行时间；
（敏捷的一大挑战就是如何在快速的迭代研发工作中确保质量可控，回归测试是重中之重！）

3、发布日当天仍处于测试中的需求，无法合并dev/master分支进行需求验收，取消上线；
（不满足发布条件的需求就不要强行进行发布，敏捷开发是要“快”，而不是“乱”和“错”）

4、提测比预期计划延期2天以上的需求，无论能否按期上线，均记为迭代任务失败的需求；
（2周10天一个迭代，提测延期2天，已超过20%，无论是否最终按期上线，任务本身已是失败）

迭代周期

开始标志：【第0周】的【周三】迭代会完成

结束标志：【第2周】的【周二】发布验证通过

发布窗口

窗口期

周二：20点-24点

周四：20点-24点

发布窗口期内

（支持试错的业务）不限制发布次数、回滚次数

“零容忍”的24*7业务功能，限制回滚（避免数据异常）

非发布窗口期

发布需要邮件大领导审批