你要不停的去尝试很多东西，试图去猜测成功是徒劳的。——凯文·凯利
极客时间《10X程序员工作法》专栏
《03 | DoD的价值：你完成了工作，为什么他们还不满意？》
before kick the ball
看到 DoD 首先想到的是美剧里面经常出现的 Department of Defence，而在这里 DoD 是指 Definition of Done （完成的定义），是一个可以检查的清单
The exit-criteria to determine whether a product backlog item is complete. In many cases, the DoD requires that all regression tests be successful. The definition of done may vary from one scrum team to another but must be consistent within one team. — Scrum, wikipedia
对于“完成的定义”，专栏文章中主要从以下四个方面进行了解释：
- 是一个检查清单，检查项是开发产品过程中有价值的活动
- 可检查，可量化，有衡量标准
- 是一种沟通机制
- 用于内部协作，外部沟通
DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。
DoD 是思维模式，其实也是一种沟通的方式吧。中国人有盲人摸象，西方有“千人千面的哈姆雷特”，所以能够把双方想象中的应用具体的描述出来，其实并不容易。
做任何事之前，先定义完成的标准
感觉有时候不光是定义完成的标准，而是要需要明确重要概念的定义，比如说完成标准中的那些检查项，就是要形成共识。
一方面可以要求对方能够提供或者可以讨论得出准确的 DoD，另一方面可能也需要适度的揣摩，站在对方的立场上考虑一下可能存在的要求。难免会遇见领导或者客户无法给出准确定义和描述的时候，而且很可能并没有那么多沟通的机会。
当然脑补的太多并没有必要，多走一步或者半步也许是不错的选择。看到文章回复中的例子，老板说弄一下考勤，那么单纯的导出考勤记录明显不能满足老板的要求，简单的做一下统计，是应有之意。而如果做的太多，花费过多的时间和精力，也没有什么必要。
还有一种情况，就是领导或者甲方其实也不太清楚自己想要什么，比如简单的说，想要上一个大数据或者人工智能的应用，这个时候是很难搞出一个 DoD 来的，如果又碰到那种先要签订一个非常具体的合同，然后按建设大纲和需求文档来实施的项目，就更困难了。
我还见到过不少拍脑袋想出来的所谓量化指标，一种是没有具体的应用场景，仅仅存在于书本或者是专家的脑袋里的；还有一种是没有办法准确衡量，或者说在制定指标的时候，并没有考虑如何测量的。
但是，不论是遇到什么样的情况，都应该尽可能的在动手之前先明确定义、确定完成的定义，才有可能更有效的沟通，达成“想象的共同体”。
最后，这个事先定义的“完成的标准”并不是为了用于项目完成之后“推脱责任”，如果随着项目的进展、迭代，这个 DoD 是不是也可以随之拥抱变化。
题图来自于极客时间，如果想要看这篇文章，可以在后台留言，有 10 个分享的名额。
网友评论