在敏捷开发的领域中，清晰度是成功的关键。当团队开始开发新功能时，基础在于用户故事。然而，用户故事仅仅是一个对话的占位符。要将这一对话转化为可工作的产品，需要两个关键的产物：验收标准和完成定义。这些概念起到了保障作用，确保质量、一致性和可预测性。
许多团队难以区分这两个概念。有时它们被当作同一事物处理，导致测试或部署阶段产生混淆。有时它们则被完全忽视，导致范围蔓延或不完整功能流入生产环境。本指南探讨了验收标准和完成定义的机制、目的与实施方法，帮助您的团队持续交付价值。
什么是用户故事？ 📝
在拆解故事的各个组成部分之前，必须先回顾用户故事的实际含义。在敏捷框架中，用户故事是从希望获得新功能的用户角度出发，对功能进行的简短而简单的描述。它通常遵循以下格式：
- 作为一个 [用户类型]，
- 我想要 [某个目标]，
- 以便 [某种好处]。
这种格式关注的是价值为用户提供的价值，而非技术实现。然而，仅靠这种格式不足以指导开发。它并未明确工作的边界或完成所需的标准。这正是验收标准和完成定义发挥作用的地方。
验收标准（AC）：完成的条件 ✅
验收标准是一组条件，用户故事必须满足这些条件，才能从产品负责人的角度被视为完成。它们定义了故事的边界，并清晰地说明了最终产品应有的样子。
验收标准的目的
验收标准在开发生命周期中发挥多种作用：
- 澄清： 它们消除了歧义。如果开发人员问：“悬停时按钮应该变绿色还是蓝色？”，验收标准应能给出明确答案。
- 测试： 它们充当测试用例。质量保证工程师利用这些条件来验证功能。
- 共识： 它们确保产品负责人和开发团队就该特定故事的“完成”标准达成一致。
良好验收标准的特点
有效的验收标准应具体、可衡量且无歧义。避免使用“用户友好”或“快速”等未定义指标的模糊术语。相反，应明确具体的行为。
- 原子性： 每个标准应仅针对一个需求。
- 可测试性： 必须能够通过通过或失败的结果来验证该标准。
- 独立性：标准不应依赖外部故事来验证。
- 相关性：关注用户价值，而非内部代码结构。
验收标准示例
考虑一个关于添加“忘记密码”功能的故事。以下是验收标准可能的样子：
- 当用户位于登录页面时，
当他们点击“忘记密码”链接时，
则他们将被重定向到密码恢复页面。 - 当用户输入有效的电子邮件时，
当他们提交表单时，
则会显示确认消息。 - 当用户输入无效的电子邮件时，
当他们提交表单时，
则会显示错误消息，指出电子邮件格式不正确。
这些示例遵循当/当/则结构（通常与Gherkin语法相关），这有助于提高清晰度，并与自动化测试框架保持一致。
完成定义（DoD）：质量门禁 🚧
虽然验收标准是针对单个用户故事的，但完成定义是一项全局标准，适用于所有冲刺或发布周期内的所有工作。它代表了任何工作增量被视为可交付的必要要求清单。
完成定义的目的
完成定义充当质量门禁。它确保技术债务不会累积，并且产品始终处于可发布状态。如果一个故事满足了其验收标准，但未满足完成定义，则不能标记为完成。
完成定义中常见的要素包括：
- 代码审查：所有代码必须至少由一位同行进行审查。
- 单元测试：自动化测试必须对新逻辑实现100%的覆盖率并通过。
- 文档： API 文档或用户指南已更新。
- 性能： 该功能满足最低加载时间要求。
- 可访问性： 该功能符合 WCAG 指南。
- 安全性： 未引入已知漏洞。
为什么完成定义很重要
如果没有完成定义，团队往往会陷入‘技术上已完成但实际并未就绪’的陷阱。一个功能可能根据验收标准正常运行，但它可能破坏了系统的其他部分，缺乏适当的文档，或引入安全风险。完成定义通过在整个待办事项列表中强制执行质量基准来防止这种情况发生。
验收标准与完成定义：关键区别 🆚
混淆常常产生，因为这两个概念都涉及‘完整性’。然而，它们的范围和所有权存在显著差异。理解这一区别可以防止开发人员、测试人员和产品负责人之间的不一致。
| 功能 | 验收标准 | 完成定义 |
|---|---|---|
| 范围 | 针对单个用户故事 | 适用于整个团队或项目 |
| 所有权 | 产品负责人和开发团队 | 整个开发团队 |
| 灵活性 | 根据需求每条故事进行变更 | 稳定，尽管可随时间更新 |
| 目的 | 定义功能需求 | 定义质量和非功能性标准 |
| 验证 | 根据用户需求进行功能测试 | 技术和流程验证 |
可以把验收标准想象成特定行程的目的地，而完成定义则是道路上每辆车都必须遵守的安全检查清单。
如何编写有效的验收标准 📝
编写验收标准是一项协作工作。它不应由产品负责人单独完成。最佳实践包括‘三友’概念，即产品负责人、开发人员和测试人员在细化过程的早期阶段共同协作。
步骤 1：明确用户目标
首先重述价值主张。用户正在解决什么问题？这能确保标准始终聚焦于用户体验，而非技术细节。
步骤 2：定义正面和负面场景
不要只写顺利的情况。要考虑事情出错时会发生什么。
- 顺利路径： 用户按照预期执行操作。
- 边界情况： 特殊字符、缺失数据或慢速连接时会发生什么？
- 负面路径： 系统如何优雅地处理无效输入？
步骤 3：使用清晰的语言
尽可能避免使用术语。如果必须使用技术术语，请确保它们已被定义。使用主动语态。例如，“系统应验证……”不如“用户收到错误消息……”更清晰。
步骤 4：优先排序
如果故事较大，请将其拆分。验收标准应在冲刺周期内可完成。如果标准暗示的工作无法在冲刺内完成，故事就需要拆分。
如何建立一个稳健的完成定义 🛠️
完成定义不是一份静态文档。随着团队的成长和技术的变化，它会不断演进。它应该对所有人可见，通常展示在实体或数字看板上。
步骤 1：征求团队意见
完成定义由实际执行工作的团队负责。开发人员、测试人员和设计师都应参与列表的制定。如果开发人员添加了要求，他们更有可能遵守。
步骤 2：对要求进行分类
将完成定义的项目按逻辑类别分组，使检查清单更易于管理。
- 代码质量： 代码检查通过，无警告，同行评审已完成。
- 测试： 单元测试已编写，集成测试通过，手动测试已验证。
- 部署： 已部署到预发布环境，冒烟测试通过。
- 文档： Readme 已更新，API 文档已同步。
步骤3：将其设为硬性停止点
如果一个故事未达到完成标准（DoD），就不能关闭。这需要纪律性。虽然很容易说“我们稍后再修复文档”，但这会带来技术债务。故事必须一直保留在“进行中”状态，直到满足完成标准。
步骤4：回顾与优化
在回顾会议中，向团队提问：“我们的完成标准是否发现了任何问题？”或“我们是否一直遗漏某个需求？”根据这些洞察更新完成标准。
需要避免的常见错误 ⚠️
即使经验丰富的团队在实施这些实践时也会犯错。意识到常见的陷阱可以节省大量时间和困扰。
1. 模糊的验收标准
像“系统应该安全”这样的标准毫无意义，因为它不可测试。应明确为：“系统必须为管理员账户要求多重身份验证。”
2. 完成标准沦为形式化检查
如果团队只是勾选完成标准的框而没有真正完成工作（例如跳过代码审查），完成标准就失去了意义。完成标准必须被尊重，而不仅仅是被阅读。
3. 过度复杂化完成标准
一个包含50项的完成标准会令人不堪重负。应聚焦于关键的质量关卡。如果某个要求很少被违反，它可能更适合作为指导原则，而非硬性完成标准项。
4. 忽视非功能性需求
团队通常过于关注验收标准（功能性）而忽视完成标准（非功能性）。性能、安全性和可访问性是完成标准的一部分，而非验收标准。忽视这些会导致功能可用但运行缓慢或不安全。
5. 在缺乏团队共识的情况下制定完成标准
如果产品负责人在没有开发人员参与的情况下制定完成标准，团队可能会抵制。完成标准必须是团队共同达成的协议。
融入工作流程 🔄
验收标准和完成标准应融入开发生命周期的每个阶段，而不仅仅是在最后。
细化阶段
在待办事项列表细化阶段，产品负责人起草验收标准。团队会审查这些标准，以确保它们可测试且可行。问题在此阶段提出并解答，而不是在冲刺期间。
冲刺计划
在承诺故事时，团队需确认验收标准清晰明确。如果不够清晰，该故事就不适合进入冲刺。
开发阶段
开发人员编写代码以满足验收标准。同时，他们确保遵守完成标准（例如编写测试、请求代码审查）。
测试阶段
质量保证工程师将验收标准与已构建的功能进行核对。他们同时验证完成标准（例如检查代码覆盖率报告、可访问性扫描）。
评审与关闭
在将故事移至“已完成”之前，团队需确认验收标准和完成标准均已满足。如果未满足，该故事将返回队列。
衡量成功 📊
如何判断你的验收标准和完成标准是否有效？需要持续跟踪相关指标。
- 缺陷率：生产环境中发现的缺陷是否在减少？一个强有力的完成定义（DoD）应在发布前发现并解决这些问题。
- 拒绝率：用户故事是否经常被产品负责人拒绝？这表明验收标准（AC）定义不清晰。
- 速度稳定性：团队的速度是否保持稳定？如果用户故事因缺少完成定义（DoD）的项目而频繁被退回，速度将出现波动。
- 部署频率：清晰的完成定义（DoD）是否能实现更顺畅、更频繁的部署？
常见问题 ❓
以下是一些团队在实施这些标准时经常提出的问题。
问：验收标准可以在冲刺期间更改吗？
答：理想情况下，不应更改。如果验收标准发生重大变化，可能表明在细化阶段对故事理解不充分。轻微澄清是可以接受的，但重大范围变更应导致创建新故事或调整冲刺范围。
问：每个故事都需要一个独特的完成定义吗？
答：不需要。完成定义（DoD）是全局性的。然而，某些特定技术故事可能需要为该特定条目添加额外要求，但基础的完成定义适用于所有故事。
问：如果团队对完成定义（DoD）存在分歧怎么办？
答：组织一次讨论。目标是达成共识。如果开发人员坚持某项要求，而测试人员不同意，应讨论相关风险。如果风险较低，可以放弃该要求；如果风险较高，则应保留。
问：验收标准应详细到什么程度？
答：详细到足以被测试。如果质量保证工程师能直接根据验收标准编写测试用例，说明其已足够详细。如果他们仍需提问，则需要更详细的描述。
问：自动化测试能否替代完成定义（DoD）中的手动测试？
答：视情况而定。对于关键逻辑，可以；但对于用户体验或视觉元素，仍可能需要手动验证。完成定义（DoD）应体现质量保证的最佳实践。
关于质量与对齐的最后思考 🌟
实施验收标准和完成定义并非形式主义；而是出于尊重。这是对期望功能正常运行的用户的尊重，对希望获得清晰需求的开发者的尊重，也是对需要交付信心的产品负责人的尊重。
当这两个概念被正确使用时，它们为团队创造了共同的语言。它们减少了频繁澄清会议的需求，防止技术债务的积累，最重要的是，确保每个完成的故事都为产品带来真实价值。
从小处着手。定义一个基础的完成定义（DoD）。为下一个故事写出清晰的验收标准（AC）。在下一次回顾会议中进行评审。随着时间推移，这些实践将变得自然而然，融入团队文化。最终结果是持续产出高质量的软件，满足使用者的需求。