如何定义开发完成?(Definition of Done)

简介: 最近在拜读郑晔的10x程序员工作法,收益良多,文中提出一个概念叫DoD(Definition of Done)给我的感触颇深。这让我联想到实际工作过程中,经常遇到的扯皮、争吵等各种场景,其实就和这个DoD分不开。

最近在拜读晔的10x程序员工作法,收益良多,文中提出一个概念叫DoD(Definition of Done)给我的感触颇深。这让我联想到实际工作过程中,经常遇到的扯皮、争吵等各种场景,其实就和这个DoD分不开。

一、场景描述

  郑晔在文中描述了这样一种现象,相信有开发经历的人多少有同感:

老张:这有一个任务需要完成,你看一下。
小李:这个不难,两天就能做完,两天以后就能上线。

  两天以后,老张又来到小李的身边验收工作:

老张:怎么样,做完了吗?今天能上线吗?
小李:我的代码写完了。
老张:测试人员测过了吗?
小李:还没有。
老张:那今天能测完吗?
小李:那我就不知道了。
老张:什么?我可是答应了业务的人,今天一定要上线的!

  两天以后,老张又来检查工作。

老张:这个功能开发完了吗?
小李:写完了,你看我给你演示一下。

  小李熟练地演示了这个新写好的功能,这次老张很满意:

老张:做得不错。单元测试都写了吧?
小李:啊?还要写单元测试吗?
老张:要不为啥给你两天的时间?

  很明显,老张有些愤怒,貌似总在挑刺,而小李也没有偷懒、有些委屈。于是,老张、小李和测试人员一起度过了一个不眠之夜。

二、理解的代沟

  根据上面的场景,我画了两幅小李和老张的思考图,看下两者的代沟在哪儿,如下图所示。

  很显然两者对完成的定义各不相同。对开发人员小李来说,完成容易理解为编码完成;而不去考虑代码测试和线上测试;对技术主管老张来说,完成的理解可能会更多一些,包括编码,测试,代码规范,审查,上线等等,有些老张脑子里的东西更多,比如下图所示:

  为什么会有上面的差异?从立场来看,小李汇报的对象只有老张,而老张要协作的对象可能有产品经理、老板、总监、小李们。小李是从个人层面,关注的是一个点,老张是从团队层面,关注的是一个面。

  各自定义差可能反应了一个信号,就是团队成员整体上缺乏职业素养,那么这个团队就危险了。从小李的角度无论怎么努力,都不可能满足老张的需求,从老张的角度总觉得小李偷懒,导致团队之间老是摩擦、挑刺,最后小李干的不爽了,老张也觉得小李孺子不可教,最后事没有做好,人跑了。

  接下来就要回到作者提出的DoD概念(完成的定义),从这个概念的名字便不难看出,它就是为了解决软件开发中常见的“完成”问题而生的。

三、完成的定义

  这里的DoD在郑晔看来包含三个层次的含义:

  • DoD 是一个清单,清单是由一个个的检查项组成的。
  • DoD 的检查项应该是实际可检查的。
  • DoD 是团队成员间彼此汇报的一种机制。

  借助这三个含义,我模拟登录功能列了表格:

 

  以上是站在测试用例的角度来写,一个简单的登录就可以包含18个开发功能点,做好登录并没有那么简单,这也就难怪小李和老张总是意见不一致。如果摊开这份清单用来验收登录功能的完整性,我相信小李和老张彼此都不会有什么意见。

  但是这里有一个问题,就是老张根本不会去做这份清单!小李也没有这种意识,那谁来拟定?也许你会说引入中间层,就是测试人员来拟定,假设你们团队没有测试人员呢?

  事情总是没有表面看起来的那么简单。这里再设计一份简化的验收清单

 

  如此简化的功能也能多少避免小李和老张的鸿沟了吧?那么又回到前面的问题,谁来制作这份清单?

  我个人的意见是小李来做,因为小李的势能没有老张高,那就多增加自己的动能了,显示自己做事的能力,同时也做一个同事眼中的好伙伴,领导眼中的好同事。等小李变成老李了,遇到小张也是小张来做这事。

四、DoD是一种思维方式

  郑晔在最后又补充道:

