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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 26|回复: 0

敏捷研发Sprint回顾的流程

[复制链接]
发表于 2022-1-9 18:08:14 | 显示全部楼层 |阅读模式
第一次召开Sprint回顾会议的团队,ScrumMaster要申明Sprint回顾会议的目的,避免大家对Sprint回顾会议有不同的理解。

$ Y3 H. S+ Q7 E7 O
很多ScrumMaster给团队讲解的关于Sprint回顾会议的目的如下。
/ r* f5 E7 C, t. l9 Y( j: d8 p( k# n7 r
ScrumMaster说:“回顾会议就是咱们常说的反思会,大家回顾一下这个Sprint运行过程中有什么问题。”

, Q1 ?- l9 S8 {* W$ v6 G# s
“反思”“回顾问题”,这样的讲解会让大家觉得回顾会议就是来吐槽说问题的。这会给回顾会议创造一个负面的场域。
& `/ |! O2 I* g4 {( k+ t+ y! @7 f
ScrumMaster说:“回顾会议,就是咱们对Sprint做个总结,花几分钟时间,每个人说一下,这个Sprint哪些好,哪些不好,完了我把会议纪要发给领导。”
" U- l4 t# y4 [7 N) m; v9 z, a
回顾会议不是总结会,更不是给领导汇报的总结。这样的讲解给大家的印象是回顾会议是为了形成报告给领导看。

, v5 z1 i8 b" }0 G
ScrumMaster应该这样给团队讲解Sprint回顾会议的目的。

/ b$ D! u6 A' B' x3 X. r( S
  • Sprint回顾是对这个Sprint过程中的团队、对外关系、过程和工具这几方面进行检视,但不限于这几方面。
  • 找出这个Sprint做得好的地方和需要改进的地方,决定改进措施,从而让我们团队持续改进。6 M3 b1 x$ G" Q- W; j8 p* a

    ; m1 b) ^+ y& A) \) \& O' g
3 a7 e8 V1 p& A5 {5 G
给团队明确了Sprint回顾会议的目的后,ScrumMaster就可以正式开始Sprint回顾会议了。

- e6 ~1 Q# y0 b% J( R
Sprint回顾会议与迭代的关系,以及Sprint回顾会议的步骤,如图6-12所示。
粘贴上传202201091804224829..png
图6-12回顾与迭代的关系及回顾步骤

! `' g8 b% g  q' y
资料来源:《敏捷回顾:团队从优秀到卓越之道》(AgileRetrospectives:MakingGoodTeamsGreat),2012年9月
: Y& X$ q0 Q; c3 a5 a: ~" N& e
Sprint回顾会议的步骤如下。
3 G4 f) `. ~: D' l! ^; x
第一步:开场
) c7 V- G7 e2 S2 N, m" \7 {2 F
ScrumMaster在Sprint回顾会议的开场,需要覆盖以下内容:
5 I& I; a5 E) n5 x7 u3 t$ i4 h
  • 介绍会议的目标和原则,以及回顾的工作协议;
  • 介绍会议议程;
  • 介绍回顾会以什么方式开展,回顾的范围是什么;
  • 最重要的是,要创造一个开诚布公的场域。3 E+ V6 `: q5 t6 Y7 }" g

    ) w  h# d+ A9 V

! Z9 }- _; r1 K: Z4 s6 w
ScrumMaster可以采取以下措施创造一个开放的场域。

$ ~) \1 U) l  e0 h# C- Z5 M
  • 选择一个令人轻松、愉悦的场地召开Sprint回顾会议。比如咖啡间,大家可以边喝着咖啡边聊。团队离开了拘束的办公场地,自然就放松起来,内心也更加开放。
  • 设计一个可以促进团队互动的座位布局。比如,让大家围坐一圈,面对面而坐,而不是端正整齐地坐在会议室里。也不要使用投影仪,如果ScrumMaster一本正经地翻PPT,那么他/她就成了会议的主导者,而这种主持风格并不能让每个人都积极参与。
    5 M. A0 g* t9 K9 S3 f  ]7 G

    # A1 Q1 {, @+ t! W. K- ~. A1 `
