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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 269|回复: 0

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

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

2 O+ r' U2 \$ c  V( }5 Q" q0 L
在一家互联网企业P,小强作为ScrumMaster带领一个Web开发团队。在第一个Sprint计划会议上,团队就Sprint要完成哪些需求与产品负责人达成了一致。在Sprint评审会议上,团队为产品负责人和利益干系人演示产品,大家也很满意。当产品负责人问,这些已经上线了吗?小强说:“刚到测试环境里完成功能测试,还没有做回归测试呢。此外,上线是运维组的事,不是我们的事。”

3 f: f  y6 {  J* t
这让产品负责人大跌眼镜:“我们需要的是上线啊,没上线怎么能算完成呢?还给我们演示(Demo),这是在浪费我们的时间啊?”
8 K. z0 [/ j" w
团队很诧异:“没人说一定要上线啊?此外,运维组也不是我们的人啊,什么时候上线不在我们的管辖范围啊。”
: w0 n* Q4 k. q" U) N
这种情况在许多初次尝试敏捷的团队很常见。对“完成的定义”,产品负责人与团队没有一致的理解,大家在各自没有说出来的理解下工作,当Sprint结束的时候,分歧暴露出来了。所以,在第一个Sprint开始之前,团队应该就“完成的定义”达成一致。那么应该定义什么样的DoD呢?

2 v) U, w$ `" a0 e7 _9 k# @
因为每个团队的DoD可能不一样,所以团队应依据自己产品和业务的特点,就DoD与产品负责人达成一致的意见。表6-3是一个DoD检查表示例,仅供参考。

7 B0 d1 r/ I# u+ [( J

, e6 m+ u: }/ @6 ?" V+ U
粘贴上传202201091734359050..png
表6-3DoD检查表: V( F& B) z6 E# A" u( o+ @) V
' }6 ?, R* `# O! Z! q/ h2 \  f7 N
在企业P,小强引导团队列出了如下“完成的定义”:
% a9 ~4 u9 @7 p# w  K8 `; Q9 [. z
  • 完成用户体验设计;
  • 通过需求设计评审;
  • 提交代码;
  • 通过代码评审;
  • 通过测试。
    % g8 D# I( t- D9 `" B
: F0 }, c: m6 R8 `
团队有人问:“这里通过的测试包括哪些?是集成测试、功能测试、回归测试,还是性能测试?”
$ f9 V9 Y; r- u9 z# L
大家商议,如果这些测试都包含,由于现在团队的自动化测试脚本很少,回归测试和性能测试无法在一个Sprint内完成。那么该怎么办呢?是不是可以将其移到下一个Sprint做呢?
( ?- |6 i. i' f/ \7 J- @
小强引导团队达成了如下共识。
, b$ u% Y9 P9 Q" z
回归测试和性能测试暂时不在“完成的定义”里,而是安排在产品发布前的一个Sprint里执行。但是团队从下一个Sprint起,引入自动化测试框架,对每个基本特性补充测试脚本,并着手调研性能测试工具。团队设定了目标:用4个Sprint的时间做完产品已有特性的回归测试和性能测试的脚本开发工作。
# C/ v4 k: _0 _8 X9 w( G# X( S; N
现实中这样的情况很常见,因为通常从0开始尝试敏捷的组织,其自动化测试基础都很薄弱。这种情况下,无法按照将产品发布给客户的标准来定义DoD。因此,DoD的范围有多大,本质上反映了组织的敏捷成熟度。DoD范围越靠近上线的最后一步,说明组织的敏捷成熟度越高。

0 N- A+ A# j1 b5 `4 ~
其实对于小强团队的情况,并没有完美答案。“完成的定义”也体现了组织敏捷转型的范围。产品发布到用户(或客户)手里需要做的所有工作都应该在“完成的定义”里,但是那些不在“完成的定义”里的工作是省不掉的,如果不是在Scrum团队范围里做,必然由另外一些部门或团队完成。那些承担Scrum团队未完成的工作的部门,称为“Undone部门”,这些部门正是组织敏捷转型未来要覆盖的目标。
, Y8 h8 U  L+ |! U+ ]1 n
对于当前Sprint做不完的工作,必须安排在下一个Sprint,或者是在发布前专门安排一段时间来完成,如图6-6所示。
- }5 t! P4 H! Q& L2 ~  \4 O9 l
粘贴上传202201091734539683..png

$ t0 M; A8 i& `) f; p2 n5 g
图6-6未完成的工作不断累积

: K* p& N: h) I
资料来源:《精益和敏捷开发大型应用实战》(PracticesforScalingLean&AgileDevelopment),2010年12月
7 K7 ^" _, z& Q; I$ h% F# G
每个Sprint不断累积的未完成的工作,不仅推迟了产品的反馈周期,蕴藏的缺陷也会不断增加。因此,未完成的工作越少越好。
7 t+ z( H, N" r4 x* z
在企业P,小强的团队在前几个Sprint没有做性能测试,而是在发布前的最后一个Sprint做的。但是团队发现了严重的性能问题,产品存在严重的内存泄露,需要对架构进行整改。而架构改动的影响范围巨大,导致前几个Sprint做的很多工作都需要返工。原定的产品上市时间也不得不推迟。

9 I& N# ^  O4 {: J
因此,团队要尽量将产品的质量反馈闭环控制在一个Sprint之内,不要推迟风险暴露的时间。
7 e3 Y) @) V7 [7 O1 E9 M

8 |$ B9 n4 K* j




上一篇:不要推迟敏捷研发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 19:14 , Processed in 0.101973 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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