DOD

今天想跟大家聊聊DOD，Definition of Done，我们总是太擅长去制定各种DOD，可执行的效果究竟如何，似乎需要打上一个问号？那我们在制定DOD的时候，究竟需要考虑哪些问题？

• 为什么需要DOD？

DOD是一种能力的体现，用于定义清楚我们的边界，比如，在团队迭代内，什么样的用户故事是迭代可交付的？需要达到什么样的标准。团队成员以此为准，用于指导迭代内用户故事的相关开发，验收工作。

• 有哪些种类的DOD？

一般说来，有很多不同层级的DOD，比如，用户故事DOD，迭代DOD（属于过程的DOD），迭代版本DOD，补丁DOD等，取决于项目的实际情况，不同层级的DOD其关注点和想要解决的问题不同。DOD定义清楚了，各个环节，各种交付物的边界就清楚了。

• 定义DOD需要注意些什么问题？

DOD不是越多越好，如果我们做不到的先不要放到里面，DOD定义的规则一定是我们百分百能做到的，如果暂且做不到的，可以考虑放低标准，或不放进来。一旦DOD里面出现一开始制定时，大家就认为做不到的项，那DOD的落地实施就是有问题的。

• DOD是可以修改的么？

当然可以，DOD是一种能力的体现，是可以被扩展，而且推崇被扩展的。比如，迭代DOD定义的项，当我们能做到所有的story都在迭代内done掉，而没有遗留undone项时，我们就可以把它作为一项加入到迭代DOD里面去，这也是我们迭代交付能力提升的一种表现，不管是团队还是项目，都可以以此作为一个改进的目标。

• 如何保证DOD更好的落地？

更好的度量手段和目标导向对DOD的落地执行具有更好的指导意义。比如，每个迭代，能够快速直观的可视化出各团队的DOD执行情况，但这里强调的一定尽可能是利用各种工具能够自动统计出的客观统计数据，因为人为统计数据不够客观，也不够可靠，且成本可能比较大，不利于长期落地使用。他们会像一个标尺，一个指向灯，引导团队往更清晰的交付边界上走。

总而言之，DOD绝对不是拍脑袋想出来的各种规则，而是结合实际情况，大家一起制定的，达成共识的，对我们的工作有绝对的指导价值的，清晰易度量的一些规则，在DOD的指导下，能够让我们更正确的做事。

图片发自App