在敏捷開發流程中, 對 story 撰寫驗收條件 (acceptance criteria) 是件非常重要的事. 驗收條件可以釐清故事範圍, 以及同步大家對故事的認知, 更可以讓開發團隊估算會比較準確.
可是我發現到, 在很多團隊這件事情常常被省略. 他們覺得開發時間都不夠了, 哪有空寫驗收條件. 或者他們認為這是測試, 不是我開發人員的事. 也有人認爲這個故事已經很清楚很簡單, 不需要再寫驗收條件了, 做就是了.
但是, 事情往往不是這麼簡單. 因為沒有寫 AC, 事後才來說為什麼需求不是那樣, 或者說這個故事需要花比我原先想的更多時間來做等等, 這是事情都是可以事前預防或減緩的.
因此, 就讓我們來看看 驗收條件 (acceptance criteria) 的相關知識吧
AC 的定義
Story 必須要滿足客戶和 PO 所想要的狀況(conditions). 這些狀況會由一堆敘述所組成, 每個敘述會有很清楚通過和失敗的標準, 讓我們可以度量是否滿足. 這堆敘述稱之為驗收條件
|
User story: As a user, I want to be able to register in the service so that I can start shopping online.
Acceptance criteria:
* Users can only submit a form by filling in all the required fields.
* The email the user provides must not be provided by a free email service.
* Submissions from the same IP can only be made three times within 30 minutes.
* Users receive notification emails after successfully registering.
|
何時要撰寫, 誰來寫
通常是PO 在列出 user story 時, 就要列出這個 story 的驗收條件
但是為了避免 PO 變成是瓶頸, 可以讓 team 和 PO 公同來撰寫. 或者由 team 先撰寫, 然後和 PO 共同確認
寫的時間點可以是 PO 列出 user story 時候寫, 或者在 PBR 會議中一起共同來撰寫
為什麼我們需要驗收條件
(1) 釐清 story 的細節和範圍
(2) 幫助團隊能做出更精確的估計
(3) 共同確認不清楚或是較複雜的 error handling 的部分
(4) 讓 PO, designer 和 team 可以對 story 範圍和細節有共識
(5) 如果發現有不清楚, 太大, 或是不太重要的部分, 可以拆解成其他的 story
AC 要包含的方向
(1) 功能的主要運作流程, 可以說明功能的範圍
(2) 會影響其他功能的流程
(3) 非功能的需求
Ex: 效能/安全性
(4) 需要處理的限制或約束
AC 的格式
(1) Given/When/Then
* Given some precondition
* When I do some action
* Then I expect some result
|
User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.
Scenario: Forgot password
Given: The user has navigated to the login page
When: The user selected forgot password option
And: Entered a valid email to receive a link for password recovery
Then: The system sent the link to the entered email
|
(2) rule based
|
User story:
As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.
Acceptance criteria
* The search field is placed on the top bar
* Search starts once the user clicks “Search”
* The field contains a placeholder with a grey-colored text: “Where are you going?”
* The placeholder disappears once the user starts typing
* Search is performed if a user types in a city, hotel name, street, or all combined
* Search is in English, French, German, and Ukrainian
* The user can’t type more than 200 symbols
|
(3) 各式客製化格式
撰寫 AC 主要的挑戰
(1) 要在開發之前撰寫完 AC
(2) 要具體可以明確的指出是否通過
(3) 找出最小的驗收集合, 而非整個要測試的細節
(4) 避免寫一堆技術細節, 要讓所有人都懂
(5) 重點在描述做什麼, 而非怎麼做
文章標籤
全站熱搜
留言列表
