验收标准：5 种格式以及破坏它们的结构陷阱

如果用户故事是被最多跳过的敏捷制品，那么验收标准就是被最多跳过的 部分 用户故事。大多数团队编写标题和描述，然后在没有明确标准的情况下发布“完成”的含义。然后，当 QA 拒绝时，或者当利益相关者演示工程师认为他们不需要的东西时，他们会感到惊讶。

这是实用指南。五种验收标准格式，每种格式都适合，以及大多数团队标准失败的结构性原因。

验收标准实际上是什么

一个用户故事说 什么 和 为什么。验收标准说 我们如何知道它已经完成.

没有他们，“完成”就得事后协商；通常是在工作之后，通常是在冲刺之后。与他们一起进行谈判 之前 任何人都会编写代码。

您的团队缺少验收标准的信号：

• 工单因缺少无人讨论的范围而在审核中被拒绝。
• “但我没有意识到我们需要那个”，这是回顾的说法。
• QA 发现的“错误”实际上是范围差距。
• 利益相关者问“完成了吗？”而工程师也无法干净利落地回答。

这四个中的三个是范围清晰度问题，而不是工程问题。

格式1：项目符号列表

通俗易懂的语言子弹。最常见的格式，最容易编写，最容易阅读。

故事：用户可以通过电子邮件重置密码

验收标准：

• 用户在重置页面输入电子邮件
• 如果电子邮件与帐户匹配，系统会发送重置电子邮件
• 无论电子邮件是否匹配（无枚举），系统都会显示相同的消息（“检查您的电子邮件”）
• 重置链接将在 24 小时后过期
• 重置链接仅工作一次

在以下情况下使用它：标准是独立的并且故事很小。大多数故事都适合这里。

在以下情况下跳过它：行为取决于上下文（输入 X 给出输出 Y），或者标准相互交互。

陷阱：作者陷入“系统应……”的规范语言。不。验收标准是预先对话，而不是合同文件。

格式 2：给定/何时/那么（小黄瓜）

借用了 BDD 框架（Cucumber 等）。强制进行明确的场景思考。

场景：电子邮件与现有帐户匹配
假设存在一个电子邮件地址为“[email protected]”的用户
当用户请求“[email protected]”重置密码时
然后重置电子邮件将发送到该地址
系统显示“检查您的电子邮件”

场景：电子邮件与任何帐户都不匹配
鉴于没有用户有电子邮件“[email protected]”
当有人请求重置“[email protected]”的密码时
然后没有发送电子邮件
系统显示“检查您的电子邮件”（相同的消息）

场景：重置链接被重复使用
假设成功点击了有效的重置链接
当再次单击同一链接时
然后用户会看到“此链接已被使用”

在以下情况下使用它：行为因输入或状态而异。该格式使分支明确。

在以下情况下跳过它：故事是一件简单的事情（使用有效凭据登录）。小黄瓜增加了仪式感，但没有为琐碎的案件增加清晰度。

陷阱：大多数团队过度使用小黄瓜。他们用小黄瓜格式列出了一系列事实，但实际上并不是场景。三个给定，没有何时，没有那时；这只是假装的项目符号列表。

格式 3：示例表

当故事是“计算这 N 个输入的正确值”时，表格胜过散文。

故事：按年计费与按月计费的定价

计划	座位数	期限	预计总数
专业版	1	每月	£5
专业版	5	每月	£25
专业版	1	年度	50 英镑（60 英镑 - 10 英镑折扣）
专业版	5	年度	250 英镑（300 英镑 - 50 英镑折扣）
专业版	0	要么	拒绝；无效

在以下情况下使用它：工作是具有多个输入案例的查找、计算或转换。定价、税收、权限矩阵、验证规则。

在以下情况下跳过它：行为不能简化为一行。

陷阱：编写者列出快乐路径行并跳过边界。有趣的情况是空输入、最大值、负数、无效货币。如果您的表有 4 个快乐行和零个边缘行，则条件不完整。

格式4：验收测试清单

每个标准都是工作结束后将存在的测试的标题。

故事：冲刺产能尊重假期

要通过的测试：

• capacity_calculator_excludes_holidays
• capacity_calculator_handles_partial_day_holidays
• capacity_calculator_uses_team_timezone_for_holiday_resolution
• capacity_calculator_returns_zero_when_all_days_are_holidays
• capacity_calculator_warns_when_more_than_50_percent_of_sprint_is_holiday

在以下情况下使用它：团队首先编写测试，或者“完成”被证明是自动化的。对于没有 UI 界面的后端故事特别有用。

在以下情况下跳过它：该工作是探索性的、设计性很强的，或者还没有可测试的断言。

陷阱：并非每个故事都有有意义的自动化测试。将这种格式强加到 UI 抛光的故事上就是戏剧。

格式 5：完成的定义 + 故事特定的增量

对于成熟的团队：不要在每个故事上重复相同的标准（测试、代码审查、文档更新）， 团队的 完成的定义涵盖了它们。该故事仅列出具体内容 这个 故事。

特定于故事的验收标准：

• 速率计算器处理 0 速率冲刺而不除以零
• 当速率差异很大时，冲刺 预测器使用中位数，而不是均值
• 两个计算器都显示基础数字，而不仅仅是结果

