本文翻譯自 Clear Acceptance Criteria for User Stories with Examples
在一個理想的完美的世界之中，人們之間的相互理解會很簡單快捷，不會產(chǎn)生困惑。但是，在現(xiàn)實世界中，我們不得不去找到一種清晰的溝通方式，這樣，對方就不會產(chǎn)生誤解。
在軟件開發(fā)中，AC可以幫助我們獲知客戶的對產(chǎn)品的期望。像是諸如“我想要一個牛掰的APP，并且在人群中非常的火爆”這種AC，并不能帶給我們太多的東西。通過對每個user story定義一個清晰的AC，可以減少客戶和開發(fā)團隊之間的誤解。
在這篇文章中，我們會討論在敏捷方法（例如Scrum和 Kanban）中的AC，并且給出一些比較好的AC的例子。
在2020年，Scrum，user stories 和acceptance criteria不再僅僅是流行語
我們在之前已經(jīng)提到Scrum過了。Scrum是一個敏捷框架，幫助軟件開發(fā)團隊完成任意復雜度軟件的開發(fā)。
你可以從這里找到更多關于Scrum的消息。
在Scrum（或者其他的敏捷方法）中，我們使用 user story 和AC等概念來確保對于終端用戶如何使用APP和開發(fā)團隊如何滿足每一個需求有一個清晰的描述。
當我們開始創(chuàng)建一個產(chǎn)品，我們跟客戶合作來定義user story。user story使用下面的格式來寫：
作為一個（用戶的類型），我想要（做一些事情）以便我能（實現(xiàn)一些目標/獲得一些結果/得到一些有價值的東西）。
user story的目的是解釋用戶在系統(tǒng)中的角色，他們想要的活動，他們想要完成什么。對于敏捷團隊，user story是識別他們的需求的最簡單的方法。
定義AC
那么，我們要怎么確保一個user story被正確地完成了，并且滿足了客戶的要求。這就是為什么要有AC。AC是一系列要求的列表，保證user story被完成，并且所有的場景都被考慮到。簡而言之，AC明確了在哪些條件下user story是被滿足的。簡潔書面標準幫助開發(fā)團隊能夠避免對客戶需求的歧義和溝通上的錯誤。
AC是非常重要的，不僅僅體現(xiàn)在使你能夠以客戶的角度看待產(chǎn)品，還體現(xiàn)在開發(fā)流程上。不同的人會在不同的角度上看待同一個問題，這是很自然的事情。明確的書面標準能夠給你要實現(xiàn)的功能一個簡單的解決方案。
AC的作用
定義邊界。AC幫助開發(fā)團隊定義user story的邊界。換句話說，AC可以幫助你確認，當功能跟我們的期望一致的時候，我們的user story就完成了。
達成一致。AC是開發(fā)團隊和客戶的一種同步。開發(fā)團隊能夠準確的知道什么樣的條件應該被滿足，就像是客戶知道他們期望從產(chǎn)品中得到什么。
作為基本的測試。AC是一個系統(tǒng)是否能夠如預期運行的基礎。
能夠準確的計劃和預估。AC的場景可以準確的將user story劃分為任務，這樣就可以更準確的進行計劃和估計。
誰來寫AC？什么時候來寫？
客戶或者開發(fā)團隊來寫AC。有一條規(guī)則是，由PO（客戶）所寫的AC需要開發(fā)團隊的成員來評估，以便確認該AC對于開發(fā)團隊是清晰明確的，并且從開發(fā)的角度來看是沒有技術上的限制的。如果PO有軟件開發(fā)的經(jīng)驗并且懂得如何寫項目文檔，這種合作方式是極好的。
如果更傾向于讓開發(fā)團隊來寫AC，那么就應當由PM或者QA來執(zhí)行這項任務，因為他們懂得技術棧和特性的可行性。
你知道自動化測試是檢驗產(chǎn)品是否達到AC的最有效的方法從這里可以了解更多的自動化測試的相關內(nèi)容
請記住，AC應該是開發(fā)前明確，永遠不要滯后于開發(fā)。因此，開發(fā)團隊和PO應該就交付內(nèi)容達成一致，交付內(nèi)容應該是滿足PO需求的最小的功能集合。
如何寫AC
AC有幾種類型。最流行的是面向規(guī)則（rules-oriented）和面向場景（scenario-oriented）的。面向規(guī)則的是列表形式，面向場景的是使用場景闡明每個標準。在敏捷團隊中，更傾向于面向場景的，因為它有助于了解需求，設想各種用例。并且手動測試和自動化測試也能從中獲益。*
使用面向場景的方式來描述AC的一個通用模板為Given/When/Then，這是從BDD中衍生出來的。Given/When/Then格式被用來寫AT。AT能夠確保所有指定的需求都被滿足。
這種格式不僅符合人類的思維邏輯（因為其類似于因為所以這種邏輯）而且也適用于自動化測試工具，例如Cucumber和RSpec。舉個例子，我們創(chuàng)建一個有兩種類型的用戶的網(wǎng)站，登陸用戶和非登陸用戶。我們會寫一個給登出用戶的登入特性的user story。
作為一個登出用戶，
我想要登入這個網(wǎng)站，
以便我能獲取到我自己的信息。
場景：系統(tǒng)用戶使用有效的密碼登陸
考慮到（Given）我是一個登出用戶，
并且我在登陸頁面
當（When）我填入用戶名和密碼，
并且點擊登入按鈕的時候，
那么（Then）我就登入了系統(tǒng)。
Given/When/Then模板幫助你減少寫測試用例的時間，因為你已經(jīng)提前描述了系統(tǒng)的行為。我們更傾向于使用第一人稱“我”來寫AC，因為它幫助我們從一個用戶的角度來看待問題，并且將客戶的需求記在心里。
這里有一些tips，可以幫助你寫一些好的AC：
- 你的AC應該是定義明確的，這樣你的團隊成員才能明白你所表達的內(nèi)容。
- 確保你的AC是可實現(xiàn)的。把你想要交付的內(nèi)容盡可能的細化，這樣你才可以專注于要交付的內(nèi)容。換句話說，不要想著去描述每一個細節(jié)，因為這樣你會是你的backlog聚集，并且淹沒在許多小的任務上。
- 跟所有的干系人配合，你的AC是建立在一致的基礎上的。
- 創(chuàng)建可測量的AC，這樣你可以充分的估計開發(fā)時間，不會導致預算或者時間不夠的情況。
- 考慮提供一個checklist，這樣你就能夠知道你的AC覆蓋了哪些user story。
AC的例子
在這一章節(jié)中，我們給出幾個AC的例子。
Example #1
我們的第一個例子描述了網(wǎng)頁搜索功能。
作為一個網(wǎng)站用戶，
我想要在網(wǎng)頁上搜索，
以便我能找到必要的信息。
根據(jù)Given/When/Then模板，AC應該是
場景：用戶通過名字搜索
考慮到我是一個注冊或者非注冊用戶，
當我打開產(chǎn)品頁面的時候，
那么系統(tǒng)會給我顯示產(chǎn)品列表
并且系統(tǒng)會在屏幕的右上角顯示搜索區(qū)域
當我在搜索的輸入框中輸入已有產(chǎn)品的名字，
并且點擊Apply按鈕或者敲擊enter按鍵的時候
那么系統(tǒng)會在搜索結果區(qū)域給我展示符合搜索結果的產(chǎn)品名字的列表，
并且系統(tǒng)會顯示搜索結果的數(shù)目
