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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 134|回复: 0

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

[复制链接]
发表于 2022-1-9 17:36:09 | 显示全部楼层 |阅读模式
当团队说产品待办事项列表条目以及产品增量“完成”的时候,每个人都应该理解“完成”意味着什么。
2 R; z6 A6 d- k
在一家互联网企业P,小强作为ScrumMaster带领一个Web开发团队。在第一个Sprint计划会议上,团队就Sprint要完成哪些需求与产品负责人达成了一致。在Sprint评审会议上,团队为产品负责人和利益干系人演示产品,大家也很满意。当产品负责人问,这些已经上线了吗?小强说:“刚到测试环境里完成功能测试,还没有做回归测试呢。此外,上线是运维组的事,不是我们的事。”

) B3 m6 Z! t/ O0 M  M. g
这让产品负责人大跌眼镜:“我们需要的是上线啊,没上线怎么能算完成呢?还给我们演示(Demo),这是在浪费我们的时间啊?”
) D/ s+ {& K) q
团队很诧异:“没人说一定要上线啊?此外,运维组也不是我们的人啊,什么时候上线不在我们的管辖范围啊。”
. Z! z# h! d1 C' n+ a: m
这种情况在许多初次尝试敏捷的团队很常见。对“完成的定义”,产品负责人与团队没有一致的理解,大家在各自没有说出来的理解下工作,当Sprint结束的时候,分歧暴露出来了。所以,在第一个Sprint开始之前,团队应该就“完成的定义”达成一致。那么应该定义什么样的DoD呢?
! Y% A) T. U/ ]) L: H8 B
因为每个团队的DoD可能不一样,所以团队应依据自己产品和业务的特点,就DoD与产品负责人达成一致的意见。表6-3是一个DoD检查表示例,仅供参考。
+ z2 i7 ]9 L: x1 L

/ u, K% L! T  O
粘贴上传202201091734359050..png
表6-3DoD检查表$ Y8 v3 G% V6 r9 Z

8 T# O5 \/ ~9 j, J$ p
在企业P,小强引导团队列出了如下“完成的定义”:

9 ~" G" r4 J& f; o+ E) W
  • 完成用户体验设计;
  • 通过需求设计评审;
  • 提交代码;
  • 通过代码评审;
  • 通过测试。
    2 N6 Y  Q& Y* g  f3 e7 @% x$ e
  F3 v! U# U  G
团队有人问:“这里通过的测试包括哪些?是集成测试、功能测试、回归测试,还是性能测试?”
+ ?/ t; v2 b9 m8 i" k
大家商议,如果这些测试都包含,由于现在团队的自动化测试脚本很少,回归测试和性能测试无法在一个Sprint内完成。那么该怎么办呢?是不是可以将其移到下一个Sprint做呢?
) [. s9 N0 t! [6 N; Y& T( Y
小强引导团队达成了如下共识。

( G$ z: B1 \  I7 G7 Y" P8 w! `
回归测试和性能测试暂时不在“完成的定义”里,而是安排在产品发布前的一个Sprint里执行。但是团队从下一个Sprint起,引入自动化测试框架,对每个基本特性补充测试脚本,并着手调研性能测试工具。团队设定了目标:用4个Sprint的时间做完产品已有特性的回归测试和性能测试的脚本开发工作。

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

8 Q) g' k2 e- U8 h, }8 Q+ j, t
其实对于小强团队的情况,并没有完美答案。“完成的定义”也体现了组织敏捷转型的范围。产品发布到用户(或客户)手里需要做的所有工作都应该在“完成的定义”里,但是那些不在“完成的定义”里的工作是省不掉的,如果不是在Scrum团队范围里做,必然由另外一些部门或团队完成。那些承担Scrum团队未完成的工作的部门,称为“Undone部门”,这些部门正是组织敏捷转型未来要覆盖的目标。

+ v8 Z$ w9 @% s* {" g9 R% y
对于当前Sprint做不完的工作,必须安排在下一个Sprint,或者是在发布前专门安排一段时间来完成,如图6-6所示。
: }1 e& z1 g! e! o! S
粘贴上传202201091734539683..png

" c8 c' u, K3 }, }) T! p
图6-6未完成的工作不断累积

4 e$ K7 F1 t/ V) g
资料来源:《精益和敏捷开发大型应用实战》(PracticesforScalingLean&AgileDevelopment),2010年12月
* ]! q+ e# q7 U$ h2 p
每个Sprint不断累积的未完成的工作,不仅推迟了产品的反馈周期,蕴藏的缺陷也会不断增加。因此,未完成的工作越少越好。

5 G/ \. y# _) C. H" k
在企业P,小强的团队在前几个Sprint没有做性能测试,而是在发布前的最后一个Sprint做的。但是团队发现了严重的性能问题,产品存在严重的内存泄露,需要对架构进行整改。而架构改动的影响范围巨大,导致前几个Sprint做的很多工作都需要返工。原定的产品上市时间也不得不推迟。
/ s+ G' ]+ P1 Z  P8 U
因此,团队要尽量将产品的质量反馈闭环控制在一个Sprint之内,不要推迟风险暴露的时间。
8 P1 m: R2 B4 \9 r9 Z# V
& u+ J. Z0 c6 O5 u* {




上一篇:不要推迟敏捷研发Sprint
下一篇:做好启动第一个敏捷研发Sprint的准备工作
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

GMT+8, 2022-7-5 15:33 , Processed in 0.100830 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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