至此,我们只是从软件开发团队内部协作的角度来谈 DoD。但实际上,它不仅局限在团队内部协作上,如果你可以放开思路,会发现 DoD 的思维在工作中用途非常广泛。比如,当我们需要和其他团队合作开发一个接口时,我们都知道第一步就是要把接口定义下来。

  这里的DoD看起来很完美,定义了验收清单,罗列了一系列验收项目,并固化成文档。但是,过程中有几个焦油坑需要去思考:

  • 如何才能符合“可验收”?
  • 彼此都无法想到的风险如何管理?

  也许这需要团队的磨合了,从老张角度如果这事不会死人,其实没有必要去咄咄逼人,大不了后续进行迭代改进,否则逼得紧其实只会引起反弹,养成小李习惯性的逃避责任,形成团队推卸责任的文化就得不偿失了。

  当我们有了DoD的思维方式,后面的事情也许会变得简单很多,郑晔举了个小例子让人折服:

1.经常会有人过来,让我帮忙做些事。运用 DoD 的思维,我首先会问他我具体要做哪些事,确认好细节(相当于定义好“检查项”),然后我就知道,这个忙我能帮到什么程度。
2.我请别人帮忙的时候,也会很清楚告诉他,哪些事是需要他做的,尽量减少不必要的误解。

五、总结

  人与人的协作,总会存在理解上的偏差,如何去解决信息不同步的问题呢?DoD是一种最佳实践,它是包含了检查项的验收清单,而如何做到“可检查”需要双方重点沟通。DoD从大了看是一种思维模式,是一种尽可能消除不确定性,达成共识的方式。

借用郑晔的一句话:“如果今天的内容你只能记住一件事,那请记住:在做任何事之前,先定义完成的标准。”

目录
相关文章
|
Kubernetes Linux 程序员
k8s自定义controller三部曲之一:创建CRD(Custom Resource Definition)
通过自定义控制器开发深入理解k8s的控制器设计思想及其实现
838 0
k8s自定义controller三部曲之一:创建CRD(Custom Resource Definition)
|
3月前
|
开发框架 .NET 编译器
总结一下 C# 如何自定义特性 Attribute 并进行应用
总结一下 C# 如何自定义特性 Attribute 并进行应用
|
6月前
|
编译器 C#
C#.Net筑基-类型系统②常见类型 --record是什么类型?
`record`在C#中是一种创建简单、只读数据结构的方式,常用于轻量级数据传输。它本质上是类(默认)或结构体的快捷形式,包含自动生成的属性、`Equals`、`ToString`、解构赋值等方法。记录类型可以继承其他record或接口,但不继承普通类。支持使用`with`语句创建副本。例如,`public record User(string Name, int Age)`会被编译为包含属性、相等比较和`ToString()`等方法的类。记录类型提供了解构赋值和自定义实现,如密封的`sealed`记录,防止子类重写。
|
缓存 iOS开发
Runtime系列:Class的结构【03】
Runtime系列:Class的结构
127 0
Runtime系列:Class的结构【03】
【Groovy】编译时元编程 ( AST 语法树分析 | ClassNode 根节点 | 方法 Methods 节点 | 字段 Fields 节点 | 属性 Properties 节点 )
【Groovy】编译时元编程 ( AST 语法树分析 | ClassNode 根节点 | 方法 Methods 节点 | 字段 Fields 节点 | 属性 Properties 节点 )
197 0
【Groovy】编译时元编程 ( AST 语法树分析 | ClassNode 根节点 | 方法 Methods 节点 | 字段 Fields 节点 | 属性 Properties 节点 )
|
Linux C语言
利用__attribute__((section()))构建初始化函数表【转】
转自: https://mp.weixin.qq.com/s?__biz=MzAwMDUwNDgxOA==&mid=2652663356&idx=1&sn=779762953029c0e0946c22ef2bb0b754&chksm=810f28a1b678a1b747520ba3ee47c9e...
1761 0
【基础】Attribute的妙用
如果您觉得文章对您有帮助,可以【打赏】博主或点击文章右下角【推荐】一下。您的鼓励是博主坚持原创和持续写作的最大动力!
728 0