（标准 DoD 适用；测试、审查、部署、文档、可访问性检查。）

适用情况：团队已有实际执行的完成定义（DoD）。（参见 已完成工程的定义 和 完成定义（DoD）生成工具.)

以下情况不适用：团队的完成定义（DoD）只是理想目标，而没有实际执行。不要引用未作为合并门槛的完成定义。

陷阱：故事 仅 “参见完成定义（DoD）”并且没有特定于故事的标准。这意味着这项工作实际上还没有被定义；这只是“做事”。

如何选择格式

大多数故事不需要格式对话。大多数故事都需要子弹。仅当子弹无法承载负载时才选择非子弹格式：

• 分支行为 → 小黄瓜
• 查找或计算→表格
• 后端重/测试优先 → 测试列表
• 成熟的团队和稳定的 DoD → DoD + delta

在一个故事中混合使用格式是可以的。一个故事可以有三个项目符号和一个小示例表。

五种反模式

大多数标准失败与格式无关。它们是结构性的。

1. 重述标题

故事： 用户可以登录

验收标准：

• 用户可以登录

零添加信息。标准必须定义 什么算登录;接受凭据、设置会话、发生重定向；或者是噪音。

2. 伪装成标准的实施步骤

验收标准：

• 添加一个 password_resets 表
• 添加一个 PasswordResetsController
• 添加一个 PasswordResetMailer

这些是任务，而不是标准。标准描述结果；任务描述了工作。如果团队明天选择不同的实现（第三方身份验证提供商），则该标准应该仍然有效。实施任务属于单独的清单或工程师的待办事项，而不属于验收标准。

3. 无法测试的标准

• 系统应该很快
• 用户界面应该看起来很专业
• 代码应该干净

如果您不能同意是否满足，那么它就不是一个标准。 “第 95 个百分点的页面加载时间不到 200 毫秒”是可测试的。 “应该快”是一厢情愿的想法。

4. 隐藏标准

评审员说，工程师交付了，“但它也应该处理 X”，而 X 从未被写下来。如果 X 很重要，那么它就是一个标准。如果 X 不够重要，无法写下来，它就不会阻止合并。

解决方法：当审阅者要求 X 时，要么 (a) 拒绝该请求，因为标准未提及 X，要么 (b) 接受 X 但将其添加到标准中，以便下一个故事的下一个审阅者知道栏已移动。不要让酒吧静静地漂移。

5. 工作开始后添加的标准

工程师开始工作两天
“等等，我们可以添加一些验收标准吗？”

如果标准在工作开始后出现，那么它们是对已经建造的东西的观察，而不是关于建造什么的合同。要么追溯确认已经完成的工作（很好，但承认这一点），要么在工作中扩大范围（不好；推迟到新的故事）。

结构性修复：拒绝无标准开工。细化是它们被写入的地方。 （参见 待办事项细化操作手册.)

五分钟规则

如果一个正常大小的故事的接受标准需要五分钟以上的时间来编写，那么这个故事太大或不清晰。标准编写过程是对故事本身的质量检查。

如果您仍然需要 30 分钟：

• 这个故事是一部伪装的史诗（分裂它）
• 团队不理解需求（更多细化，更少打字）
• 这些标准用于与棘手的利益相关者就范围进行诉讼（流程问题，而不是写作问题）

一个小而清晰的故事应该能够快速产生明确的标准。如果没有，问题就出在上游。

验收标准如何与系统的其余部分相互作用

• 故事预估： 分数应反映书面标准。如果标准在冲刺中期扩大，那么分数是错误的，而不是团队错误。 （参见 故事点估计.)
• 完成的定义： 适用于每个故事的团队范围的大门。标准是特定于故事的。两者并不重叠；他们堆叠起来。
• 冲刺目标： 标准定义了一个故事何时完成。冲刺目标定义了何时 冲刺 交付了一些连贯的东西。 100% 满足标准但没有冲刺目标进展的冲刺是糟糕的冲刺计划，而不是糟糕的标准。
• 回顾： 如果同一种标准在一个又一个的冲刺中被错过（用户体验优化、可访问性、错误状态），那么它属于团队的 DoD，而不是每个故事。

最低可行的验收标准

如果您的团队目前没有，请从这里开始：

1. 每个故事都至少有一个要点来具体说明“工作”是什么样子。
2. 每个故事都至少有一个关于边缘情况的项目符号（空输入、错误状态、明显但被跳过的情况）。
3. 每个故事都至少有一个要点说明用户如何知道它成功了。

三颗子弹。五分钟。在前两个冲刺中发现了大部分“我不知道我们需要那个”的抱怨。

两个月后，仅在简单项目符号无法承载负载的情况下升级格式。

底线

验收标准并不符合要求。这是团队和请求者就“完成”的含义达成一致的方式 之前 工作开始，因此工作在交付后不会被重新定义。

不要写超出故事需要的内容。不要写得少于故事的需要。五分钟规则和最少三颗子弹可以让大多数球队赶上。

当你毕业时，围绕以下内容制定标准： 善良 这是故事，而不是围绕你的培训课程所教的内容。