scrum敏捷开发、敏捷测试，快速迭代实践

目前敏捷开发、敏捷测试几乎已成为各个公司的通识，但每个公司的方法和流程都有所不同，以下就分享一下我所学习到的内容

 

一、迭代角色

1、Scrum Master

1.1 促进团队提高创造力，并努力提高开发团队的效率

1.2 负责消除团队的风险以及困难

1.3 识别 Sprint 中的风险并提供解决措施

1.5 负责召开复盘会议。 组织 Sprint 计划会议

1.6 负责跟进迭代进度

1.7 组织 Scrum 晨会

2、产品

2.1  负责迭代需求计划

2.2 负责编写需求产品设计文档

2.3 白皮书、操作手册、介绍资料

2.4 了解市场最新政策、动向、竞品分析

2.5 公司内部产品培训

2.6 不定期去客户现场沟通，调研新需求

2.7 负责管理好 Jira Sprint

2.8 迭代温馨提示、产品验收

2.9 积极参与测试用例评审并有效反馈

3、研发

3.1 认真评估产品需求，协助产品经理丰富其产品设计

3.2 根据产品需求文档，对需求任务做合理的拆分并评估其工作量

3.3 编写有效的研发设计文档并组织评审

3.4 积极参与测试用例评审并有效反馈

3.5 积极参与代码评审并有效反馈

3.6 需求负责人需要积极协调所有参与研发人员一起保证需求目标达成

3.7 需求有延期风险需要及时反馈给 Scrum Master

3.8 积极反馈迭代流程问题

4、测试

4.1 设计测试用例并执行测试    后期问题跟踪

4.2 为软件提供产品质量快速反馈

4.3 负责发布预演

4.4 识别需求，研发，测试，上线各阶段中可能存在的风险，并且快速反馈

4.5 发现敏捷过程中流程问题并提出改进意见

4.6 编写自动化测试用例与脚本

4.7 测试直接对接生产bug

4.8 关注系统级别的问题：比如性能、高可用性、安全等

4.9 鼓励提Bug时，提供更多有价值的信息

5、Devops

5.1 负责 CI/CD 

5.2 负责迭代发布

 

 

 

二、文档模板

1、需求文档模板

包含信息：需求名称、计划上线时间、需求目标、背景和策略适合、设想、需求、用户交互设计、问题、没有做。

参考示例：

模板下载：无

2、测试用例模板

包含信息：

参考示例：

模板下载

3、研发设计模板

包含信息：

参考示例：

模板下载

4、发布升级邮件模板

包含信息：升级开始时间、升级结束时间、升级影响的系统范围、升级可能会给客户带来的影响、客户需要注意的事项、升级期间的客户支持和沟通机制、应急方案和措施、升级原因

参考示例：

5、发布看板模板

包含信息：Zoom 会议室地址、发布站点、数据库变更、ES脚本变更、资源码变更、SQS 变更、apollo 配置变更、上线清单、点检发布时间、点检验证时间、点检测试用例验证、生产发布时间、生产验证时间、生产测试用例验证、回滚方案、保驾安排、发布过程记录等

参考示例：

模板下载：无

6、产品发布说明文档

包含信息：

参考示例：

模板下载

三、迭代流程

1、需求

1.1 迭代需求吹风会（会议）

1）会议目标：

• Scrum Master 规划评估整体工作量，提前了解下个迭代的任务
• Scrum Master 对于下个迭代的任务安排提前进行规划安排
• 所有成员了解需求
• 所有成员需求可行性分析
• 所有成员系统影响分析
• 明确下迭代目标
• 明确US是否需要再切分

2）会议开始时间：上个迭代发布日的前一周。比如：上个迭代的发布日是： 5.20号(礼拜三)，则建议会议时间是：5.13号。

3）会议主持人：Scrum Master

4）会议参与人：产品经理、研发、测试

5）会议建议时长：不超过1.5个小时

6）会议开展方式：

• • 产品经理根据需求和bug优先级安排下个代计划完成需求
  • 研发安排下个迭代技术需求
  • 研发和QA分析判断需求是否合理以及是否能技术实现
  • Scrum Master 控制会议时长，控制问题讨论不要无限扩展，高效达成会议目标

1.2 产品需求详细设计文档编写

1）负责人：产品经理

2）文档编写格式：参考 《二.1需求文档模板》

3）文档地址：

4）完成时间：在迭代 sprint planning 会议之前

5）需求涉及到集成联调的，需提前和干系人（平台集成、属地集成、项目经理等）约定联调时间

