用户故事要通过 DoR 的考验能力被研发团队承受，只有扛住 DoD 的考核能力迈出走向客户第一步。点击理解 DoD 和 DoR：如何消减麻利开发中的「认知偏差」？
在麻利开发中，想要评估一个故事是否达到客户对需要的期待，就要让它去承受「验收规范」的考验：用户故事必须「通过」所有的验收规范，才算是真正地产生价值。
DoD 是对迭代中「所有」工作事项或用户故事的「根本要求」，而验收规范则是对「特定」用户故事的「需要细节」进行的逐个验证。
一个工作我的项目是否能如质如期地实现，最重要的局部就取决于动工前是否有明确的「验收规范」。
一、验收规范的目标
01 形容明确的需要范畴
通过对验收规范的探讨，团队能够理解产品负责人与利益关系人对需要的期待，也能更明确地把握需要的范畴，不便预计时程与测试涵盖范畴。
02 形容谬误的案例解决
编写验收规范条例能够全方位地思考需要可能会呈现的限度与谬误状况，并延长对应的解决形式。在开发过程中，实现高兴门路（Happy Path）绝对简略，但「谬误/例外解决」却经常被遗漏掉。
03 减少共识的探讨模式
透过对验收规范的探讨，产品负责人和开发团队可能一次又一次地了解需要目标，确保对需要持有雷同的了解，能力在最初的展现阶段残缺地出现后果。
04 提前列举出测试案例
书写验收规范的过程也是测试人员和产品负责人向开发团队阐明和同步测试最低标准的过程。这样才不会呈现开发产出越过测试，或待测试项目未实现开发等状况。
05 时程工期的无效预计
只有实现验收规范的探讨后，开发团队能力更好地明确需要和测试的范畴，对需要开发做出更精确的预计，其中包含工夫、人力的相对预计，以及点数、大小的绝对预计。
二、验收规范的写法
常见验收规范的写法有三种，别离是情景式、规定式和习惯式。
01 情境式写法 Scenario-based
「情境式写法」是面向场景的，其信息形容最为残缺，也因而在麻利团队中被更宽泛地流传和利用。
情境式写法的构造蕴含了以下五个元素，传递了「测试用例」和「价值交付」两方面信息。
- 情境 Scenario：形容用户应用的场景/情景
- 假设 Given：形容验收规范的事后设定条件
- 当 When：形容用户在什么状况/操作下
- 而后 Then：形容预期会产生的后果
- 而且 And：形容预期会产生的更多后果
举个例子阐明一下：
情境 用户帐号登录
Given 用户进入「账号登录」页面，
When 用户输出谬误的用户名或登录明码时，
Then 登录页面会弹出「明码谬误」的提醒，
And 登录页面也会出现「遗记明码」跳转入口。
02 规定式写法 Rule-based
「规定式写法」是用条列的形式列出所有须要验证的测试案例，通常是一份清单模式的文件。相比情景式写法，规定式的验收规范能笼罩更多、更广的测试范畴，但也省略了对需要价值的形容和阐明。
测试案例「用户账号登录」的验证规定如下：
- 用户输出正确的账号、明码时，能够登入账号页面查看账号信息；
- 用户输出存在的账号、谬误的明码时，须要呈现提示信息「明码谬误」；
- 用户输出不存在的账号时，须要呈现提示信息「该账号不存在」；
- 用户间断输出谬误的明码超过三次时，须要呈现提示信息「明码已谬误三次，请重设明码（附跳转）」。
03 用户角度的习惯写法 Customer-based
有些测试人员可能会用 流程图、思维导图、检核表 等形式书写验收规范，但写法不是重点，能分明出现「验收规范」，阐明客户需要冀望的就是好办法。
三、验收规范的八点误区
- 工作我的项目实现后才进行验收规范的探讨。
- 验收规范事无巨细，繁多性能就有不同组合的测试。
- 验收规范范畴太广，曾经超过本次要进行的范畴。
- 验收规范不是用户看到的情境，而是底层的技术细节。
- 团队对验收规范还没有达成共识就开始工作。
- 验收规范无奈独立，须要其余验收规范的配合能力进行测试。
- 测试的条件是充斥变数的，无奈模仿的。
- 只由测试人员或产品负责人单向设计出的验收规范，开发团队事先不知情。
原文作者：Vince Huang
文章起源：Medium【文思不藏私】专栏
理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。