×

微信扫一扫,快捷登录!

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

标签: 暂无标签
当团队说产品待办事项列表条目以及产品增量“完成”的时候,每个人都应该理解“完成”意味着什么。

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

这让产品负责人大跌眼镜:“我们需要的是上线啊,没上线怎么能算完成呢?还给我们演示(Demo),这是在浪费我们的时间啊?”

团队很诧异:“没人说一定要上线啊?此外,运维组也不是我们的人啊,什么时候上线不在我们的管辖范围啊。”

这种情况在许多初次尝试敏捷的团队很常见。对“完成的定义”,产品负责人与团队没有一致的理解,大家在各自没有说出来的理解下工作,当Sprint结束的时候,分歧 出来了。所以,在第一个Sprint开始之前,团队应该就“完成的定义”达成一致。那么应该定义什么样的DoD呢?

因为每个团队的DoD可能不一样,所以团队应依据自己产品和业务的特点,就DoD与产品负责人达成一致的意见。表6-3是一个DoD检查表示例,仅供参考。


表6-3DoD检查表

在企业P,小强引导团队列出了如下“完成的定义”:

  • 完成用户体验设计;
  • 通过需求设计评审;
  • 提交代码;
  • 通过代码评审;
  • 通过测试。

团队有人问:“这里通过的测试包括哪些?是集成测试、功能测试、回归测试,还是性能测试?”

大家商议,如果这些测试都包含,由于现在团队的自动化测试脚本很少,回归测试和性能测试无法在一个Sprint内完成。那么该怎么办呢?是不是可以将其移到下一个Sprint做呢?

小强引导团队达成了如下共识。

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

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

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

对于当前Sprint做不完的工作,必须安排在下一个Sprint,或者是在发布前专门安排一段时间来完成,如图6-6所示。


图6-6未完成的工作不断累积

资料来源:《精益和敏捷开发大型应用实战》(PracticesforScalingLean&AgileDevelopment),2010年12月

每个Sprint不断累积的未完成的工作,不仅推迟了产品的反馈周期,蕴藏的缺陷也会不断增加。因此,未完成的工作越少越好。

在企业P,小强的团队在前几个Sprint没有做性能测试,而是在发布前的最后一个Sprint做的。但是团队发现了严重的性能问题,产品存在严重的内存泄露,需要对架构进行整改。而架构改动的影响范围巨大,导致前几个Sprint做的很多工作都需要返工。原定的产品上市时间也不得不推迟。

因此,团队要尽量将产品的质量反馈闭环控制在一个Sprint之内,不要推迟风险 的时间。


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:不要推迟敏捷研发Sprint
下一篇:做好启动第一个敏捷研发Sprint的准备工作
FYIRH

写了 198 篇文章,拥有财富 1122,被 1 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

返回顶部