DoD-做任何事之前，先定义完成的标准

先来看一个小故事。小李是一个程序员，有一天，项目经理老张来到他身边，和他商量一个功能特性的进度：

老张：这有一个任务需要完成，你看一下。

小李：这个不难，两天就能做完，两天以后就能上线。

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

老张：怎么样，做完了吗？今天能上线吗？

小李：我的代码写完了。

老张：测试人员测过了吗？

小李：还没有。

老张：那今天能测完吗？

小李：那我就不知道了。

老张：什么？我可是答应了业务的人，今天一定要上线的！

很明显，老张有些愤怒，而小李也有些委屈。于是，老张、小李和测试人员一起度过了一个不眠之夜。

又过了几天，老张又来找小李，给小李安排一个很简单的功能。在小李看来，一天就能搞定，而按照老张给出的时间表，小李有两天时间处理这个功能。小李心中暗喜：看来我可以“偷得浮生一日闲”

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

老张：这个功能开发完了吗？

小李：写完了，你看我给你演示一下。

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

老张：做得不错。单元测试都写了吧？

小李：啊？还要写单元测试吗？

老张：要不为啥给你两天的时间？

怎么会这样？小李心里很委屈，自己明明已经很好地完成了工作，老张是不是故意在找自己的麻烦呢？

是不是有些似曾相识的感觉呢？为什么小李辛辛苦苦地工作，老张却总能挑出毛病来呢？老张是不是来挑刺的呢？其实老张才没那么闲，小李的委屈主要是因为他和老张对于“完成”有着不一样的理解。换句话说，他们之间存在一个理解的鸿沟

理解的鸿沟

小李认为他的活已经做完了，老张却认为他没做完。二人之所以有分歧，归根结底，就在于二人对“完成”的定义理解的不同。

在第一个案例中，作为项目经理的老张，认为 “完成” 应该是 “上线运行”，而程序员小李则认为 “完成” 是 “功能代码编写完毕”。这中间存在的理解偏差，包括了测试人员的测试工作，可能还包括了运维人员的上线工作
在第二个案例中，老张给了小李两天时间。小李认为这两天都是编写功能代码的，而老张想的是，小李应该自己写好功能代码和单元测试，可能还包括了功能测试，这中间的差异是测试代码的工作量

因为双方的理解不一致，所以无论怎样努力，小李都不可能达成项目经理老张的要求。既然双方的理解有差异，那就把这个差异弥合上，弥合差异的方式有很多，最佳实践叫 DoD（Definition of Done 完成的定义）

DoD 概念就是定义怎样算是完成，尽量减少因为理解偏差造成的各种浪费。就是团队在开始工作前，先制定 DoD。以前面的场景为例，团队可以规定：

一旦 DoD 确定好，谁该做什么事就一目了然。不过不仅要知道怎么用，还要知道怎样让 DoD 更好地发挥作用。

DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。DoD 的检查项，就是开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等。

什么样的活动是有价值的，也许每个团队的认识是不同的。但如果你的团队认为除了功能代码，其他都没价值，也许这是个信号，说明你的团队整体上是缺乏职业素养的，在这样的团队工作，前景并不乐观

DoD 是团队成员间彼此汇报的一种机制。当有 DoD 之后，做事只有两种状态，即 “做完” 和 “没做完”。在团队协作中，经常会听到有人说“这个事做完了 80%”，对不起，那叫没做完，根本没有 80% 做完的说法。

在前面的讨论中，所说的 DoD 只是从个人层面入手。在团队层面也可以定义 DoD

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

那么怎样才算定义完成？很多团队认为落在字面上就够了。但是有了 DoD 的思维，定义接口，就会去明确定义可检查的检查项。那么在定义接口这件事上，什么才是“可检查”的呢？可以参照一个可运行的接口来进行评估。只要检查：

在协作中一旦确立好 DoD，甚至可以通过流程把它固化下来，从而更高效高质地完成工作。当然在工作生活中难免会有一些临时的工作，它们没有复杂到需要一个流程，但是也可以用 DoD 思维来高效地解决。比如：

DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。本着“以终为始”的方式做事情，DoD 能够在一开始就把“终”清晰地定义出来

人与人协作中，经常会出现各种问题，根本原因就是，有太多因为理解差异造成的误解，进而浪费了大量的时间，而 DoD 就是一种将容易产生歧义的理念落到实处的方法