请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 225|回复: 0

开展敏捷研发Sprint计划会议的步骤

[复制链接]
发表于 2022-1-9 17:49:09 | 显示全部楼层 |阅读模式
第一步:产品负责人陈述Sprint目标,讲用户故事

' q. g" }# Z: }
产品负责人讲解他/她提议的Sprint目标,以及他/她希望被纳入Sprint的用户故事。如果其中有些用户故事在上一个Sprint的Backlog梳理活动中已经讲解过,那么在这个步骤中可以省略,产品负责人只需要给团队明确这个Sprint要做哪些用户故事即可。
( B% K2 n$ O  o1 i+ p1 ?
很多产品负责人不知道怎么讲用户故事。有的产品负责人把用户故事的标题念一遍,或者干脆把故事卡摊到桌上说:“就这些,你们看看有什么问题。”
* s: o) i% e  ?/ i4 ], m
产品负责人要讲清楚用户故事,需要讲以下内容。

4 _. I  T7 X5 O& b: K2 s
  • Who:用户是什么角色。
  • What:完成什么活动。
  • Why:达成什么目的。
  • How:具体怎么做。如果有业务流程图、线框图、参考规范或标准等,也需要给团队介绍。
  • 验收条件:做到什么程度算完成。
    8 c! [" \0 L& n

, O  ?6 n) w, O
第二步:产品负责人澄清产品需求