6）需求涉及到跨部门（比如税件）的，需要提前和协作方沟通排期以及联调时间

7）PRD 在 sprint planning

1.3 迭代启动会（会议）

1）会议目标：

• 定本迭代的主要目标

• 确定本迭代需要完成的具体需求（包含产品需求和技术需求）

• 确定迭代投入资源（包含人员和其他资源）

• 深入需求了解，为研发设计，测试设计提供参考准则

• 评审每个产品需求、技术需求的合理性并安排研发、测试人员

• 评估每个需求的 story point 

2）会议开始时间：迭代开始的第1天

3）会议主持人：Scrum Master

4）会议参与人：产品经理、研发、测试

5）会议建议时长：不超过3个小时

6）会议开展方式：

• 产品经理至少要提前2天在会议前提供完整的 PRD 文档，并抄送给全部团队人员
• 优先评审产品需求、技术需求，bug 直接委派研发或者测试人员，不进行具体的讲解
• 产品对照需求说明文档讲解，研发、测试提出问题，如果没有问题或者问题能够解释清楚，则该需求评审通过，建议优先由熟悉此块功能的人认领，然后是其他人主动认领
• 如果需求描述不清且产品经理在会议上也无法描述清楚，则在会议上跳过该需求，由产品经理在当天或者第2天重新组织小范围会议讨论，参会人员包含Scrum Master、研发、测试。如果第2次还是没达成一致，则不列入本迭代任务，将backlog里的任务置换一个到本迭代中
• Scrum Master 控制会议时长，控制每个需求评审无限扩展，高效达成会议目标
• 对每个需求进行 story point 估算。基于 Jira poker 投票方式，大家一起估算。story point 估算方式可参考《Story Point 估算方法》

2、研发

2.1 迭代需求拆分及估算

1）需求拆分规则：每个需求拆分包含有 代码评审、测试用例评审、功能测试 3个子任务，有集成联调或者跨部门联调，同时创建一个 集成联调 子任务

2）需求按照产品视角进行细分，每个细分功能如果前后端都涉及到，则创建2个细分子任务

3）每个子任务估算“预计评估时间”，“预计剩余时间”

4）需求的 owner 是整个需求的负责人，负责需求整体的进度、联调工作

5）在迭代启动会当天要完成绝大部分需求拆分及估算，并在第2天晨会进行确认。剩余需求拆分和估算在第2天完成

2.2 研发需求设计文档编写

1）负责人：研发

2）文档编写格式：参考 《二.3 研发设计文档模板》

3）文档地址：

4）需求涉及到集成联调的，需提前和干系人（平台集成、属地集成、项目经理等）约定联调时间并记录在 Jira 中

5）需求涉及到跨部门（比如税件）的，需要提前和协作方沟通联调时间并记录在 Jira 中

2.3 研发需求设计文档评审

1）负责人：研发

2）参与人：研发、测试、软件构架师（可选，大的需求、架构调整时需要参与）

3）评审方式：线下自行组织

4）评审时间：// TODO 

2.4 测试用例编写

1）负责人：测试

2）文档编写格式：参考《测试用例文档模板》

3）文档地址：

4）测试用例编写技巧：

• 等价类划分方法
• 边界值分析方法：等价类划分的补充，对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据
• 错误推测方法：基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法

2.5 测试用例评审

1）负责人：测试

2）参与人：产品经理、研发、Scrum Master（可选）

3）评审方式：线下自行组织

4）评审原则：

• 评审前，优先先进行同行评审
• 先讲解本次评审用例的需求点
• 根据需求点对用例进行场景讲解，设计思路，以及业务覆盖
• 参与人员积极补充场景
• 用例场景遗漏太多，可以评审不通过，补充后，第二天测试再主动发起评审

2.6 需求提测

1）负责人：需求负责人

2）参与人：测试

3）提测说明：按照提测规范进行提测，参考《团队最佳实践》中研发提测需求

2.7 代码评审

1）负责人：研发

2）评审时间：每次代码 merge 的时候

3）参与人：其他研发干系人

4）组织方式：自由方式

2.8 下个迭代需求吹风会

1）参考 三.1.1.1 迭代需求吹风会

2）执行时间：迭代发布日的前一周

3、测试

3.1 FAT 测试

1）负责人：测试

2）测试时间：需求负责人联调自测结束

3）测试开展方式：

• 按测试用例执行
• 并标记执行状态
• 每天汇报测试进度
• 更新jira任务剩余时间

