小团队敏捷实践2.0


敏捷迭代为什么升级

团队在敏捷迭代实施的过程中,遇到了各种问题,在这个过程中,也发现了很多很好的方法论。所以,近期根据团队迭代的实际情况,做了2.0的迭代流程升级。

团队使用的工具,在很早的文章里面有介绍,请查看:《小团队如何落地敏捷开发》。

一切从需求开始

需求源分类

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

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

迭代流程

2.png

整体迭代分为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流程
3.png

参与者
  • 推动:PM
  • 参与:RD FE QA UI


输入信息
  • Confluence中的本次迭代的PRD


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


Confluence中的PRD:
4.jpeg

钉钉中的用户故事:
5.jpeg

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
6.png

扑克说明(点数约定:1 Story Point = 1 人/天)
B2.png

估算流程
7.png

参与者
  • 推动:PM
  • 参与:RD FE QA


输入信息
  • 用户故事


输出信息
  • 用户故事的估算和优先级


操作步骤(一般2轮估算基本可以达成共识):
  • PM进行用户故事描述
  • RD / FE 的团队成员,通过面朝下的方式打出编号卡(斐波那契值:1,2,3,5,8,13,20,40)
  • 卡片同时亮出
  • 解释估算偏差,并讨论
  • 估算共识达成


估算记录表:
8.png

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

3、Sprint Start

Sprint创建&开启流程
9.png

参与者
  • 推动:Scrum Master(QA)
  • 参与:RD FE QA


输入信息
  • 用户故事 & 估算结果


输出信息
  • Jira内的Sprint & Gantt


创建Epic:
10.jpeg

创建Story:
11.jpeg

12.jpeg

Sprint面板:
13.jpeg

Gantt:
14.jpeg

4、Sprint In Progress

日常流程
15.png

参与者
  • 推动:Scrum Master(QA)
  • 参与:RD FE QA


输入信息
  • 站会同步


输出信息
  • 用户故事更新


5、Deploy

验收&发布流程
16.png

参与者
  • 推动:Scrum Master(QA)
  • 参与:PM UI RD FE


输入信息
  • UAT环境


输出信息
  • 迭代发布
  • Sprint Done


6、Sprint Review

Review流程
17.png

参与者
  • 推动:QA
  • 参与:PM UI RD FE


输入信息
  • 测试报告


输出信息
  • 复盘结果


测试报告:
18.jpeg

19.jpeg

20.jpeg

21.jpeg

总结

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

原文链接:https://mp.weixin.qq.com/s/tIeU4o0Q3wiJuFtbUX-qHQ

0 个评论

要回复文章请先登录注册