在 Jira 中使用 Definition of Done：约定“完成”的含义
建立实用的质量清单，应用到 Jira 事项，并依据证据判断完成情况。
工程师完成修改并推进 Jira 状态，测试人员却发现新页面正常、旧流程损坏。支持从困惑的客户那里才得知变化。大家都说“完成”，含义却不同。
Definition of Done 为团队提供共同完成标准，在开工前展示预期质量检查，让审查不再依赖谁记得提出正确问题。
本指南通过虚构门户团队，区分共享质量检查与功能专属验收标准，并用 Power Pack 的 Definition of Done & AC 将两者放在事项旁。
什么是 Definition of Done？
Scrum Guide 将其描述为增量必须达到的质量标准，建立对完成工作的共同理解。组织已有的标准是其 Scrum 团队必须满足的最低要求。参见官方 Scrum Guide。
在实践中，可以把它视为每次相关变更都要回答的少量问题：实现是否经过审查？约定验证是否通过？支持变更所需信息是否可用？
具体问题取决于产品和风险。公共门户、内部报表和安全关键系统需要不同标准。不经讨论复制别人的清单，可能既留下重要漏洞又增加无用工作。
有用标准描述可观察的结果。“高质量”是目标，“约定回归检查通过，结果已链接至 Jira 事项”才是可以核查的条件。
区分共享质量与功能行为
团队新增通知偏好，让客户开关每周摘要邮件。重要账户消息不受此偏好影响。
功能需要自己的验收标准。例如退出后重新登录，保存的选择仍应显示。这描述客户体验，因此属于该功能。
Definition of Done 覆盖更广泛的完成要求。实现审查、受影响旧行为验证和支持文档更新，可能适用于多种变更。
| 检查什么？ | 约定回归检查已通过。 | 关闭每周摘要后，不再发送下一封符合规则的摘要。 |
| 适用在哪里？ | 产品中的相关变更。 | 通知偏好事项。 |
| 什么证据有帮助？ | 该变更的回归结果链接。 | 使用已关闭摘要账户完成的检查记录。 |
两份清单都重要。功能可能满足要求但缺少必要质量工作；代码审查和回归通过也不等于指定功能行为正确。
从团队真实遇到的缺口开始
邀请开发、验证和支持人员简短讨论，选用近期看似完成却出现意外后续工作的案例。
门户团队发现三个重复问题：审查意见有时未解决，现有账户设置回归不足，支持说明晚于功能上线。
这些问题指向有用检查，也说明清单应保持简短：每项都应避免可辨认的失败或确立必要质量条件。
询问如何验证每个提议。如果没人说得清证据，先改善措辞。“文档完成”可能指发布说明、内部设计或客户帮助文章。约定所需信息及其位置。
也应在日常规划中约定谁通常执行检查。清单不会自动分配审查者或预留日历时间。
起草实用的共享清单
以下是团队初稿，是示例工作约定，不是普遍标准。
- 实现审查完成，必须处理的意见已解决。
- 事项约定的验收标准已经验证。
- 受影响账户流程的约定回归检查通过。
- 修改页面的约定无障碍检查通过。
- 支持说明反映新的客户行为。
- 验证结果与相关审查链接已记录在 Jira 事项中。
使用前，团队写明回归和无障碍检查包括哪些内容，否则两个人可能做不同工作却勾选同一句话。
门户的回归范围包括登录、打开账户设置、更新现有个人资料字段。改动控件的无障碍检查包括键盘操作、可见焦点和清楚标签。这些只是该团队选择的检查，不是完整无障碍标准。
支持条目也需要实际解释。若变更不影响客户，应事先制定适合此类工作的标准，不要让审查者临时发明例外来把列表变绿。
将标准加入 Jira 事项
打开事项中的 Definition of Done & AC 卡片。它包含 Acceptance Criteria 和 Definition of Done 两个独立标签。添加共享检查前选择后者。
短清单可输入检查标题，再选 Add 或按 Enter。每个标题只包含一个可审查条件；将三个无关检查写成一句，会难以表示部分完成。
也可选择 Bulk Import 粘贴 Markdown 列表，例如上面六项，每行前加连字符和空格。普通 Markdown 复选框也受支持。
导入会向当前标签追加内容。确认前检查标签，导入后检查结果。重复导入可能产生重复项，因此不要把它当作刷新。
未验证工作应使用未勾选条目。已勾选 Markdown 会被导入为完成；从旧事项复制的勾选不能代替当前检查。
共同标准需要手动放入每个相关事项。在团队文档保留参考版本，再将合适检查粘贴到新事项。这是团队实践，不是中央标准与全部事项的自动连接。
进行一次真实审查
假设通知偏好已可审查。Maya 核查客户结果，Priya 验证回归，Leo 解决剩余实现意见并链接审查记录。
第一轮发现保存正常，但点击 Save 后键盘焦点消失。团队保持无障碍项未完成，在正常 Jira 讨论中记录问题，修复后重新检查。
支持说明也尚未完成。即使功能验收标准全通过，这项仍可见。独立列表能说明团队为什么还有工作。
真正检查通过后，选择 Done。若新信息要求重新处理，再选一次即可恢复待办。测试结果、审查链接和重要决定仍按正常 Jira 或文档流程记录。
完成条目记录的是团队判断，不会运行检查、收集证据或确认验证者。如果身份或时间重要，应在日常审查流程明确记录。
正确理解就绪指示
工具显示每个标签完成数与总数。只有两份清单都至少一项且全部完成，才显示 Ready for Release；否则为 In Verification。
这帮助发现未完成项，也解释了为什么 Definition of Done 全完成、Acceptance Criteria 为空时不会显示全部完成。
它只是清单状态摘要，不证明检查足够、证据有说服力或产品可安全发布。差劲的检查同样容易被标为完成。
清单也不阻止 Jira 状态转换或合并请求。仍应按团队正常交付与发布流程作这些决定。
工作变化时保持标准有用
重复缺陷暴露漏检、产品显著改变或检查失去信息价值时，应重新评估标准。
例如偏好立即生效，但延迟同步后失效，可能引出针对延迟处理功能的更广验证规则。先确定适用变更和成功证据。
更新参考标准，并讨论如何用于进行中的工作。现有事项不会自动继承修订，需要检查受影响事项并按需手动添加。
不要每出现一次孤立错误就扩充清单。有时具体验收标准、明确实施任务或改善审查流程更合适。共享标准应保持可理解且能真实执行。
在当前事项中试用
选择临近审查的事项，约定短质量标准，放入 Definition of Done，再将专属客户结果加入 Acceptance Criteria。
一起检查并在日常位置链接证据，只在验证后标为完成，再按通常交付流程讨论剩余工作。
价值在于沟通清晰。有人说偏好修改完成时，团队能解释哪些结果正常、哪些质量检查通过，以及结论依据。
相关文章
立即沟通
对此文章有疑问？让我们讨论你的工程目标。