特征
- 日常語言描述
- 捕獲系統(tǒng)行為
- 個數(shù)有限
在故事基礎(chǔ)部分，我提到用戶故事通常是日?；蛘呱虅?wù)語言寫成的句子，這些句子描述了用戶在其工作職責(zé)范圍內(nèi)想要達成的某個目的以及達成該目的需要的功能（手段）。所以書寫用戶的故事的句式一般都是：As（用戶的角色）... I Want（功能或手段）... So That（目的）。根據(jù)用戶故事的 INVEST 劃分原則中 N (Negotiated 可協(xié)商的) 原則，故事包含的是對需求的簡短描述，具體的細節(jié)需要溝通產(chǎn)出，產(chǎn)出物表現(xiàn)為驗收條件。
換言之，驗收條件是在開發(fā)前的分析階段輸出的，它的作用是補充需求細節(jié)。更進一步，驗收條件其實有力地消除了用戶和開發(fā)人員之間的溝通鴻溝。為什么這么說呢？因為驗收條件具備兩點很重要的特征：
- 日常語言描述
- 捕獲系統(tǒng)行為
這兩點特征促進了參與各方在需求點上快速反饋，如下圖：
在敏捷活動中高效地溝通一直被反復(fù)強調(diào)，因為不高效的溝通造成的信息誤導(dǎo)和返工是精益生產(chǎn)活動中應(yīng)當(dāng)極力消除的，所以任何能夠促進溝通的方式方法都值得提倡。
除此之外，有限的個數(shù) (2-8 ACs/story) 也是驗收條件的一個特征，這也是 INVEST 原則中 E (Estimable 可評估的) 所要求的。所以，也引出了驗收條件的一個簡明定義——用戶故事的 DoD (Definition of Done)。也有人說，一組驗收條件定義了用戶故事的邊界（Boundary）。如果任由用戶故事自然“瘋長”，范圍無限放大，交付怕是遙遙無期。
驗收條件會作為業(yè)務(wù)活動描述的一部分存在于用戶故事中，一般會在開發(fā)之前準(zhǔn)備就緒。在敏捷活動 kick-off 時，由業(yè)務(wù)分析師（BA）和開發(fā)人員（Dev），也可叫上質(zhì)量保證師（QA）一起逐條澄清驗收條件，以便保證開發(fā)之前達成共識，減少返工和浪費。在其它敏捷活動如：desk-checks, customer sign-off, UI testing, BDD 中也會重度參與。
格式
Given/When/Then
#Title
Given 用戶觸發(fā)操作之前處于的系統(tǒng)狀態(tài)
When 觸發(fā)系統(tǒng)結(jié)果的操作
Then 系統(tǒng)預(yù)期返回的結(jié)果
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 之內(nèi)，這是一個標(biāo)量，完全可以衡量。
非系統(tǒng)交互
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.
這里的所有描述都是對現(xiàn)實場景的描述，和系統(tǒng)并無關(guān)系，對于開發(fā)人員構(gòu)建系統(tǒng)幾乎沒有絲毫幫助。這種反模式的修正方法是剔除那些系統(tǒng)的驗收條件，重新梳理用戶故事。
非系統(tǒng)輸出
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 是無法進行斷言的，因為這是系統(tǒng)無關(guān)的，說得極端些，假如用戶閉上眼睛，這個功能就沒法通過驗收了。
合理的改法是：
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
這個時候，我可以檢查系統(tǒng)展示了我的用戶頁面。
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 時最容易犯的錯誤，操作出現(xiàn)在前置條件中，when 中反而不是系統(tǒng)行為了。
合理的改法是：
Given: that I am on the homepage
When: I navigate to the search
Then: the search options are displayed
最佳模式
1. 可讀的
我們希望業(yè)務(wù)人員審閱和修正驗收條件，如果寫的內(nèi)容只有開發(fā)人員能懂，我們就失去了獲得反饋的機會。使用上述書寫格式，可以提高可讀性。
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. 實現(xiàn)無關(guān)的
驗收條件應(yīng)該是實現(xiàn)無關(guān)的，它和用戶故事一樣，是給業(yè)務(wù)和開發(fā)人員提供交流憑證的一種工具，所以它應(yīng)該聚焦于功能，而不是功能的展現(xiàn)形式。
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
這里已經(jīng)框死了必須要使用 text box 實現(xiàn)展示功能，而實際上其背后真正的意圖是通過屬性字段進行搜索，隱藏了業(yè)務(wù)含義的驗收條件是不可取的。
合理的改法是：
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
換句話說，驗收條件本身不應(yīng)該關(guān)注于展現(xiàn)形式，當(dāng)然，為了便于理解，wireframe 是提供直觀素材的更好的方式。
練習(xí)
用戶故事
作為一名管理員
我想要把一名員工加入系統(tǒng)中
以便管理他們的權(quán)限
分析步驟
1. 定義邊界
- 觸發(fā)添加員工操作
- 輸入員工的詳情
- 驗證遺漏或者錯誤的字段
- 保存
2. 提煉和細化
- 觸發(fā)添加員工操作
假如我進入了員工管理系統(tǒng)
當(dāng)我進入員工的瀏覽頁
之后添加員工的操作出現(xiàn)在頁面上
2. 輸入員工的詳情
假如添加員工的操作出現(xiàn)在瀏覽頁
當(dāng)我調(diào)用了添加員工的操作
那么我可以輸入員工的姓名和出生日期
并且出現(xiàn)了保存操作
3. 驗證遺漏的字段
假如我沒有填寫員工的姓名和/或生日
當(dāng)我嘗試保存
那么保存不會成功
并且會有消息顯示遺漏的字段
4. 驗證錯誤的生日日期
假如我正在添加一名員工的詳情
并且我輸入了未來或者早于1900年的日期，或者錯誤的日期格式
當(dāng)我嘗試保存
那么保存不會成功
并且會有消息顯示輸入的生日日期無效
驗證列表：
[日期格式] yyyy/MM/dd
5. 保存
假如我正在添加一名員工的詳情
并且我輸入了有效的生日和姓名
當(dāng)我嘗試保存
那么會有消息顯示保存成功
并且包含該員工詳情的頁面會呈現(xiàn)
并且詳情中的生日和姓名和之前輸入的一致
警告
驗收條件并不是唯一澄清和約束用戶故事的方式！任何可以提升理解和降低溝通成本的方式方法都值得嘗試。比如：用戶偏好 —— 希望使用下拉框而不是復(fù)選框，往往可以通過添加一條記錄在故事中補充這部分信息。另外，一個完整的故事最好能附上線框圖，一圖勝千言。
進一步閱讀
[1] 敏捷團隊工作流
