DoD 原则是什么？

DoD，敏捷开发中，常用“Definition of Done”来表示工作是否已完成。所有的DoD随着时间的推移、经验的积累、成员的变更，项目的变更，会有很大的不同。

分类：

迭代DoD：

1、所有代码通过静态检测，严重问题都已修改；新增代码都已得到人工审核

2、所有完成的user story 都有对应的测试用例；并且都已执行

3、所有完成的user story都得到Product Owner的验证

发布DoD：

对于发布，一般有更严格的要求，典型条款有：

1、完成发布规划所要求的重点需求    2、至少通过一次全量的回归测试

3、修复所有等级为1、2的缺陷；3、4级缺陷不超过20个

版本DoD：

针对每个版本上线前后的一些规则

1、PRD已全部更新  2、代码已部署到产品服务器上

3、运维在验收测试环境上通过冒烟测试  4、需求提出人已通过验收测试

5、对运维、市场、客服的新功能培训已完成

每日DoD：

搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。

1、下班前要触发静态代码检查、自动化回归测试

2、当天持续集成、构建环境中的问题，当日解决

3、检入的功能代码要有对应的单元测试

每周DoD：

测试集大时，可开展每周全量回归自动化测试规则如下：

1、上周发现的缺陷是否解决

2、上周新增功能的自动化测试是否加入到每周测试集

用户故事DoD:

1、最终描述符合INVEST     2、得到测试用例(自动化测试)的对应覆盖 

3、得到PO试用并初步认可