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

一、场景描述

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

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

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

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

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

小李：我的代码写完了。

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

小李：还没有。

老张：那今天能测完吗？

小李：那我就不知道了。

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

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

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

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

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

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

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

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

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

二、理解的代沟

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

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

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

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

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

三、完成的定义

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

• DoD 是一个清单，清单是由一个个的检查项组成的。

• DoD 的检查项应该是实际可检查的。

• DoD 是团队成员间彼此汇报的一种机制。

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

 

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

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

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

 

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

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

四、DoD是一种思维方式

　　郑晔在最后又补充道：

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

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

• 如何才能符合“可验收”？

• 彼此都无法想到的风险如何管理？

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

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

1.经常会有人过来，让我帮忙做些事。运用 DoD 的思维，我首先会问他我具体要做哪些事，确认好细节（相当于定义好“检查项”），然后我就知道，这个忙我能帮到什么程度。

2.我请别人帮忙的时候，也会很清楚告诉他，哪些事是需要他做的，尽量减少不必要的误解。

五、总结

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

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

原文地址：https://www.cnblogs.com/jackyfei/p/10244806.html

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com