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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 568|回复: 0

敏捷研发Sprint计划的流程

[复制链接]
发表于 2022-1-9 17:42:41 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-1-9 17:45 编辑
% `/ D& [( F" [3 D- ]2 G0 m) Y! g+ j3 R) ?  z, m: `$ {" O' k  p
Sprint计划的输入有:
- B( r+ K1 v8 ?1 X% ^0 [3 g: m
  • 为Sprint准备高质量的产品Backlog;
  • 团队的历史速率;
  • 团队做SprintBacklog的可用时间;
  • 产品负责人提议的Sprint目标。
    $ l8 |+ p7 r6 m
7 h& U! e  X+ g' q9 s
Sprint计划的输出有:

9 w0 o, s6 N3 s, [+ K
  • 团队承诺的Sprint目标;
  • SprintBacklog。
    * n2 Y7 f, h% C) Z+ O, R
5 n( ]* M+ `0 w( m* o. j
Sprint计划的参与人有:

  Y( I" D% i. V1 l: B
  • 产品负责人;
  • 团队成员;
  • ScrumMaster。8 w1 y' I/ b0 q! `
0 _6 n' t1 \2 d8 P" n- z! _
Sprint计划的流程如图6-7所示。
粘贴上传202201091739341862..png

3 Z1 F" U! k; k' Z: j* {! P
图6-7Sprint计划的流程

! j. [* t$ u6 A3 a3 [  x5 v" I
高质量的输入是举行高效的Sprint计划会议的前提条件。
& H4 O* E. {% U: r. d# G1 s0 K
输入1:高质量的产品Backlog

3 r+ C. w  e3 [8 I& I% I+ A; Y) q
Tommy团队的产品负责人是David,他经常在每个Sprint计划会议开始后飞奔而来,手里捏着几个用户故事卡片。到会场后,David气喘呼呼地给团队讲用户故事。每个用户故事都让团队成员感到头大,因为每个用户故事听起来都很大,需求也很模糊。当团队问起每个用户故事的细节时,David一样感到头大,因为他完全没有想过细节,只是在会前花了10分钟匆匆忙忙地把想法用卡片写下来了。团队问起这个Sprint的目标,David说的目标让团队集体“晕倒”,因为那个目标大到至少三个月才能实现。
& P2 _. F( }- h6 K# p- F- K
可见,一份高质量的产品Backlog对Sprint计划是多么重要。很多团队为了解决这个问题梳理了“就绪的定义”(DefinitionofReady,简称DoR),定义了进入Sprint计划的前提条件。这个“就绪的定义”与“完成的定义”的作用类似,都是对用户故事的检查。两者的区别是:“完成的定义”定义了产品增量做到什么程度算是完成,而“就绪的定义”定义了产品Backlog可以进入Sprint计划的前提条件。

8 b1 M2 Y+ |' I6 x3 q. S- f5 `% f
Tommy引导团队制定了“就绪的定义”:

( O5 R5 Z7 k1 J( D
  • 已经打印或手写了用户故事;
  • 用户故事已经具备技术可行性;
  • 用户故事满足INVEST原则(好的用户故事需要遵循的原则,详见第8章);
  • 用户故事的优先级已经排好;
  • 用户故事已经具备参考的文档并被团队熟悉;
  • 用户故事卡片里含有对接受条件(AcceptanceCriteria)的描述;
  • 已经明确了依赖关系;
  • 已经估算了用户故事点数,且大小在一个Sprint完成。
    * J2 z" o1 h/ O) W" b! z: }
    4 i1 A, A  x$ C: L
8 ~- P0 m8 K. g$ [4 z: \. E
与“完成的定义”一样,每个团队需要依据自己的情况来定义“就绪的定义”。对于Tommy的团队来说,如果团队与产品负责人达成了“就绪的定义”这个规约,就可以约束产品负责人David的行为,督促他维护高质量的产品Backlog,从而给团队高质量的输入。

3 {& n, n# G6 K# I# {9 A
输入2:团队的速率
+ |9 o- E3 h/ K
下面这个案例在很多公司里都出现过。
' l6 M, y9 o& B
我刚进入Tommy的团队做教练的时候,Tommy说,他们团队已经做Scrum几个月了,感觉基本的知识都会了。我说:“那很好啊,那么你们的速率是多少呢?”Tommy一脸茫然:“速率是啥?”

. P$ j8 z) k) V  Y4 u/ t5 _( A
我问团队:“你们不知道速率是什么,那你们每个Sprint依据什么来决定要完成的工作量呢?”

: e: U3 v6 G9 e9 s
团队答:“就按照产品负责人给我们的SprintBacklog来做。”我问团队:“那么你们每个Sprint的完成情况如何呢?”

9 B: t0 M8 V' O2 J" I. ^. L  Q: O
团队答:“没注意过,好像都没有完成过啊!”

; Y2 @( f7 [+ \
速率在Sprint结束时由实际完成的所有用户故事点数之和来度量。速率的统计有两个作用。
: N; U2 X2 |, ^7 _! ^
  • 让团队对每个Sprint的产出量做到心里有数,这样能够做出靠谱的预测。
  • 速率是发布计划的重要输入。比如,你的产品当前版本的Backlog有150个故事点,而团队每个Sprint的平均速率是30个故事点,这样你就可以预测出这个版本大概需要5个Sprint来完成。$ l: R- h% l  @3 P) K- z

    - b- R; k! f2 A; z. q. u! {9 J

% M4 y1 V/ Q; a' t8 _
很多团队将没有完成的用户故事也统计在速率内。这是错误的统计方法。

9 a6 d. Z" }3 ^2 t9 x: h8 V8 A
一个用户故事要么是完成了,要么是没完成。即使是完成了99%,也是没有完成,没完成的用户故事没有价值,因此不该统计在速率里。

$ h% b! A* c. f, T: l3 d
Tommy团队在一个Sprint结束后,出现了这样的速率统计结果(如图6-8所示)。  

* Q# T8 q0 z5 D& h, |" C3 r' n5 @
粘贴上传202201091740014675..png
图6-8速率的计算

- G2 ?+ T( Y6 l' a" G9 _1 ?* B
团队质疑道:“最后那个故事卡,差一点就完成了,为什么速率统计不是2×90%,而是0?这样没有真实统计我们团队的速率啊!”

8 y9 A8 b3 |# f% ~5 P
其实,即使团队完成了用户故事的90%,但是如果没有达到“完成的定义”,就不具备完成的条件,在速率的计算中,99.9%=0。

% k1 ]0 u5 L, E* Q  T. {- e0 E1 E
累积了多个Sprint后,就可以计算历史Sprint的平均值,以及最大值和最小值,并将其作为下一个Sprint的参考(如图6-9所示)。

" V7 J8 ~8 ?/ m9 d3 C0 w+ l
粘贴上传202201091740288016..png
4 C8 v) C7 [2 y% l/ i! L3 T1 c" i
图6-9历史速率统计
0 p. H3 @. T; c0 I. |
图6-9的历史速率统计为团队做Sprint计划提供了量化参考,团队应依据此数据把握Sprint的装载量——在最大值和最小值之间,接近平均值。

9 }; V; b9 Z& _
输入3:团队做SprintBacklog的可用时间

6 ~: }8 `; z( E: t% E9 e
Tommy的团队在一个Sprint计划的时候出现了这样的情况:公司要求所有工程师在这个Sprint都参加计算机编程考试,考不过的同事会影响其职位晋升。为了考过,每个人得花点时间准备一下才行。于是团队疑惑,这个Sprint还能装载多少工作呢?

2 l8 A; i4 B" T3 f' x3 u
如果团队有6个人,Sprint长度为10天,每天按照8小时计算,那么经计算得出,该团队成员总共的工作时间是480小时。
" q! j. X+ o6 h* W: g/ \  H
对于已知的干扰事件,比如,每个人都要参加考试,在这个时间里团队没有做SprintBacklog的工作,因此需要去除掉。如果每个人考试需要3小时,准备考试需要大约半天的时间,于是,基本上一天的时间就被耗进去了。因此,这个Sprint的有效长度其实只有9天。
4 j0 v4 c" j: F
值得注意的是,每个人有效的工作时间并不是8小时,通常也就是5~6个小时。如果用6小时来算作有效工作时间,那么经计算得出,在这个Sprint中,该团队的有效工作时间是324小时。

* F! R; j  q7 Z: o
再看看这个Sprint里有没有人休假呢?小王休假2天,小李休半天,这样,团队的2.5天就需要被去除掉。经计算得出,可用的有效工作时间是309小时。最后,这个Sprint本身还有Scrum的基本活动:Sprint计划4小时,Sprint评审2小时,Sprint回顾2小时,Backlog梳理4小时。经计算得出,该团队可用的有效工作时间是237小时。
" Q( C) v) @5 z7 q, [
算到这的时候,团队说:“难怪不知道时间都去哪了!好了,本来以为480小时的工作时间现在只剩下一半了,这下可以了吧?再减就做不了什么了!”

6 [6 l3 P" C) [- C+ l
我问团队:“这237小时,你们确实都用来开发SprintBacklog吗?”团队答:“要是没有Bug的话,是的……可是我们在每个Sprint都会收到用户发现的线上Bug,以及从以前的Sprint测试中发现的Bug也会有一些遗留到下一个Sprint里,这些都要修改。”这才是真实的Scrum世界,在开发伟大特性的同时还要清扫垃圾。所谓的零缺陷在软件世界里只是个梦想。

1 {: `# m1 o  [; L  ]
我问团队:“那么你们每个Sprint大概花多少时间来处理这些Bug呢?解决线上Bug和遗留Bug的时间,与开发SprintBacklog所用时间的占比是多少呢?比如,是3∶7、2∶8,还是1∶9?”

0 i1 A& u4 ^- n  ]3 H: V
团队查看了历史数据,大概是4∶6的比例。

# c3 E* |3 o0 t% o: e1 T
因此,团队真正能够装载SprintBacklog的时间是142小时(237小时×60%)。

' L8 }$ u6 `3 z( ?% [: i) N
输入4:产品负责人提议的Sprint目标
  D4 B( q4 R! d
产品负责人在Sprint计划会议上提议一个Sprint目标。这个Sprint目标不是产品负责人单向压给团队的,而是需要与团队协商的。最终团队与产品负责人就目标达成共识,团队承诺的Sprint目标才是最终的目标。
. R3 s  L7 c! C* J. H9 \
1 _/ B' T  o* _2 i% q




上一篇:承诺敏捷研发Sprint目标
下一篇:开展敏捷研发Sprint计划会议的步骤
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

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

GMT+8, 2022-12-7 17:40 , Processed in 0.118635 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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