4）Bug 反馈：记录到 Jira 需求的子任务下，并标记为 内部Bug

5）Bug 修复方式：基于 feature 分支修改，然后自己验证通过后，merge 到 develop 分支，发布 FAT 环境

3.2 代码封板

1）负责人：后端负责人、前端负责人

2）封板时间：FAT 测试通过。一般是迭代发布周的上周五下班前。比如 5.20（礼拜三）是迭代发布日，则封板时间建议为：5.15号（上周五）

3）封板动作：

• 务必要确保迭代每个需求代码都合并到 release 分支，找每个需求负责人确认代码提交记录
• 封板直接采用从 develop merge release 方式

3.3 SIT测试

1）负责人：测试

2）测试时间：迭代发布日前3天。比如 5.20（礼拜三）是迭代发布日，则SIT提测时间为 5.18 号

3）测试开展方式：

• 发SIT后进行冒烟测试,当天冒烟三次机会,冒烟不过,未达到封板条件。----当天复盘–评估发布风险,是否需要延期
• 按测试用例执行，并标记执行状态
• 每天汇报测试进度
• 更新jira任务剩余时间
• SIT环境US测试通过，对应的QA人员给产品创建验收task，等待产品验收
• 最晚迭代发布当天17点前必须通过 SIT 测试，不通过则延期（紧急发布、特殊发布不在这个要求之内）

4）Bug 反馈：记录到 Jira 需求的子任务下，并标记为 内部Bug

5）Bug 修复方式：基于 release 分支修改，测试验证通过后，merge 回 develop 分支

3.4 产品功能验证

负责人：产品经理

验证时间：至少提前迭代发布1天进行验收

验证结果：产品验证有问题，先找测试确认。 如果有问题，测试提 Bug

3.5 Demo 

1）无

3.5 产品发送关怀邮件

1）负责人：产品经理

2）邮件内容：参考《发布升级邮件模板》

3）发送时间：迭代发布当天

4）发送对象： PSCC  PMO，抄送给团队成员、研发中心负责人

3.6 迭代看板预演

1）发起人：迭代测试负责人

2）参与人员：Scrum Master、产品经理、研发、测试、运维

3）看板内容：参考《发布看板模板》

4）预演时间：迭代发布当天下午14:00 ~ 20:00 之间

4、发布

4.1 生产环境发布

1）负责人：运维

2）参与人：Scrum Master、产品经理、研发、测试

3）发布流程：按照事先建好的《迭代发布看板预演》流程进行发布

4）协作方式：钉钉会议

4.2 生产环境功能验证

1）负责人：迭代测试负责人

2）参与人：测试、产品经理

3）验证结果：

• 验证过程中发现3级及以下 Bug，不用处理，继续发布，同时将 Bug 记录到 Jira 里面，计划在后面的迭代中修复
• 验证过程发现2级及以上 Bug，给予1次修复机会
• 修复完成后还出现问题，取消当晚发布，发起日期第2天在定
• 原则上发布时间不超过凌晨2点，超过2点，还没有结束，视情况延期

4.3 生产环境冒烟

1）负责人：迭代测试负责人

2）参与人：测试

4.4 生产发布过程记录

4.5 紧急发布

1）SIT 最晚21点前结束

2）如果21点前没有结束，则

• 延期 （绝大部分场景）
• 必须发布：1）找简单可行的替代方案  2）继续当天的发布流程，直至成功

4.6 发布延期

1）项目发布延期后，产品经理当晚或者第二天早上发送告之邮件，抄送给：PMO、项目经理等。

五、复盘

1 复盘会议（会议）

1）会议目标：回顾本迭代过程中做的好的和做的不够好的地方。做的好的地方继续保持，形成持续优势。做的不好的地方，提出改进措施，在后续迭代中完善，总体目标是持续不断的提升迭代流程质量和效率
2）会议负责人：Scrum Master
3）会议参与人：产品经理、研发、测试
4）会议举行时间：迭代结束第1天
5）会议时长：不超过3个小时
6）会议开展方式：

• • 在 WIKI 上创建迭代复盘页面，每个人提前在该页面编辑本迭代做的好的地方和做的不好的地方，并署名
  • 先分析好的地方，给团队成员打气鼓励
  • 在分析做的不够好的地方，逐条分析，并提出改进措施
  • 对最终形成的改进措施提出 owner，并制定日期
  • 下个迭代复盘时，在来 review 上个迭代改进措施落地情况