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

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

一、场景描述

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

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

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

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

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

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

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

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

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

二、理解的代沟

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

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

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

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

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

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

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

三、完成的定义

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

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

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

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

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

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

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

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

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

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

四、DoD是一种思维方式

  郑晔在最后又补充道:

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

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

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

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

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

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

五、总结

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

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

上一篇:重拾《 两周自制脚本语言 》- Eclipse插件实现语法高亮


下一篇:从立创EDA,Gratipay看中文编程开发环境和推广运营的一个趋势