DoR、DoD，定义的是什么？ | IDCF

本文部分内容，节选自——《敏捷无敌之DevOps时代》第18章 ”DoD，真正把事做完“

本文部分内容，经授权，节选自“侬家铺子“的文章：DevOps成长路线——DoR vs DoD

上文翻译自：https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will

一、DoD 与 DoR

一个迭代是固定时间的循环，依次把迭代backlog上高优先级的任务变成产品增量。但是，要把事项顺利拉到当前的迭代中，如何定义用户故事“已经准备好”是很重要的——把没有完成或没有细化的用户故事放到迭代中，会在开发阶段产生问题，因为它遵循一个古老的原则：“进去的是垃圾，出来的也是垃圾”。如果开发基于没有充分细化或定义的用户故事来开发，他们不太可能产出高质量的代码。

一个“准备好”的backlog事项应该是清晰的，可行的，可测试的：

• “清晰的”意味着所有的Scrum团队成员对该条目达成了共识。通过协同编写用户故事，对高优先级事项添加验收标准，有利于需求的澄清。
• “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。
• “可行的”意味着根据DoD，该条目能够在一个迭代中完成。否则，条目需要进一步的分解。

简单的讲，DoR定义了一些标准，用户故事在开始估算或者进入迭代前，必须先符合这些标准。

“DoR”关注用户故事级别的特性，“DoD”的关注点则在迭代或者发布层面。本质上，“DoD”代表着迭代或者发布的验收标准。它清楚的列出了为完成产品增量，开发团队必须要达到的要求。

二、DoR是什么

DoR是一个待办（backlog）是否能够被团队接受，认为可以作为开发候选所需要达到的最小要求，是团队针对PO的要求。

一个DoR的例子：

• Clear，用户故事描述清晰；
• Feasible，用户故事可以放入一个迭代；
• Testable，验收条件得到定义 。

需要注意的是，DoR只需要针对产品待办列表PBL中高优先级的需求进行，通常是准备能够满足两个迭代的即可。PBL越是近期会做的，需求越清晰，越是符合INVEST原则；越是暂时不会做的，越不需要花太多精力去澄清和拆解。

而DoD则相反，是PO针对团队的产出进行验收的最低验收标准，文中已经给出了样例。

最初DoD只有一级，即研发迭代完成，用户故事可以被视为完成的标准。逐渐出现了多级的DoD，针对每一个研发阶段，出现了这一阶段的DoD标准，例如从Henrik Kniberg的Kanban kick-start example图中，分析阶段的DoD、开发阶段的DoD、验收测试阶段的DoD等；典型的Kanban是拉动的过程，后一阶段拉取上一阶段完成（Done）的工作时，会检查相应的DoD是否完成，因此上一阶段的DoD事实上就是下一阶段的DoR。

越往前的DoD越偏业务，然后是偏技术实现，越往后的越要加入运维和非功能性要求。

2.1 DoR的一些例子

• 用户故事是清晰的
• 用户故事是可测试的
• 用户故事是可行的
• 用户故事已定义
• 用户故事验收标准已定义
• 用户故事依赖已明确
• 用户故事已由开发团队做过粒度划分
• Scrum团队已接受UI原型设计
• 指定场景下的性能指标已明确
• 指定场景下的可扩展性指标已明确
• 指定场景下的安全指标已明确
• 验收用户故事的人已明确
• 团队都清楚用户故事所表达的意思

三、DoD是什么

“DoD”是开发团队和PO对每个用户故事需要做什么的协定 – 通常在公司层面统一标准，以保证交付质量一致。

“DoD”通常会说明：

• 用户故事所处的系统环境（哪个版本的Linux、Android、iOS或者浏览器）？
• 需要输出什么样的文档（自动生成的Javadoc，还是完整的终端用户手册）？
• 有什么质量要求（用于演示的基本功能，还是一个功能完整，健壮的APP）？
• 有什么安全要求（无安全要求，还是从代码评审、代码扫描到网络安全配等各方面都要求做安全审查）？
• 有什么扩展性要求（10个并发，还是10万个并发）？

