Bob Jiang | 敏捷教练 | Scrum Master

敏捷培训 | Scrum培训 | 组织创新

再次强调完成的定义(DoD)

Posted at — May 18, 2020 阅读

之前我写过一篇文章,关于敏捷坑人系列不清晰的完成,在这篇文章当中,描述了完整的定义和验收标准之间的区别,但是最近的课程当中依然有不少小伙伴在提问关于完成的定义,那今天的来说一下,为什么我们要设定完成的定义(即其重要性)

完成?!

在工作当中往往我们会说这个事情我完成了。当我们说完成的时候,每个人对于这个完成是有不同的定义。比如PO认为完成是需要包含完成编码,提交到代码库,完成单元测试,完成集成测试,完成功能测试,等等一系列的测试。

而开发小伙伴可能认为完成只包含代码,以及在自己的电脑上测试,没有问题就算是完成了。

那这两个完成之间是有很大的一个差距,而这个往往会造成大家对于完成的理解误区,及同时也会造成沟通上的冲突。

完成的定义 Definition of Done

在这个背景下,团队需要对于完成有一个统一的认识。这个完成会包含很多不同的层面及不同的步骤。

举例说,如果说一个产品功能完成了会包含什么?如果开发完成了会包括什么,如果测试完成会包括什么,这是不同的层面。但是在Scrum指南中完成默认是指的产品完成。

完成的定义就像是一道门槛

团队一起设好了门槛,能跳过去的功能(PBI)就是完成了,跳不过去的,就是没完成。没有完成一半或者完成90%这样的概念。

所以对于这道门槛我们要设多高,这个是看团队对于自己的要求是多少,以及团队对质量的要求是多少,这是非常重要的一一个概念

验收标准 Acceptance Criteria (AC)

验收标准更像是PBI(功能)自身的一部分,或者用户故事的一部分。验收标准和用户故事是完整的整体,且不可拆分的。

也就是我们在梳理用户故事的时候,要同时梳理出这个用户故事的验收标准。

举个例子,比如登录功能,如何这个登录功能才算是完成呢?最简单的用户名密码正确就登录成功,用户名密码错误返回错误原因。这是最简单的两个验收标准。这两个验收标准就是用户故事的一部分。

总结

完成的定义和验收标准相同点

完成的定义和验收标准不同点

关于用户故事和产品待办列表,在我之前的博客当中也已经有详细描述,大家可以参考。