“完成的定义“在每本 Scrum 书籍中都会重复出现，但没有太多工程意义。它通常是一个 12 项清单，在 sprint 2 之后没有人会阅读。
这篇文章是工程版：什么 有用的 完成的定义实际上包含，要删除什么，以及如何使其成为您的团队用来决定工单是否可交付的东西；不是一种服从仪式。
为什么大多数完成定义（DoD）成为摆设
标准的 scrum DoD 看起来像这样：
- 代码写好了
- 代码已审核
- 测试已编写
- 测试通过
- 文档已更新
- 向产品负责人演示
- 合并到主干
- 部署到暂存区
每个团队都见过其中之一。每个团队在第三次冲刺后也不再阅读它。为什么？
因为大多数子弹要么是 明显的 （“代码已编写”；是的）， 有抱负的 （“文档已更新”；“更新”的定义是什么？），或者 实践中无法验证 （“测试是编写的”；针对哪些行为，覆盖范围如何？）。
在决定是否合并时没有人参考的完成定义（DoD）是沉重的负担。这是一张墙海报，而不是工具。
实用的完成定义（DoD）有何作用
真正有效的完成定义（DoD）只回答一个问题： 该工作现在是否满足由团队中的任何人交付的标准？
就是这样。不是“我们是否遵循流程”。不是“我们是否勾选了方框”。完成定义（DoD）是你和未来的你之间的一份合同：当这张票被标记为完成时，排队的下一个人可以信任它吗？
实用的完成定义（DoD）具有以下三个特性：
- 几秒钟内即可验证。 每个项目必须在一分钟内完成检查。如果“文档已更新”需要阅读三个文档和三个 PR 来验证，那就太模糊了。
- 独立失败。 每个项目都必须是审稿人可以独立说“这没有发生”的事情。没有什么挥手。
- 属于工程，而不属于仪式。 完成定义（DoD）不应包含“向项目经理演示”。那是工作流程的门槛，而非质量门槛。
真正有效的工程完成定义（DoD）
这是我们推荐的版本。六项，全部可验证。
1. 测试涵盖工单改变的行为
不是“测试存在”。不是“覆盖率是 X%”。完成定义（DoD）要求： 对于此工单添加或更改的每个行为，如果您恢复该行为，是否有测试会失败？
这是唯一重要的测试栏。覆盖率百分比可以通过，但关键路径未经测试。 “编写的测试”在技术上可能是正确的，但测试断言没有任何意义。
如果工单更改了计算，则如果您破坏了计算，测试就会失败。如果工单添加了一个端点，就会有一个测试命中它。如果它更改了错误路径，则会对该错误进行测试。
2、happy path的手动冒烟测试
人类查看运行环境（开发、登台或生产）中的变化，并看到该功能端到端地工作。不通过屏幕截图；通过点击。
如果更改是非 UI 的，则变为“运行了相关的 CLI 命令/命中了相关的 API 并返回了预期的响应”。
这捕获了通过测试的错误类别，因为 测试设置 是错误的。我们都经历过这样的情况：测试未通过、功能损坏、模拟无法反映生产情况。
3. 没有新的 linter 或 CI 失败
CI 绿色，绒毛干净，没有新警告。这是验证成本最低的项目（参见 GitHub），也是应用最少的项目。很多团队都拥有“CI 通过”的 DoD，但允许合并忽略不可靠的测试。不。
4. PR 描述中指定的审阅者已批准
不是“代码经过审查”。这句话太含糊了；代码由谁审查？深度是多少？
具体版本：PR 描述指定了一位审阅者，该审阅者留下了批准，并且批准是在最近的有意义的更改之后进行的。如果作者在批准后强行进行重构，请重新获得批准。成本小；跳过的成本有时是一个非常令人惊讶的错误。
5. 架构更改是可逆的或有记录的回滚
这可以防止 90% 的深夜事故发生。如果工单修改了数据库模式，则记录回滚路径；要么作为有效的向下迁移，要么作为 PR 中的评论解释“这是一种单向迁移，因为 X，这就是我们恢复的方式。”
对于非架构更改，此项不适用。但每个团队都应该将其列入列表中，因为 成本 不可逆的不良迁移是巨大的。
6. 工单描述与 PR 的实际操作相符
阅读工单。阅读公关。他们描述的是同一件事吗？
这是对范围蔓延的检查，而不是其他任何事情。如果您着手“修复工具提示错误”并发布“修复工具提示错误+重构整个工具提示组件+添加新的分析事件”；工单需要拆分，或者描述需要更新。描述和 PR 存在分歧的工单是审核工作花费在错误的事情上以及回归潜入的地方。
标准完成定义（DoD）应去掉哪些内容
三个看似合理但实际上是噪音的项目。
删除：“合并到主”
如果工单未合并，则表示未完成。这个项目符号是同义反复。不要把它放在清单上。
删除：“已演示至 PO”
这是一个工作流程步骤，而不是质量标准。它属于你的冲刺审查或计划仪式，而不是完成定义（DoD）。如果是在完成定义（DoD），你会让工程师在“演示”之前标记完成的工单，因为完成定义（DoD）说合并到主线就足够了。你正在编码一个矛盾。
删除：“文档已更新”
在目前的模糊形式下，该项目大多被忽略。如果需要，请替换为两个具体内容：
- 如果更改涉及已记录的公共 API： API 文档作为此 PR 的一部分在同一提交中进行了更新。
- 如果更改引入了不明显的操作行为（cron 作业、新的配置标志、新的外部依赖项）： 操作手册或相关自述文件中有一段注释。
如果两者都不适用，则此项不适用。不要让它成为你出于习惯而选中“是”的永久复选框。
使其可见
完成定义（DoD）只有在以下情况下才能发挥作用 工作旁边。我们已经看到它在三个地方起作用，按有效性的粗略顺序排列：
- 固定到工单跟踪器的工单模板的顶部。 每张新工单都会显示完成定义（DoD）清单。工程师边工作边勾选，审查者可以抽查。
- 每个 PR 都有一个机器人评论 列出了 DoD 项目并要求作者勾选每一项（或标记 N/A）。对于作者来说30秒，比审稿人的记忆要快得多。
- 工程频道中的固定消息。 摩擦力最低，衰减最高。仅将其用作备份。
我们在 SprintFlint 中原生支持前两个；有一个 完成清单模板的定义 进入工单描述，平台的 PR-link 集成在 GitHub 链接旁边显示 DoD 内嵌内容。
6 项版本与 12 项版本
为什么是 6 项，而不是 12 项？
因为每增加一个项目 稀释 其余的。 12 项 DoD 变成了 12 项仪式。实际使用的 6 项 DoD 比被忽略的 20 项 DoD 捕获更多错误。
“这应该属于完成定义（DoD）”的标准是： 如果缺少此项目，我会拒绝 PR 吗？ 如果答案是“可能不会，我就发表评论”；它不是完成定义（DoD）项目，而是代码审查偏好。
如何不拘礼节地介绍
如果您的团队目前没有完成定义（DoD），或者没有人读：
- 冲刺1：就这 6 项达成一致，将它们放入文档中。不强制执行。只需拥有它们即可。
- 冲刺2：将它们添加为工单模板上的清单。工程师自我评价，评审员抽查。
- 冲刺3： 在 回顾，请问：“上一次冲刺中，是否有工单被错误地标记为已完成？”如果有，是完成定义（DoD）中的哪一项没有得到落实？只需加强该项的执行。
- 冲刺4：现在 DoD 已具有本地含义。这不是从书上借来的。
不要试图强行推行繁重的完成定义（DoD），那样难以持续。六项版本足够轻量，更容易顺利落实。
“完成”应该是什么样的感觉
对于您的团队来说，经过 4-6 次冲刺运行后：
- “完成”的意思是 你现在就把这个放在客户面前。没有什么惊喜。
- 审查者可以在 5 分钟内完成 PR 审查，因为完成定义（DoD）已经保证了大部分要求。
- 新员工可以查看已关闭的工单并信任它。
- “完成”从你的词汇中消失，因为“完成”已经意味着完成。
这正是它的意义。完成定义（DoD）不是文书工作，而是团队的约定，让工程 速率 保持可持续发展。生成您自己的 完成生成器的定义.
SprintFlint 附带本机 DoD 检查表、工单模板和 PR 集成；专为想要合同而不是文书工作的团队而设计。固定价格为 5 英镑/用户/月。 免费开始：每月50张免费工单，无需刷卡。