1.0阶段

1.0

一切从需求开始

在「1.0」阶段实施和使用过程中，我们发现了很多实际问题，所以整体对敏捷流程进行了一些改进和升级，以适应团队迭代的变化。

需求源分类

由于提出需求渠道比较多，为了便于管理，我们对需求源进行了分类，具体分类如下：

需求代号	描述	迭代版本代号
Feature	基于产品价值的自主产品迭代	feature/sprintXX，如：feature/sprint40
CS	客户成功经理反馈的用户侧需求	cs/yyyyMMdd，如：cs/20210713
Tech	研发内部发起的技术改进或重构类需求	tech/模块或重构名，如：tech/mtms、tech/res
Hotfix	故障流程触发的线上问题修复需求	hotfix/yyyyMMdd，如：hotfix/20210713

目前，我们团队开启Sprint的需求类型为：feature，其余类型不触发Sprint。

迭代流程

整体迭代分为6个阶段，分别是

1. PRD Review：产品需求评审、用户故事评审
2. Estimate：概要设计、工作量估算（扑克牌）
3. Sprint Start：Jira创建Sprint、版本号、登记用户故事、创建甘特图
4. Sprint In Progress：迭代进行中，每天10点站会同步进度
5. Deploy：PM、UI验收、版本发布
6. Sprint Review：迭代复盘

1.PRD Review

PRD Review流程

参与者

• 推动：PM
• 参与：RD FE QA UI

输入信息

• 本次迭代的PRD。（路径「PM团队」→「产品需求」→「2021产品需求」→「产品自主迭代」→「某次迭代的PRD页面」）

输出信息

• 蓝湖中本次迭代原型讨论终稿
• 用户故事讨论终稿（路径「钉钉云盘」→「3-研发部」→「用户故事拆解」→「SprintXX」→「文件夹下的用户故事文件」）

PRD

钉钉中的用户故事

2.Estimate

估算方式采用的是「规划扑克估算法」。一种基于共识的估算方式（游戏），主要用于估算Scrum迭代中的开发任务的工作量问题，通过团队的共同的评估方式，使得偏差变得相对较小。

什么是规划扑克

规划扑克使用Fibonacci序列作为Story Point。Fibonacci序列是13世纪引入的数学系列数字，用于解释自然的某些形成方面，例如树的分支。通过将前两个数字相加来生成序列，以获得序列中的下一个值：0,1/2,1,2,3,5,8,13,20等。出于敏捷估计的目的，一些数字已经改变，导致以下系列：1，2，3，5，8，13，20，40，100

扑克说明（点数约定：1 Story Point = 1 人/天）

牌	解释
0	不需要工作量
无穷	任务量大
?	无法估计
一杯咖啡	不足0.5
其他	按照字面意思理解点数

估算流程

参与者

• 推动：PM
• 参与：RD FE QA

输入信息

• 用户故事

输出信息

• 用户故事的估算和优先级

操作步骤（一般2轮估算基本可以达成共识）

• PM进行用户故事描述
• RD / FE 的团队成员，通过面朝下的方式打出编号卡（斐波那契值：1，2，3，5，8，13，20，40）
• 卡片同时亮出
• 解释估算偏差，并讨论
• 估算共识达成

估算记录表

估算完成后，我们把估算的结果填写到钉盘中的故事列表中，并确定故事优先级

3.Sprint Start

Sprint创建&开启流程

参与者

• 推动：Scrum Master（QA）
• 参与：RD FE QA

输入信息

• 用户故事 & 估算结果

输出信息

• Sprint & Gantt

创建Epic

创建Story

Sprint面板

Gantt

4.Sprint In Progress

日常流程

参与者

• 推动：Scrum Master（QA）
• 参与：RD FE QA

输入信息

• 站会同步

输出信息

• 用户故事更新

5.Deploy

验收&发布流程

参与者

• 推动：Scrum Master（QA）
• 参与：PM UI RD FE

输入信息

• UAT环境

输出信息

• 迭代发布
• Sprint Done

6.Sprint Review

Review流程

参与者

• 推动：QA
• 参与：PM UI RD FE

输入信息

• 测试报告

输出信息

• 复盘结果

测试报告

总结

以上就是目前研发团队的2.0版本的敏捷迭代流程，后面需要重点改进的还是，如何引入CI、自动化测试等等手段，进一步提升测试的效率，从而更快的反馈出问题。