小团队敏捷实践2.0
敏捷迭代为什么升级
团队在敏捷迭代实施的过程中，遇到了各种问题，在这个过程中，也发现了很多很好的方法论。所以，近期根据团队迭代的实际情况，做了2.0的迭代流程升级。团队使用的工具，在很早的文章里面有介绍，请查看：《小团队如何落地敏捷开发》。
一切从需求开始
需求源分类
由于提出需求渠道比较多，为了便于管理，我们对需求源进行了分类，具体分类如下：
目前，我们团队开启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 人/天）
估算流程
参与者
- 推动：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、自动化测试等等手段，进一步提升测试的效率，从而更快的反馈出问题。原文链接：https://mp.weixin.qq.com/s/tIeU4o0Q3wiJuFtbUX-qHQ
