小团队敏捷实践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