新瓶裝舊酒之驗收條件

May 08 11:10~12:30

 

昨天（5/8）在北科的「軟體生命週期管理」課程和學生談到product backlog refinement workshop。在實務上，有許多Scrum團隊在這個活動中會讓PO與團隊成員一起合作，幫story撰寫驗收條件。合作的模式為：

1. PO解釋story內容。
2. 大家針對story內容討論。
3. 團隊成員在白板上寫出story的主要驗收條件（驗收條件可以有很多，如果每種情況都考慮到，不太可能在product backlog refinement workshop裡面全部寫完。所以只針對比較重要的使用情境撰寫驗收條件。）
4. 團隊成員解釋所撰寫的驗收條件。
5. 大家集思廣益看看驗收條件是否清楚完整，或是需要增加新的驗收條件。

藉由這種方式，PO可以從團隊成員身上立刻獲得回饋，了解團隊成員對於story的理解程度，也順便檢驗自己對於story的內容說明是否有遺漏之處。

***

驗收條件的撰寫方式有很多種，可以用條列式的方式，例如步驟1、步驟2、步驟3等等，或是用Given-When-Then（GWT）的格式來撰寫。GWT格式是目前敏捷社群主流的方式之一，看起來好像很「潮（很新穎）」，其實這也是幾十年前就已經存在的做法。

 

 

如上圖所示，要證明或是驗收一個功能是否正確，一種常見的方法就是把系統當成一個狀態機（state machine），每一個功能（action）將系統由目前狀態（current state）轉變到下一個狀態（resulting state）。只要能夠指明系統的目前狀態與下一個狀態，並且在執行了某一個特定功能之後系統的狀態的確符合所期待的下一個狀態，那麼我們就可以「大膽假設」這一個功能的實作是正確無誤的。

GWT格是就是用Given來指定目前狀態，也就是前置條件（pre-condition）；用Then來指定下一個狀態，也就是後置條件（post-condition）；而When就是造成狀態轉換的那個動作（action），也就是待測功能。

舉個部落格寫作軟體的例子，

Given 部落客新增了一篇blog並且打完 <內容>

When 部落客發布文章

Then <內容>將顯示在<部落格>的文章列表第一篇

Examples：

| 內容                  部落格                                          |

| This is a blog.    http://teddy-chen-tw.blogspot.tw/    |

| 今天睡懶覺。    http://eiffel-tw.blogspot.tw/             |

***

驗收條件當然是寫給人看的，所以當story完成之後，人可以依據驗收條件來決定是否接受這個story。如果採用固定格式，例如GWT來撰寫驗收測試，可以進一步使用像是Cucumber這類的工具，將執行驗受測試的方式自動化。

***

友藏內心獨白：格式和工具都不是重點，重點還是在有沒有動腦。