特征
- 日常语言描述
- 捕获系统行为
- 个数有限
在故事基础部分，我提到用户故事通常是日常或者商务语言写成的句子，这些句子描述了用户在其工作职责范围内想要达成的某个目的以及达成该目的需要的功能（手段）。所以书写用户的故事的句式一般都是：As（用户的角色）... I Want（功能或手段）... So That（目的）。根据用户故事的 INVEST 划分原则中 N (Negotiated 可协商的) 原则，故事包含的是对需求的简短描述，具体的细节需要沟通产出，产出物表现为验收条件。
换言之，验收条件是在开发前的分析阶段输出的，它的作用是补充需求细节。更进一步，验收条件其实有力地消除了用户和开发人员之间的沟通鸿沟。为什么这么说呢？因为验收条件具备两点很重要的特征：
- 日常语言描述
- 捕获系统行为
这两点特征促进了参与各方在需求点上快速反馈，如下图：
验收条件-反馈环
在敏捷活动中高效地沟通一直被反复强调，因为不高效的沟通造成的信息误导和返工是精益生产活动中应当极力消除的，所以任何能够促进沟通的方式方法都值得提倡。
除此之外，有限的个数 (2-8 ACs/story) 也是验收条件的一个特征，这也是 INVEST 原则中 E (Estimable 可评估的) 所要求的。所以，也引出了验收条件的一个简明定义——用户故事的 DoD (Definition of Done)。也有人说，一组验收条件定义了用户故事的边界（Boundary）。如果任由用户故事自然“疯长”，范围无限放大，交付怕是遥遥无期。
验收条件会作为业务活动描述的一部分存在于用户故事中，一般会在开发之前准备就绪。在敏捷活动 kick-off 时，由业务分析师（BA）和开发人员（Dev），也可叫上质量保证师（QA）一起逐条澄清验收条件，以便保证开发之前达成共识，减少返工和浪费。在其它敏捷活动如：desk-checks, customer sign-off, UI testing, BDD 中也会重度参与。
格式
Given/When/Then
#Title
Given 用户触发操作之前处于的系统状态
When 触发系统结果的操作
Then 系统预期返回的结果
Verifiable checklists
e.g. [PhoneNumber] 只能包含0-9, +
反模式
模棱两可的陈述
Given: that I have the search page loaded
When: I perform a search
Then: the search results come back within a reasonable period of time
这里的 reasonable period of time 就是不可测试的，因为没有人可以决定什么才是 reasonable.
合理的改法是:
Given: that I have the search page loaded
When: I perform a search
Then: the search results come back within 5ms
5ms 之内，这是一个标量，完全可以衡量。
非系统交互
Given I have pulled my car up to the valet area
When I hand over my keys to the valet person
Then I receive a paper ticket from the valet person
And I am instructed to hold on to it so I can use it to retrieve my car later.
这里的所有描述都是对现实场景的描述，和系统并无关系，对于开发人员构建系统几乎没有丝毫帮助。这种反模式的修正方法是剔除那些系统的验收条件，重新梳理用户故事。
非系统输出
Given: that I am on the home page
And: I am logged in
When: I navigate to account preferences
Then: I can see my account preferences
这里的 I can see my account preferences 是无法进行断言的，因为这是系统无关的，说得极端些，假如用户闭上眼睛，这个功能就没法通过验收了。
合理的改法是：
Given: that I am on the home page
And: I am logged in
When: I navigate to account preferences
Then: my account preferences are displayed
这个时候，我可以检查系统展示了我的用户页面。
when 隐藏到 given
Given: that I am on the homepage
And: I navigate to the search
When: I look at the page
Then: the search options are displayed
基本上，这是团队编写 AC 时最容易犯的错误，操作出现在前置条件中，when 中反而不是系统行为了。
合理的改法是：
Given: that I am on the homepage
When: I navigate to the search
Then: the search options are displayed
最佳模式
1. 可读的
我们希望业务人员审阅和修正验收条件，如果写的内容只有开发人员能懂，我们就失去了获得反馈的机会。使用上述书写格式，可以提高可读性。
Given: that my mobile phone is switched on
And: I have sufficient signal to make a call
When: I dial a number
Then: I am connected to the person I want to talk to
And: incoming calls are diverted to my voicemail
2. 可测试的
参见反模式中合理改法。
3. 实现无关的
验收条件应该是实现无关的，它和用户故事一样，是给业务和开发人员提供交流凭证的一种工具，所以它应该聚焦于功能，而不是功能的展现形式。
Given: that I am on the home page
And: I am logged in
When: I navigate to advanced search
Then: the advanced search web page must be displayed
And: a text box labelled "Name" is displayed
And: a text box labelled "Description" is displayed
And: a command button named "Search" is displayed
这里已经框死了必须要使用 text box 实现展示功能，而实际上其背后真正的意图是通过属性字段进行搜索，隐藏了业务含义的验收条件是不可取的。
合理的改法是：
Given: that I am on the home page
And: I am logged in
When: I navigate to advanced search
Then: the advanced search is displayed
And: an option to search by name is displayed
And: an option search by description is displayed
And: the advanced search is displayed in accordance with the attached wireframe
换句话说，验收条件本身不应该关注于展现形式，当然，为了便于理解，wireframe 是提供直观素材的更好的方式。
练习
用户故事
作为一名管理员
我想要把一名员工加入系统中
以便管理他们的权限
分析步骤
1. 定义边界
- 触发添加员工操作
- 输入员工的详情
- 验证遗漏或者错误的字段
- 保存
2. 提炼和细化
- 触发添加员工操作
假如我进入了员工管理系统
当我进入员工的浏览页
之后添加员工的操作出现在页面上
2. 输入员工的详情
假如添加员工的操作出现在浏览页
当我调用了添加员工的操作
那么我可以输入员工的姓名和出生日期
并且出现了保存操作
3. 验证遗漏的字段
假如我没有填写员工的姓名和/或生日
当我尝试保存
那么保存不会成功
并且会有消息显示遗漏的字段
4. 验证错误的生日日期
假如我正在添加一名员工的详情
并且我输入了未来或者早于1900年的日期，或者错误的日期格式
当我尝试保存
那么保存不会成功
并且会有消息显示输入的生日日期无效
验证列表：
[日期格式] yyyy/MM/dd
5. 保存
假如我正在添加一名员工的详情
并且我输入了有效的生日和姓名
当我尝试保存
那么会有消息显示保存成功
并且包含该员工详情的页面会呈现
并且详情中的生日和姓名和之前输入的一致
警告
验收条件并不是唯一澄清和约束用户故事的方式！任何可以提升理解和降低沟通成本的方式方法都值得尝试。比如：用户偏好 —— 希望使用下拉框而不是复选框，往往可以通过添加一条记录在故事中补充这部分信息。另外，一个完整的故事最好能附上线框图，一图胜千言。
进一步阅读
[1] 敏捷团队工作流
网友评论