尾牙活動小插曲
全世界都受到 COVID-19 疫情的影響下，在台灣的我們，就好像活在另一個平行的世界，除了勤洗手戴口罩以外，對於日常生活沒有太大的影響。於是，公司克服了各種困難，在今天中午舉辦了尾牙活動。
或許因為抽獎太興奮的關係，晚上沒有睡得很好。早上吃了一片吐司當早餐，就匆匆忙忙前往捷運站搭捷運準備前往會場。在捷運車廂裡，習慣性的打開 LINE 聊天室，查看最新訊息。
由公司同事組成的 LINE 群組裡，擔任福委會的同事，很貼心的傳了一張照片，這張照片由《PUI PUI 天竺鼠車車》當背景的提醒聲明，告訴大家出門前記得要準備：抽獎卷、口罩、健康聲明書。
看了訊息以後，快速檢查提在手上的手提袋，鬆了口氣，心想：「好險，剛好都有帶到。」
隔了三分鐘，突然有位同事冒出一句話：「還有『員工證』。」
我的心突然涼了一半，因為我的員工證通常放在上班專用的後背包裡，今天輕裝出門，只帶了輕便的手提袋而已。再次檢查了一次，更確認了我的假設，我忘記帶「員工證」出門了。
為什麼要帶員工證呢？如果你很幸運，抽到現金與獎品時，必須透過員工證來證明本人在現場，而不是由其他人幫忙投抽獎卷。
果然這消息一出現，好幾位同事跟我一樣就哀嚎起來了，難道，我們抽頭獎的機會就這樣飛走了嗎？
「員工證也要帶？」
「爆了，沒拿。」
「需要帶員工證嗎？忘了帶。」
「有，信中有寫。」
這時候，一位同事傳了一張如下圖的照片在聊天室裡，內容是其中一篇尾牙通知的電子信件片段，並且用紅色底線做了註記。
這個意外的小插曲，讓我聯想到敏捷團隊經常遇到的問題。
敏捷團隊的產品交付
敏捷團隊通常會採用使用者故事的方法描述需求，團隊在精煉或規劃會議上一起做討論。
以尾牙活動當例子的話，使用者故事可以這麼寫：
As a 公司員工
I want to 參加尾牙的抽獎活動
So that 我有機會可以中大獎
會議中，產品負責人就會打開準備好的規格文件（通常記錄在 Wiki 中），跟開發人員做細節的說明。以尾牙活動當例子的話，尾牙活動通知就如同規格文件，密密麻麻的，提供了許多的資訊。
如果沒有採用驗收準則（Acceptance Criteria）的方法，來輔助使用者故事，通常都會遇到一個你我都很熟悉的場景。
在展示會議時，團隊展示這個 Sprint 的產出，產品負責人或是利害關係人突然意識到跟預期的行為不同，產生如下的對話：
「這個使用者故事的行為跟規格文件不一樣。」產品負責人説。
「有嗎？當初的討論結果不是這樣子啊。」開發人員説。
「文件上有寫。」產品負責人説。
產品負責人立刻翻出規格文件，證明確實有記載。這個場景就如同尾牙通知電子信件一樣，可能只是長長文章中的一句話，甚至是一個詞。
有時候，場景更尷尬些，產品負責人翻出規格文件後，發現開發人員是真的依造規格文件開發，是產品負責人忘記修訂規格文件了。
那有沒有更好的方法
驗收準則通常是由使用者角度來看如何使用特定的功能。它著重於業務價值，確認功能範圍的邊界，並指導開發。
驗收準則可以確定邊界，幫助團隊成員了解使用者故事中包含的內容和排除的內容。產品負責人可以藉由驗收準則得知使用者故事的成功與否。
以尾牙活動為例子，驗收準則可以用條列方式做撰寫：
帶員工證
帶抽獎卷
帶口罩
帶健康聲明書
團隊採用使用者故事搭配驗收準則的方法，可以大幅降低產品負責人與開發人員認知的不同，而產生的各種不預期的功能行為。
除了驗收準則以外，也可以試著改善規格文件產生的方式。產品負責人在收到使用者需求後，應該先著重在釐清需求的價值，不適合一開始就做了過度的規劃。
當產品負責人將使用者故事帶進團隊會議討論時，每位開發人員都會提供不同角度的想法與建議，因此細節會開始累積與增加，而規格文件的目的是用來記錄大家有共識的部分，當作參考使用。
總結一下，使用者故事應該搭配驗收準則使用，規格文件對於使用者故事來說，只是資料參考與補充說明的用途。
