作者：张克强 作者微博：张克强-敏捷307
关于Definition of Done 完毕的定义
在以往的说法中，常见用 退出标准 , 完毕条件。成功标准，等等
在敏捷软件开发中，存在多级的不同的完毕定义。
典型的是迭代的DoD。这也是最初DoD应用的地方。
常见在Scrum中，须要预先定义DoD，常见的迭代DoD条款有:
1，全部完毕的用户故事得到PO的验证
2，全部代码得到静态分析，纠正最高级别的不符合项。静态分析的规则參见...
3，全部新增代码得到人工评审
4，全部完毕的用户故事都有相应的測试用例
而对于公布，一般就有更加严格的要求，公布DoD的典型条款有：
1。完毕公布规划所要求的重点内容
2，通过公布的全量測试。回归測试范围是全范围，回归比率不低于50%
3，修复全部等级为1、2、3的缺陷，4级及4级下面缺陷不超过200个。1、2级缺陷必须修复。3级缺陷经过带缺陷公布审批后能够公布。
由于公布须要达到比迭代更高的要求，所以一般非常难强制规定公布測试所须要的时间长度，也就是说敏捷中经常使用的时间箱方法不适宜用在公布前的測试上，由于高质量公布是第1要务，假设到了原计划測试结束的时间，仍然留有妨碍公布的缺陷的话，应当修复后才干公布。
而迭代成果通常是为了内部或者可控范围内的展示，相对公布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的測试本来就有时间限制。
採用时间箱来安排迭代内的測试能够获得时间箱安排的种种优点，在这种安排下，回归覆盖率就应当是一个变量，用于观察。而不应当是一个要求指标。
为了更好的达成迭代DoD。就须要提前注意，所以有些更加细节的DoD得到识别并使用。
最典型的是每日DoD。典型条款有：
1。搭建每日构建环境，晚上自己主动静态代码检查、编译、部署和測试，每日修复前一日构建和測试发现的缺陷和问题。
2，下班前必须检入当天书写的代码
3，当天的代码必须在当天或者第2天邀请同伴进行代码评审
4。搭建持续集成环境，当天上下午必须至少各检入代码一次（这与第1条可能冲突）
5，採用TDD。凡是检入的功能代码必须要有相应的单元測试（严格採用TDD）
还有针对用户故事（或者用例）的DoD，比方
1。用户故事终于的描写叙述符合INVEST
2。用户故事得到測试用例的相应覆盖
3，用户故事得到相应的自己主动化測试用例
4，用户故事得到用户代表试用并初步认可
有少数组织考虑到測试集过于庞大。无法在1天之内測试完毕，开展每周全量回归自己主动化測试，这样就有每周DoD。典型条款有：
1，上上周发现的缺陷是否解决
2，上周新增功能的自己主动化測试是否增加到每周測试集。