本质上说，“DoD”是基于验收标准的协议，PO在迭代结束时同它来验收产品增量。

请注意，针对迭代和发布阶段，DoD标准可能会不一样。中间迭代的DoD，比起临近发布的几个迭代，要求不会那么严格。

3.1 DoD的一些例子

• 代码已完成（所有代办事项已经完成编码）
• 代码已注释、已提交。版本库当前版本能正常运行
• 结对检视已完成（或者采用结对编程），代码符合开发标准
• 构建没有错误
• 单元测试全部通过
• 部署到测试环境并通过系统测试
• 通过UAT（用户验收测试）并签字确认符合需求。
• 任何编译/部署/配置变化都已实现/记录/沟通。
• 相关文档/图表已完成或已更新
• 任务剩余的小时数已设置为0，任务已关闭

3.2 DoD，通常需要从几个维度考虑

为Sprint中任务给出明确的“Done”定义是非常重要的，但即使你遵循这个最佳实践，最终仍然会有集成问题，会存在Bug，以及晚期的需求变更。所以，对于大型复杂产品，在正式发布前，单独计划1～2个Sprint，专门做Bug修复，也是合理的。

关于DoD的例子，通常需要从几个维度考虑。

1）需求/用户故事DoD

• 用户故事的描述及拆解符合INVEST；
• 用户故事有验收标准AC(Acceptance Criteria)。

2）开发任务DoD

• 代码已经提交到Git;
• 代码通过单元测试；
• 代码经过Code Review;
• 代码通过集成测试。

3）迭代DoD

• 所有代码通过静态检测，严重问题都已修改；
• 所有新增代码都经过Code Review；
• 所有完成的用户故事都通过测试；
• 所有完成的用户故事得到Product Owner的验证。

4）发布DoD

• 完成发布规划所要求的必须具备的需求；
• 至少完成一次全量回归测试；
• 符合质量标准(Quality Gate)，譬如所有等级为1、2的缺陷均已修复；3、4级缺陷不超过10个；
• 有Release Notes；
• 有用户手册；
• 产品相关文档已全部更新；
• 代码已部署到发布服务器上，并冒烟通过；
• 原始需求提交人完成UAT；
• 对运维、市场、客服的新功能培训已完成。

Tips：DoD及WA必须是团队共同讨论出来的，团队愿意共同遵守的原则，一旦确定，团队就应共同遵守。

四、DoD和DoR应该上墙

无论是用物理的Kanban、TaskBoard，还是电子的，建议将定义清晰的DOD，显式的张贴出来。下图就是很好的例子，便于所有人对齐想法，并且在板子上进行挪动时，无论是挪到Done的专题，还是拉到下一个状态，都可以随时看到DoD的标准，提醒所有人遵守并检查。保证每个人对一件工作是否完成有一个统一的认识，交付和接纳时时也保持清晰的交接界面。

五、DoR和DoD另外的用法

DoR和DoD的本意是创建一份简明的文档，用于在项目干系人，PO和开发团队间达成一致。但是，随着越来越多的工作被外包或分包， DoR和DoD也更多的用于合同协议和SOW，用以清楚、准确阐述对于需完成工作的期望。

DoR和DoD是很实用的项目范围商议工具，因为它们定义了期望和双方的职责；DoR帮助客户产出良好的用户故事，为开发团队所用；DoD帮助交付伙伴根据整体项目需求产出可工作的产品增量，而不仅仅是特定的用户故事功能。

六、小结

DoR和DoD就像流水线上的两道关，一个管进，一个管出。我们不像牛那么厉害，吃的是草，挤出的是奶。对团队来说，第一道关更加重要，正如作者说的，进去的是垃圾，出来的也是垃圾。没有DoR的把关，后面的持续改进，工程实践效果都不会太好。

ACE葫芦兄弟集结，带来系列课程【IDCF训练营|ACE JIRA实战训练营】，现在购买可享受团购优惠价哦~识别下图二维码立即加入吧（识别二维码即可浏览课程目录）