研发需求的验收标准应该怎么写？

用户故事要经过 DoR 的考验才能被研发团队接受，只有扛住 DoD 的考核才能迈出走向客户第一步。在敏捷开发中，想要评估一个故事是否达到客户对需求的期待，就要让它去接受「验收标准」的考验：用户故事必须「通过」所有的验收标准，才算是真正地产生价值。

DoD 是对迭代中「所有」工作事项或用户故事的「基本要求」，而验收标准则是对「特定」用户故事的「需求细节」进行的逐一验证。

一个工作项目是否能如质如期地完成，最重要的部分就取决于开工前是否有明确的「验收标准」。

一、 验收标准的目的

---

01 描述明确的需求范围

通过对验收标准的讨论，团队可以了解产品负责人与利益关系人对需求的期待，也能更明确地掌握需求的范围，方便估计时程与测试涵盖范围。

02 描述错误的案例处理

编写验收标准条例可以全方位地考虑需求可能会出现的限制与错误情况，并延伸对应的处理方式。在开发过程中，实现快乐路径（Happy Path）相对简单，但「错误／例外处理」却常常被遗漏掉。

03 增加共识的讨论模式

透过对验收标准的讨论，产品负责人和开发团队能够一次又一次地理解需求目的，确保对需求持有相同的理解，才能在最后的展示阶段完整地呈现结果。

04 提早列举出测试案例

书写验收标准的过程也是测试人员和产品负责人向开发团队说明和同步测试最低标准的过程。这样才不会出现开发产出越过测试，或待测试项目未完成开发等情况。

05 时程工期的有效估计

只有完