0. 简介
在开发大型的机器人工程时候，我们会发现团体开发以及代码的review的会非常重要。而这些离不开敏捷开发（Scrum）以及Git管理。而最常用敏捷开发流程就是DoD。本文也将介绍和学习这种方式，来辅助各位能够在实验室和工作中团体开发中有效的管理自己以及团队。
1. 常见的迭代DoD条款
- 所有完成的用户故事得到PO的验证
- 所有代码得到静态分析，纠正最高级别的不符合项
- 所有新增代码得到人工评审
- 所有完成的用户故事都有对应的测试用例
早期的迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处，在这样的安排下，回归覆盖率就应当是一个变量，用于观察，而不应当是一个要求指标。
2. DoR与DoD
2.1 就绪定义(Definition of Ready,DoR)
DoR是指一个需求能够被团队接受的标准，认为该需求已经准备就绪，并可以流入到研发的任务队列中，是需求准入的标准。该方式可以有效防止“低质量需求”流入研发侧，产生浪费！DoR是研发侧针对策划的要求。
2.2 完工定义(Definition of Done,DoD)
DoD的目的就是为了让大家对“完成”的标准有一个统一的认知，防止理解偏差。可以拆分成不同的维度去定义。
对于DoD的制定，不同的DoD任务需要有不一样的需求：
产品需求 / 用户故事 DoD
a）用户故事的描述及拆解符合INVEST
b）用户故事有验收标准AC（Acceptance Criteria）
产品开发任务 DoD
a）代码已经提交到代码库
b）代码通过单元测试
c）代码经过Code Review
d）代码通过集成测试
产品迭代 DoD
a）所有代码通过静态检测，严重问题都已修改
b）所有新增代码都经过Code Review
c）所有完成的用户故事都通过测试
d）所有完成的用户故事得到PO的验证
产品发布 DoD
a）完成发布规划所要求的必须具备的需求
b）至少完成一次全量回归测试
c）符合质量标准（Quality Gate），所有等级为1、2的缺陷均已修复；3、4级缺陷不超过10个
d）发布通知（Release Notes）
e）有用户手册
f）产品相关文档已全部更新
g）代码已部署到发布服务器上，并冒烟通过
h）原始需求提交完成UAT
i）对运维、市场、客服的新功能培训已完成
3. 来自个人的日常DoD与每周DoD
3.1 日常DoD
每日DoD，该DoD适用于研发人员的每日工作,其条款有：
- 搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
- 下班前必须检入当天书写的代码
- 当天的代码必须在当天或者第2天邀请同伴进行代码评审
- 搭建持续集成环境，当天上下午必须至少各检入代码一次（这与第1条可能冲突）
- 凡是检入的功能代码必须要有对应的单元测试
