敏捷DoD完成定义的多种形态

作者：张克强    作者微博：张克强-敏捷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，上周新增功能的自动化测试是否加入到每周测试集。