敏捷迭代为什么升级
团队在敏捷迭代实施的过程中，遇到了各种问题，在这个过程中，也发现了很多很好的方法论。所以，近期根据团队迭代的实际情况，做了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个阶段，分别是
- PRD Review：产品需求评审、用户故事评审
- Estimate：概要设计、工作量估算（扑克牌）
- Sprint Start：Jira创建Sprint、版本号、登记用户故事、创建甘特图
- Sprint In Progress：迭代进行中，每天10点站会同步进度
- Deploy：PM、UI验收、版本发布
- 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、自动化测试等等手段，进一步提升测试的效率，从而更快的反馈出问题。