% d& R# a4 C& n1 m9 ~
ScrumMaster要向团队介绍诺姆·科尔特(NormKerth)提出的回顾的基本原则:“不管我们发现了什么,我们理解并且相信,每个同事在其已有的知识、技术、能力、资源以及当下所处的环境下,付出了最大的努力。”这样的原则可以为团队创造尊重、互信的气氛。关于回顾范围,ScrumMaster可以给团队一个思考框架,以帮助大家打开思路,比如团队的工作流程(并不局限于Scrum本身)、团队之间的协作(工具、工作环境、技术、对外协作)。

: K' G6 {; H1 G/ N$ C2 K
Sprint回顾会议的基本原则、议程、工作协议、回顾范围都可以被可视化到墙上,以营造一个开放的公共场域。

! B& A# i& x) H
第二步:收集数据

% q$ x/ a6 a3 g  g7 ?' O/ U
Sprint回顾会议收集的数据包含两方面:客观的度量数据以及Sprint里发生过的事件。
; R5 \: M" G5 b) K! l# N
对于客观的度量数据,需要ScrumMaster在会前将这个Sprint和这个版本的交付数据,以及任何需要团队关注的度量数据准备好,带到Sprint回顾会议上来。

! e5 X6 f' \' Z( J1 W; k  o3 u
Sprint回顾会议经常收集的数据有三个:团队的速率、Sprint燃尽图、版本燃尽图(详见第9章)。
+ A- t6 F! G* A0 x5 a3 d% v' m7 u2 o
ScrumMaster不是将数据贴到墙上就完了,而是要带领团队解读数据,让大家对团队的交付情况有共同的认识。比如,这个Sprint没有完成的目标;目前的速率低于最近的几个Sprint;按照现在的速率,从版本燃尽图上能看到我们将推迟1个月发布版本;这个Sprint的前3天,燃尽图上SprintBacklog没有一点燃尽,导致我们后来几天加班赶进度,最后到Sprint结束的时候也没有完成目标;等等。
+ Q. b% ]0 S9 h6 x4 k7 B5 {
整个团队就数据达成一致的认识后,再开始回忆和分析产生这样结果的原因。
$ K# ~& B5 s3 Q* T: p  p+ R; w
第三步:产生改进意见
* G8 i& \/ z2 I2 k0 V4 i4 s& z
ScrumMaster在会前准备好进行头脑风暴的框架,供大家沿着框架产生改进意见。框架有很多种,可以隔一段时间换一换,这样团队会对回顾保持新鲜感。
2 @' `- H6 N3 i
图6-13所示的回顾方法采用的是SSCC(Start-Stop-Continue-Chang)框架,分成如下四个部分。

' A# u3 }) R- l7 E/ Q9 P
  • Start:哪些实践应该开始尝试。
  • Stop:哪些问题或者实践应该立即停止。
  • Continue:哪些现有的实践应该继续保持。
  • Change:哪些情况应该改变。
    5 z) Z9 d6 R$ u: H
    0 T5 a( O7 u' U
- n) j' Z5 y4 c+ e9 O) D) U$ A/ H
粘贴上传202201091804414125..png

