关于DOD的一点思考2

DOD的理解

DOD：Definition of Done，完成的定义。

#日，服务工具AMM评审过程中，#教在看了我们的DOD后，认为我们目前正在运行的DOD存在如下几个问题:

1.每个迭代回顾会上去检查DOD占用较多的时间，目测我们的DOD条目有几十条。

2.有些DOD没有办法验证，比如每天提交代码到制品库。

3.有些条目不适合作为DOD，比如，回顾会上要考虑风险，这种可以作为回顾会的一种约定。

这些确实是我们目前DOD需要改进，于是便呈现了我们正在整理的，按照交付类，过程类的新DOD，#教看了后，说了一句让我倍感受挫的一句话，我觉得，这个新的DOD还没有你们现在正在执行的好。#教提出，一个好的DOD，不应该产生额外的工作量，要融入我们平时的工作中，比如，当一个用户故事从开发中移到待验证状态，需要完成哪些动作才能够移动？那么这些必须要完成的动作就可以作为团队的DOD，如果这些动作没有满足，则不能移动卡片，每次的卡片移动，都需要对应DOD的达成，同时，DOD的达成是对每个卡片都生效的，不应该在回顾会上作为一条任务来过。

  通过与#教的交流，让我对DOD有了新的认识，同时也产生了迷茫，后续，我们的DOD该何去何从？

  关键时刻，请教了教主，中间省略1w字。

在定义DOD时，要确定一下DOD的使用场景，

首先，先来看一下SCRUM和看板方法的区别。

          看板方法与Scrum的一个显著差别，看板方法没有时间盒的概念，每个任务项在泳道中从代办到完成，没有统一的交付时间，而Scrum有时间盒的概念，即使SBI可以按照优先级的先后顺序在迭代中有不同的开始时间，且可能完成的时间也不同，但却是在迭代结束时是需要同时交付的。

        因此，Scrum运作过程中，在DOD的设定上，除了过程中卡片移动产生DOD外，每个时间盒结束时，也应该有对应交付的DOD，即:我们的DOD可以分为过程类DOD和交付类DOD。而过程类DOD，可以参照#教的提议，约定我们在迭代过程中卡片移动时需要完成的动作，此外，在我们的敏捷研发过程中，除了迭代过程，我们还可以有补丁过程等，具体可以根据自己项目需要设定。交付类DOD:我们可以根据交付类型来定义迭代交付DOD，Release交付DOD，补丁交付DOD等，每种交付约定相应的输出。

          确定了DOD的总体方向，后面在约定DOD具体条目时，需要考虑易于跟踪，避免增加团队额外工作量等方面。