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

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

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

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

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

特点

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

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

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

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

缺点

瀑布

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

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

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

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

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

人才要求高

犯错成本高

沉默成本高

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

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

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

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

增量

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

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

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

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

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

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

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

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

RUP

迭代

敏捷思维深受日本产业最佳实践的影响，尤其是丰田和本田推出的精益原则，以及竹内博之和野上裕次郎开发的知识管理策略。受上述思想和全球软件项目研究的影响，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框架的起源

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

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

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

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

Sprint 冲刺，即“迭代”

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

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

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

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

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

Scrum综合指南

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

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

从组织方式上解决了瀑布模型存在的资源闲置问题，各个环节全角色及时沟通反馈

培训

流程管理规范

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

TL/资深兼任

独立SM

需要培养Scrum Master

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

JIRA管理员操作手册

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

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

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

Scrum

敏捷

软件生命周期模型

CI/CD

快速发布

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

快速感知

快速修复

有错就改

快速优化

一个字：快！

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

试错

发现问题

解决方案

计划

执行

检查

<8H

Plan

Do

Check

Action 

PDCA

及时沟通

工具&流程

消息/邮件

电话/语音/视频

面谈

正式会议

沟通级别

如何沟通？

Talk is cheap. Show me the code.

好的沟通？

沟通

敏捷的精髓

例：Intel公司的Tick-Tock模式

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

休息、松弛有度

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

周末利用不上

周一到周五？

迭代周期4→3→2→1

高度成熟的研发团队

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

可靠且高效的发布控制

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

DevOps、CI/CD

快速试错

需求/设计/用例的评审

需求变更控制

缺陷跟踪

麻雀虽小

非敏捷

流程缺失

过程混乱

质量不可控

人员情绪

团队关系

无限“救火”

“埋雷”

恶性循环

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

迭代周期为1周？

总图

流程图

按阶段

注：1、原则上，排期计划里的最后发布日前2天不给开发排新任务，专注debug和准备发布相关工作；    （即便bug较少也不可随意插入新需求，不允许任意打乱排期计划，开发可用于安排自研任务）2、回归测试是敏捷开发的一个重要工作内容，发布日前面1~2天是回归测试的执行时间；    （敏捷的一大挑战就是如何在快速的迭代研发工作中确保质量可控，回归测试是重中之重！）3、发布日当天仍处于测试中的需求，无法合并dev/master分支进行需求验收，取消上线；    （不满足发布条件的需求就不要强行进行发布，敏捷开发是要“快”，而不是“乱”和“错”）4、提测比预期计划延期2天以上的需求，无论能否按期上线，均记为迭代任务失败的需求；    （2周10天一个迭代，提测延期2天，已超过20%，无论是否最终按期上线，任务本身已是失败）

按角色

甘特图

【开始】：【第0周】的【周三】

【结束】：【第2周】的【周二】

迭代周期

周二 20点-24点

周四 20点-24点

窗口期

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

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

发布窗口期内

发布需要邮件大领导审批

每次发布/回滚操作都需要审批

非发布窗口期

有助于产品-开发-测试形成共同的发布目标

给予研发团队在发布阶段的自由度，可提高效率

优势

发布窗口

启动阶段：松

准备阶段：紧

（不被打扰的）专注干活的过程是“松”

冲刺阶段：松

发布阶段：紧

节奏：松→紧→松→紧

智者千虑必有一失，排期计划不能是“一锤子买卖”

第一个周末：排期公示的缓冲

进度符合预期，休息放松，为接下来的发布工作养精蓄锐

若进度不理想，可用于加班突击，或用于应对意外情况

【※】发布之前的“突击”，与发布之后的“救火”，有着本质的不同

第二个周末：发布之前的缓冲

两个周末

全业务线主流程+需求周边影响

最终发布日+前1~2天

需求周边影响

窗口发布日

赋能：任何人都可便捷的执行自动化测试，而非只有测试能执行

自动化回归测试

非发布日

回归测试

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

节奏

不要假设（或想当然的认为）员工能够积极主动，设计流程要避免主观臆想

人都是懒惰的！

利用人性，顺应人性

人性

研发流程

静态测试/文档测试

评审

开发自测

前后端联调

“提测&打回”机制

冒烟测试

正式测试

验收测试

发布测试

质量监控

需求&变更管理

<2H

无主题

无准备

无结论

无效

会议管理

“家丑不可外扬”

互相学习，共同进步

管理者的权力与价值

统一风格，提高内/外合作效率

内审

外审

评审管理

分支管理

缺陷管理

利于团队形成统一目标

产品

有助于增加团队凝聚力

窗口

发布流程

流程管理

操作简单

学习容易

易用

直观

如工作流按钮可见性，不给成员误操作的机会

权限

工作流

字段

界面

自动化

事件

……

自定义

可靠

高效

宁缺毋滥

JIRA用户操作手册

实操演示

Jira

管理工具

敏捷研发流程分享