DevOps成长路线——DoR vs DoD

IDCF的Devops成长路线图就贴在吹风机旁边的墙上，每次吹头发的时候，盯着图看，很多的新名词都不懂。既然叫成长路线图，那就顺着图一点一点学习吧。开篇先来聊聊DoR和DoD。

我发现LinkedIn上的文章质量还是不错的，有一篇Brian Will写的关于DoR和DoD的介绍，我拿来翻译了下，和大家一起学习。原文地址是：https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will

全景图

Backlog是Agile和Scrum里一个关键的制品，分为产品和迭代两个层级。

产品级backlog就是项目的代办列表，也叫需求池。项目范围内的所有事项，无论颗粒度如何，都归入产品backlog，经过排序——意味着排名第1的比第5的重要，同样，第5位的比第23位的重要。事项顺序通常是由商业价值驱动，由PO和开发团队一起协商，最终由PO决定。

项目范围通过用户故事的方式来记录，会随着后续的需求探索而变化。产品backlog由PO负责，并持续更新。

产品backlog是迭代backlog的来源。如果说产品backlog代表项目的需求池，那么迭代backlog 就是针对下一个迭代约定的范围，也代表着开发团队的交付承诺。

一旦大家认同并作出了承诺，迭代backlog通常不会再改变，以保证开发团队能够兑现诺言。

开发团队按迭代backlog从上到下的顺序开发（从最重要到不太重要），如果工作提前完成了，就从产品backlog的最上面依次取出额外的代办事项，放到当前的迭代中。

如果事项在迭代结束前没有完成，就放回到产品backlog中，在下一个迭代计划会中重新考虑。

新发现的需求以用户故事的方式加到产品backlog中，在未来的迭代中考虑。

定义已准备（DoR） vs 定义已完成（DoD）

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

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

1. “清晰的”意味着所有的scum团队成员对该条目达成了共识。通过协同编写用户故事，对高优先级事项添加验收标准，有利于需求的澄清。

2. “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。

3. “可行的”意味着根据DoD，该条目能够在一个迭代中完成。否则，条目需要进一步的分解。

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

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

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

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

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

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

DoR的一些例子

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

DoD的一些例子

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

DoR和DoD另外的用法

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

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

小结

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