敏捷迭代为什么升级

---

团队在敏捷迭代实施的过程中，遇到了各种问题，在这个过程中，也发现了很多很好的方法论。所以，近期根据团队迭代的实际情况，做了2.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

输入信息

• Confluence中的本次迭代的PRD

输出信息

• 蓝湖中本次迭代原型讨论终稿
• 用户故事讨论终稿

Confluence中的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

输入信息

• 用户故事 & 估算结果

输出信息

• Jira内的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、自动化测试等等手段，进一步提升测试的效率，从而更快的反馈出问题。