验收标准
定义用户故事"完成"的精确、可测条件。
为什么
验收标准是唯一让"完成"对 PM、工程师、QA 意思相同的东西。没有它，"完成"是凭感觉，功能带着未测边界和未测性能就被标完成。写成 Given/When/Then 时，标准可直接转成自动测试，闭合规格与验证的环。没有验收标准的故事无法估时、测试或签字——它只是个愿望。
何时使用
估时前，作为每个用户故事的一部分。每条 10-15 分钟。永远不要跳过——无标准的故事没准备好进迭代。
如何做
1. 为每个用户故事列 3-7 条"完成"必须全真的标准 2. 每条写成 Given/When/Then： - Given [前置条件/状态] - When [用户动作] - Then [可观察结果] 3. 至少含一条负面路径（错误/非法输入时怎样） 4. 面向用户的故事至少含一条性能标准 （如"100 并发用户下响应 < 200ms"） 5. 和 QA 评审标准——他们据此写测试，歧义 = bug 6. 标准在迭代规划时冻结；迭代中变更需重新规划
示例
故事：作为计费所有者，我想要下载发票 CSV。 验收标准： 1. Given 我有 50 张发票，When 我点"导出 CSV"， Then 3 秒内下载含全部 50 行的文件。 2. Given 我有 0 张发票，When 我点"导出 CSV"， Then 我看到"无可导出发票"且无文件下载。 3. Given CSV 已生成，Then 列精确匹配 QuickBooks schema（日期、金额、状态、描述）。 4. Given 非计费所有者，When 访问导出 URL， Then 收到 403 且不生成文件。
常见问题
- ⚠把标准写成能力（"导出能用"）而非可观察条件——QA 测不了"能用"。
- ⚠漏掉负面/错误路径——80% 的 bug 在顺利路径标准忽略的边界里。
最佳实践
- ✓每故事 3-7 条标准——更少说明规格不足，更多说明太大。
- ✓让 QA 共写标准而非只评审——他们用测试用例思维，能抓 PM 漏的缺口。