& x( `6 t# y6 D  U
图6-13SSCC框架示例
5 u6 B3 Y9 k; i, Y9 N* O4 L

0 n/ y1 n1 ^: i. c; u1 o7 M
为避免思绪被他人影响,每个提议用一张报事贴书写,然后放到相应的区域。不出意外的话,经过这一步,团队会形成很多改进建议。

; |3 ^' n+ e1 w6 n3 m7 l
但是也有意外的情况发生,团队写不出什么东西来。比如,一个6个人的团队,一共只写了3张报事贴,连框架都填不满。这种团队一般是那种被管理层和公司的体制压抑得太久,员工失去了主动反映问题的习惯,或者是对公司的改变彻底不抱有希望,所以就算有主意也懒得提了。这时候,ScrumMaster需要有耐心,让团队逐渐打开思路。刚开始的时候,ScrumMaster可以设置一个下限,比如,每个人最少写两条意见,时间可以适当长一点,给大家足够的思考时间。随着每个Sprint都有改进措施落地执行,团队会重拾希望,思路也会逐渐打开。

7 s4 F9 @/ G' t$ ]0 z5 d1 v
第四步:决定改进措施
2 f( ^, ~- E) V$ x; g( |" ?
面对大量的改进意见,团队是否该全部采纳呢?

% m7 Y5 R. P" m: Q- ^( B/ D
团队的精力和时间是有限的,即便大家对所有的意见都认同,也不能什么都做。Sprint回顾会议产生的改进意见需要放到Sprint中,团队边交付产品边改进。如果每个Sprint实施太多的改进,就会影响正常的产品交付工作。因此,团队必须对改进意见缩小范围。团队可以采用点投法,比如,每人有5个点的限额,投出你认为最需要做的几个改进事项。点投的时候,大家不要商量探讨,也要采用“沉默”投票法。

& _; q% u$ u3 w" m
每个人投完后,点数最多的1~3个事项将浮出水面,团队就这几个事项讨论具体的措施。
8 K& {8 d) B7 K, e
需要注意的是,改进措施分为两类。
; L5 z% b4 X4 W
  • 一类是新的实践、规范或者共识,不需要作为一个具体任务来落地实施。这类往往为工作协议。比如,点数最多的报事贴上写的是:“不要过多承诺Sprint目标。”团队注意依据自己的速率和可用的产能来装载SprintBacklog,不要过载即可。
  • 另一类是需要团队完成一个具体的任务。比如,点数第二多的报事贴上写的是:“测试效率太低,Sprint最后几天,测试工程师加班到半夜。”这样的改进需要团队来讨论如何提升测试效率。如果团队讨论的结果是开发测试自动化框架,那么就需要团队里有专人来认领这个任务。并且,这个任务也许需要长期进行,不是一个Sprint就可以搞定的。对于这种长期任务,团队需要将其分解到Sprint里来执行:下一个Sprint开始做什么,再下一个Sprint做什么。在每个Sprint结束的时候做检视,看看效果如何,下一个Sprint是否需要调整策略。4 d' N2 N6 A/ @, V9 a' S6 z

    0 `3 M+ M( N: W1 h/ G# _4 w* ^3 g' _
; b' S- J+ V# `" H: V
在下一个Sprint计划的时候,一定要记得,这种需要占用团队时间的改进措施也是SprintBacklog的一部分,需要占用团队产能。在任务板上,团队要将它与其他的SprintBacklog条目一起可视化,并跟踪它的进展。
4 c5 P  Z; d6 R3 W2 m7 `
第五步:收尾
; G, Q% \. w$ c
改进措施确定后,主持人需要做一些收尾的工作,包括:

* \  S' a& {. W, \" f
  • 对大家花时间共创一个美好的Sprint回顾表示感谢;
  • 拍照作为历史记录存档;
  • 将改进措施报事贴放到任务板上,用来跟踪进展;
  • 做一个关于回顾的回顾,以帮助团队在下次回顾中做得更好。- s" S3 S' Q& i7 m8 C- q

    1 ~& k9 k, H& x( \
6 \8 c$ r! M( ^, G% N/ _6 N; g
当然,不需要每次回顾都做关于回顾的回顾。在团队刚开始尝试Scrum方法的时候,花几分钟做关于回顾的回顾,有助于ScrumMaster听到团队的反馈,下次回顾会做得更好。
& M; ?& P" r# W- ?. S8 |, a# z
( i5 S7 w- ^" z6 `( ?" j5 y

; y8 k/ i0 z3 u3 M8 b! C+ a




上一篇:什么是敏捷研发Sprint回顾
下一篇:为什么要映射价值流
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 19:39 , Processed in 0.158749 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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