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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 15|回复: 0

敏捷研发DoD:怎样才算“完成”

[复制链接]
发表于 2022-1-9 17:36:09 | 显示全部楼层 |阅读模式
当团队说产品待办事项列表条目以及产品增量“完成”的时候,每个人都应该理解“完成”意味着什么。

  X/ `8 T: v4 e' l; B) z
在一家互联网企业P,小强作为ScrumMaster带领一个Web开发团队。在第一个Sprint计划会议上,团队就Sprint要完成哪些需求与产品负责人达成了一致。在Sprint评审会议上,团队为产品负责人和利益干系人演示产品,大家也很满意。当产品负责人问,这些已经上线了吗?小强说:“刚到测试环境里完成功能测试,还没有做回归测试呢。此外,上线是运维组的事,不是我们的事。”
, x# a: Z# G! {
这让产品负责人大跌眼镜:“我们需要的是上线啊,没上线怎么能算完成呢?还给我们演示(Demo),这是在浪费我们的时间啊?”
& L  D& g& ], w+ u) j3 h4 i
团队很诧异:“没人说一定要上线啊?此外,运维组也不是我们的人啊,什么时候上线不在我们的管辖范围啊。”
( H; R3 o/ x7 l8 k* y/ }
这种情况在许多初次尝试敏捷的团队很常见。对“完成的定义”,产品负责人与团队没有一致的理解,大家在各自没有说出来的理解下工作,当Sprint结束的时候,分歧暴露出来了。所以,在第一个Sprint开始之前,团队应该就“完成的定义”达成一致。那么应该定义什么样的DoD呢?
* e. Q7 R1 n, J7 v' g! Z2 w
因为每个团队的DoD可能不一样,所以团队应依据自己产品和业务的特点,就DoD与产品负责人达成一致的意见。表6-3是一个DoD检查表示例,仅供参考。

0 Z/ b5 l% c% R. V1 i* q+ ?
; a! y$ r/ E( g5 p, c, @" Z
粘贴上传202201091734359050..png
表6-3DoD检查表
& ]" ?4 O6 f# |; q. i  r/ c
6 o7 C  w3 a! x1 d" Y
在企业P,小强引导团队列出了如下“完成的定义”:

- G% a9 }5 M8 Y6 @( N: e1 L. ~# s* p
  • 完成用户体验设计;
  • 通过需求设计评审;
  • 提交代码;
  • 通过代码评审;
  • 通过测试。2 J, z- c& G+ J# d
5 {% ]. q; k; c; {% U4 Y
团队有人问:“这里通过的测试包括哪些?是集成测试、功能测试、回归测试,还是性能测试?”

) k9 y0 I8 w! g: z' q8 O4 ~# V
大家商议,如果这些测试都包含,由于现在团队的自动化测试脚本很少,回归测试和性能测试无法在一个Sprint内完成。那么该怎么办呢?是不是可以将其移到下一个Sprint做呢?
! w+ B$ a- i0 |& y
小强引导团队达成了如下共识。
! z- c$ U3 |+ w1 s$ s1 g
回归测试和性能测试暂时不在“完成的定义”里,而是安排在产品发布前的一个Sprint里执行。但是团队从下一个Sprint起,引入自动化测试框架,对每个基本特性补充测试脚本,并着手调研性能测试工具。团队设定了目标:用4个Sprint的时间做完产品已有特性的回归测试和性能测试的脚本开发工作。

0 p  @* y/ K& S7 \4 u$ G6 V
现实中这样的情况很常见,因为通常从0开始尝试敏捷的组织,其自动化测试基础都很薄弱。这种情况下,无法按照将产品发布给客户的标准来定义DoD。因此,DoD的范围有多大,本质上反映了组织的敏捷成熟度。DoD范围越靠近上线的最后一步,说明组织的敏捷成熟度越高。

8 I3 V7 _/ b. z. k. m0 T
其实对于小强团队的情况,并没有完美答案。“完成的定义”也体现了组织敏捷转型的范围。产品发布到用户(或客户)手里需要做的所有工作都应该在“完成的定义”里,但是那些不在“完成的定义”里的工作是省不掉的,如果不是在Scrum团队范围里做,必然由另外一些部门或团队完成。那些承担Scrum团队未完成的工作的部门,称为“Undone部门”,这些部门正是组织敏捷转型未来要覆盖的目标。
: Z6 @+ w# D; u5 g% `6 P
对于当前Sprint做不完的工作,必须安排在下一个Sprint,或者是在发布前专门安排一段时间来完成,如图6-6所示。
& b( H/ ~7 a( Y3 U6 ^9 u
粘贴上传202201091734539683..png

0 |5 J$ o( w3 h6 ^+ f3 n7 d
图6-6未完成的工作不断累积

1 t: t7 ]- J2 [1 Z1 r& x
资料来源:《精益和敏捷开发大型应用实战》(PracticesforScalingLean&AgileDevelopment),2010年12月

+ s$ s5 K1 x' c8 N1 ?
每个Sprint不断累积的未完成的工作,不仅推迟了产品的反馈周期,蕴藏的缺陷也会不断增加。因此,未完成的工作越少越好。
# \0 |; v% L" W7 @' K% x, u4 G8 a9 M
在企业P,小强的团队在前几个Sprint没有做性能测试,而是在发布前的最后一个Sprint做的。但是团队发现了严重的性能问题,产品存在严重的内存泄露,需要对架构进行整改。而架构改动的影响范围巨大,导致前几个Sprint做的很多工作都需要返工。原定的产品上市时间也不得不推迟。

/ }. w" M% r6 h' v" w
因此,团队要尽量将产品的质量反馈闭环控制在一个Sprint之内,不要推迟风险暴露的时间。
. ?+ V. }4 b, @$ p

8 P  X( a8 R0 V( `




上一篇:不要推迟敏捷研发Sprint
下一篇:做好启动第一个敏捷研发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 20:04 , Processed in 0.102269 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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