- f( D. V. H$ s( p3 l* y
产品负责人就Sprint目标以及每个用户故事做现场解答,确保团队每个人对用户故事都有一致的理解。在这个过程中,一般会对用户故事进行细化,有可能还会拆分出新的用户故事。
! d! k' |0 {9 E" X9 g
第三步:团队估算完成用户故事所需时间
; `5 A% m& x5 o' r/ p: b
在估算过程中,产品负责人会发现,有的故事貌似大家都有共同的理解,但其实没有。因此,产品负责人要对用户故事做进一步澄清,而大的故事会继续拆分,需要的话会重新估算时间。
; H; g  X- V4 k; A6 _
第四步:团队选取SprintBacklog,调整Sprint目标
' y, M8 v$ }( }7 I% E* Y
团队依据历史Sprint速率,以及对完成用户故事所需时间的估算,按照产品Backlog的优先级,选取用户故事,作为这个Sprint的Backlog。
; H% K# M" t4 e4 |& c
依据选取的SprintBacklog,团队审视产品负责人提议的Sprint目标是否可以达成。如果SprintBacklog的范围超过了Sprint目标,团队应该与产品负责人协商,是否应该调整Sprint目标。
6 z( C  w. w( c3 w
在Tommy团队的一个Sprint计划会议上,产品负责人David提议的Sprint目标是:用户能够完成下订单和支付的采购过程。

2 w) }7 ~. Y& j7 Q; X7 g
团队估算SprintBacklog后发现,与支付有关的用户故事没有富余时间,不能放到这个Sprint里做。于是,团队与产品负责人商议,将Sprint目标更改为:用户完成下单过程,支持货到付款,下个Sprint再做支付的流程。

$ q* C; |2 q; H& @8 W
第五步:拆分任务
7 `9 h& r' h4 d  \) \
接下来,团队就每一个用户故事拆分出具休的任务。每个任务的粒度争取在一天之内。

8 M/ k6 D: F1 a; `7 ^' d
Tommy的团队在这个Sprint计划中有这样一个用户故事:购物者想把一个商品加到购物车里。
) q, Q2 z' g9 P5 @/ n
团队讨论,为了完成这个用户故事,需要完成以下任务。
; v! A4 K  x2 l! h7 u: ~) F9 b
  • 修改后台数据库,预计5小时。
  • 添加购物车UX设计,预计2小时。
  • 前台页面JS开发,预计4小时。
  • 写自动化验收测试脚本,预计3小时。
  • 更新购物者帮助说明,预计2小时。3 h: B2 K5 S# E2 l) H
& |1 ~2 w5 x: {, m% S* h
团队用卡片将每个用户故事和任务写下来,为方便互动,大家围着卡片讨论。卡片展开后如图6-10所示。
粘贴上传202201091746238664..png

4 p0 ~+ W1 C: p; z
图6-10Sprint计划任务拆分示例图

, {5 N! A+ _7 D, w: s/ g

8 j1 H0 {  \9 f. S
新的Scrum团队一开始拆分出的任务通常都比较大,比如10天、8天、5天的任务。而任务最好在一天之内完成,因为任务越大,其中蕴藏的风险可能越多。团队在探讨如何把任务拆小的过程中,会暴露出实现用户故事的风险。

. ^# ~: T4 {! {4 w, Z7 [" v/ \
当团队形成将任务拆小的习惯后,又容易走向另一个极端:经常出现1小时或半小时的任务。比如,开发弹出消息对话框需要0.5小时。
+ _0 q2 B" W" j  ~6 v
如果有一堆过小粒度的任务,会额外增加管理成本,也是不提倡的。一天之内的粒度是最合适的。

! i  A% g+ N5 n" a& R
第六步:判断SprintBacklog是否达到产能上限
% l4 T# T6 f# z. A  S$ A
Tommy团队在这个Sprint估算的任务工时之和为150小时(如图6-10所示),而在Sprint计划前的工作(输入3:团队做SprintBacklog的可用时间)中,团队做SprintBacklog的可用时间只有142小时,Tommy问大家:“这可怎么办呢?”

0 }+ L8 g) |1 O5 s  ]1 `# \
团队说:“才超出了8个小时,没准能做完。”
3 R" y, b6 o2 U" U
这个时候,作为ScrumMaster的Tommy问道:“大家确定可以吗?真的愿意挑战一下吗?为什么觉得可以做完呢?”

0 A. c) l: P  a2 v% d
不管团队是否愿意挑战,我们应该尊重团队的决定。如果团队不想挑战,那么需要从Backlog里取下一个或几个用户故事。

8 v7 r1 R1 `+ X: I8 v
第七步:承诺目标

1 u: m) E9 X$ ^$ A/ I/ i
终于到了最后一步。在Sprint计划结束前,ScrumMaster需要问大家对这个Sprint是否有信心,从而确保每个成员为达成Sprint目标做出承诺。
" \5 q& V; i% `1 N3 [7 R4 X/ j; k
很多团队都省略了承诺目标这一步,ScrumMaster也没有确认大家的信心和承诺就结束了Sprint计划会议,团队直接进入开发。从大部分工程师的习惯来看,即使有人没有信心也不会说的,因为这会显得整个团队好像就他一个人没有信心。而往往他看到的风险可能是其他人没有想到的。
/ C3 u7 I$ m2 G" T, {
一种高效征求意见的方法是用五指拳(FistofFive)投票,如图6-11所示。

! \3 k) _/ K2 y
粘贴上传202201091746403181..png

3 O* }* {$ j4 D( j9 K! Q
图6-11五指拳投
五指拳投票法的具体含义如下。

3 Q- @4 @+ q8 m5 y) v- |
  • 5个手指:完全有信心,闭着眼睛都可以达到!
  • 4个手指:有信心,不出意外的话可以达到!
  • 3个手指:有点信心,但需要努力!
  • 2个手指:没有信心,很难达到!
  • 1个手指:不可能实现,我宁愿回家睡觉!4 L4 A& \2 m$ c/ B
. p2 K3 W. o* J* W5 Z$ [' t
如果团队有人举了2根或1根手指,ScrumMaster需要请他/她讲述自己的顾虑,困难在哪里。如果团队认可他/她提出的困难会影响Sprint目标的达成,则应该调整Sprint目标。

! R+ j% J- q9 y  w( ]: |5 Y
Sprint计划结束的时候,不仅团队承诺了Sprint目标,而且SprintBacklog也得到了团队的承诺。团队可以将SprintBacklog的用户故事和拆分的任务卡放到任务板上,作为Sprint第一天启动的站会输入。
! N, M3 k) H3 P) y9 [# U

# ]$ i5 [% E1 R6 ^0 s6 i# T: o, z( _




上一篇:敏捷研发Sprint计划的流程
下一篇:敏捷研发每日站会的常见误区
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2022-8-17 08:23 , Processed in 0.096358 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表