dor
关于Definition of Done 完成的定义
DoD在以往的说法中，常见用 退出标准 , 完成条件，成功标准，等等
典型的是迭代的DoD，这也是最初DoD应用的地方。 常见在Scrum中，需要预先定义DoD。
常见的迭代DoD条款
1，所有完成的用户故事得到PO的验证
2，所有代码得到静态分析，纠正最高级别的不符合项，静态分析的规则参见…
3，所有新增代码得到人工评审
4，所有完成的用户故事都有对应的测试用例
早期的迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处，在这样的安排下，回归覆盖率就应当是一个变量，用于观察，而不应当是一个要求指标。
关于Definition of Ready齐备的定义
敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是Definition of Ready，简略称之为“DoR”， 最初的Ready是指准备好可以进入迭代开发。
常见的DoR
1，用户故事得到澄清
2，用户故事的故事点估算已经得到
3，用户故事的验收条件已经给出
多级DoD的出现
随着敏捷软件开发不断实践，为了保证不同对象的质量，出现了多级的不同的完成定义。
发布DoD
而对于发布，一般就有更加严格的要求，发布DoD的典型条款有：
1，完成发布规划所要求的重点内容
2，通过发布的全量测试，回归测试范围是全范围，回归比率不低于50%
3，修复所有等级为1、2、3的缺陷，4级及4级以下缺陷不超过200个。1、2级缺陷必须修复，3级缺陷经过带缺陷发布审批后可以发布。
在以往，由于发布需要达到比迭代更高的要求，所以一般很难强制规定发布测试所需要的时间长度，也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上，因为高质量发布是第1要务，如果到了原计划测试结束的时间，仍然留有妨碍发布的缺陷的话，应当修复后才能发布。因此出现了Water-Scrum-Fall这样古怪的提法，在DAD里面，恰恰容忍这样的做法，DAD把这样的做法看成是从原瀑布模型转向敏捷交付的起步阶段。
最新为了获得更快的时效，迭代级别的发布成为越来越多组织的选择，也就是说每迭代都要发布。那么这样，就把发布的高要求带给了迭代，迭代DoD同时要满足发布DoD。这种情形下，也需要对原来的发布DoD进行修改，主要在回归测试策略和通过条件上，一般而言，原来的回归测试策略需要过多的时间，无法在迭代内完成，需要新的回归测试策略能够支持迭代节奏。
为了更好的达成迭代DoD，就需要提前注意，所以有些更加细节的DoD得到识别并使用。
每日DoD
最典型的是每日DoD，典型条款有：
1，搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
2，下班前必须检入当天书写的代码
3，当天的代码必须在当天或者第2天邀请同伴进行代码评审
4，搭建持续集成环境，当天上下午必须至少各检入代码一次（这与第1条可能冲突）
5，凡是检入的功能代码必须要有对应的单元测试
用户故事的DoD
还有针对用户故事的DoD，比如
1，用户故事最终的描述符合INVEST
2，用户故事得到测试用例的对应覆盖
3，用户故事得到对应的自动化测试用例
4，用户故事得到用户代表试用并初步认可
每周DoD
有少数组织考虑到测试集过于庞大，无法在1天之内测试完成，开展每周全量回归自动化测试，这样就有每周DoD，典型条款有：
1，上上周发现的缺陷是否解决
2，上周新增功能的自动化测试是否加入到每周测试集。
多级DoR的出现
随着多级DoD出现，多级DoR也出现了，往往的前一段的DoD就是后一段的DoR。所以有些的DoR其实就是DoD。比如对于集成测试的DoR就是开发联调的DoD，在使用看板的情况下，就是状态列的移动条件。典型的从开发联调到集成测试的条件：
1，开发跑通主成功场景，Demo给到PO，得到PO认可
2，代码合并到某某指定分支
3，持续集成通过
小结
从最初只有迭代DoD出发，DoD和DoR的多种形态的出现是越来越高频交付的必然结果。在既追求质量又追求效率的情况下，值得组合选择设定恰当的DoD和DoR，并且在运行中根据出现的情况，不断调整，成为敏捷团队的约定，进而塑造团队文化，甚至进而影响组织文化。