如何编写 Jira 验收标准：实用示例

“客户可以修改通知偏好”听起来很清楚，直到开始开发：是否立即保存？保存失败怎么办？明天还在吗？影响哪些邮件？

验收标准把这些问题转化为约定的可观察结果，让提出、开发和审查变更的人共享期望。

本指南为虚构门户功能编写标准，改进模糊要求，并在 Definition of Done & AC 中加入实用清单。不必使用特殊写作格式，清楚的条件与结果就够了。

什么是验收标准？

验收标准描述具体工作必须满足的接受条件，关注该事项的预期结果。Atlassian 将其与描述总体完成质量的 Definition of Done 区分。参见其验收标准指南。

例如“客户重新登录后仍显示保存的通知选择”属于验收标准；“实现已经审查”属于共享 Definition of Done。

这让两份清单各有作用：验收标准解释功能是否达到约定，Definition of Done 解释是否达到团队整体完成要求。

两者都不必包含每个技术步骤。“创建数据库字段”可能必要，却不能告诉客户或审查者设置行为是否正确。

从一个客户结果开始

示例事项为“让客户控制每周摘要邮件”。目标是登录客户可选择是否接收摘要，而不改变必要账户消息。

写标准前先定范围：有明确 Save 按钮，客户只能改自己的偏好，仅影响尚未进入发送队列的摘要。已排队消息不在本事项发送规则内。

这些细节是示例设定。团队应决定自己的实际行为，而非直接复制成产品要求。

简短范围说明可避免清单承担全部背景。Jira 描述注明只涉及账户设置页的一项偏好；选择发送日期、更换地址和管理他人偏好属于其他工作。

这样标准就能集中于证明本次变更有效的结果。

先写正常路径

从大多数客户的预期操作开始，用普通语言写明初始条件、动作和可观察结果。

例如：“登录客户关闭每周摘要并成功保存后，重新打开账户设置仍显示关闭。”审查者可建立初始状态、执行操作并检查结果。

这比“偏好正确保存”有用，明确了哪项设置、何时生效和怎样检查。

还需检查反向操作。能关闭却不能开启的控件并不完整。如果反向行为值得单独验证，就另写一项。

不要把无关结果挤在一起。保存、键盘、邮件和错误处理都可能重要，但巨大单项难以显示哪部分仍待处理。

补充失败与边界情况

正常路径假设保存成功。这个假设不成立时，客户应看到什么？

示例规则是：请求失败时显示错误，不显示成功确认；重新打开后保留原值。这为测试环境提供了具体失败场景。

再检查边界：关闭摘要不能阻止密码重置邮件，选择还必须跨新登录会话保留。它们是不同问题，应单列。

避免“所有边界都已处理”。写出重要情况，通常从什么会失败、什么不应受影响、以后会怎样三个问题开始。

若不能就结果达成一致，应在开发过深前记录未决问题。没有答案的问题不会因为进入清单就成为可用标准。

完整验收清单示例

以下是虚构事项第一份完整草案，每项结果都可独立验证。

• 打开账户设置时显示客户当前保存的每周摘要偏好。
• 关闭摘要并成功保存后，重新打开设置显示关闭。
• 开启摘要并成功保存后，重新打开设置显示开启。
• 成功保存后，退出并重新登录仍保留选择。
• 保存失败时显示错误、不显示成功确认，重新打开仍是旧值。
• 偏好关闭的客户不接收成功保存后新加入队列的每周摘要。
• 偏好开启的客户仍按现有调度规则接收下一份摘要。
• 关闭摘要不妨碍接收主动请求的密码重置邮件。

发送标准依赖已排队消息的范围决定。团队应把背景放在事项旁，避免审查者误以为设置会撤回正在发送的邮件。

还需可行的验证方式。团队要确定在测试环境中如何触发或观察摘要。即使文字清楚，没有相关账户或发送证据也难以验证。

录入前改进模糊标准

简短文字检查常能避免后续争论。逐项判断两个人是否会对“成功”有不同理解。

最后一项本身不证明可用性，只将模糊句子替换为有限而有用的检查。更广的易用性目标可能需要研究或多项观察。

也要小心虚构精度。“两秒内响应”看似可测，却是真实承诺。加入性能阈值前应约定条件和理由。

将标准放入 Power Pack

打开 Definition of Done & AC，选择 Acceptance Criteria。它与 Definition of Done 独立，输入前先确认标签。

单项可输入标题，再点 Add 或按 Enter。保持简洁但不丢失结果。大量背景放在 Jira 描述或链接文档中。

多项可用 Bulk Import 粘贴 Markdown 列表，每项前加连字符和空格。也支持 Markdown 复选框。

导入后检查条目。操作是追加，重复导入会产生重复项。已勾选复选框会标为完成；除非当前事项已验证，应从未勾选开始。

条目错误时，先与团队约定新措辞，添加正确项，再通过确认提示删除旧项。若影响已定范围，相关讨论应清楚保留。

先验证，再标为完成

开发前请验证人员阅读标准，他们可能发现缺少初始条件，或现有测试配置无法观察结果。

开发后逐项验证，并按正常流程记录证据。通过后选择 Done；后来发现问题时再次点击，可恢复待办。

例如偏好能跨页面刷新保留，却在新登录时重置。重新打开标准可通过，会话持久性仍未完成。分开记录保留了这种重要区别。

Power Pack 跟踪清单完成，不运行测试，也不自动确认审查者。需要姓名或日期时，应在日常流程明确记录。

使用两个计数，但不要当作证明

两个标签分别显示完成数与总数。只有两份列表非空且所有条目完成，才显示 Ready for Release，否则是 In Verification。

这只是输入状态摘要，不能确认标准覆盖所有重要行为或证据可靠，也不强制 Jira 状态或阻止合并。

示例八项验收全通过时，Definition of Done 中支持说明仍可能未完成。功能结果通过了，但团队整体完成约定还有缺口。

从即将开展的事项开始，写客户结果，约定条件，再把标准与共享 Definition of Done 一起放入 Power Pack，与开发和验证人员审阅。收益是减少看似显然的句子背后的隐含假设。

• Atlassian — 什么是验收标准？