使用者故事(User Story) 是敏捷社群用來描述需求的 practice. 它非常容易上手, 但是也容易犯下錯誤, 以下便是常見的問題:

1. 都是使用者
User story 有個範本:
     as a , I want to because of .

大家可以根據這個來撰寫使用者故事. 可是很多人在寫的時候都會變成這個樣子

身為一個<使用者>, 我想要<可以根據關鍵字查詢書籍>, 因為<大多數時候我只記得一些關鍵字, 這樣對我比較方便>
也就是說, 大家都不區分你的使用者是誰, 都把它泛稱使用者, 也起來比較快速, 因為不用大腦. 可是這會讓你損失很多了解系統的機會. 因為不同角色的人, 會有不同的考量和需求, 並且也會有不同的優先順序, 混為一談, 只是讓你迷失在一大包功能列表中, 而無法掌握重點一刀斃命.

2. 不是從客戶角度出發
本來應該要從不同角色的角度出來, 來思考他想要的需求是什麼. 可是總是會有些是技術債, 或者是 product owner 自己想要的東西. 這些東西不是不能寫, 而是要寫的時候, 還是要站在客戶的角度, 想想客戶會希望你這個東西做成什麼樣子.
例如, 有些 debug log 資訊不完整的技術債, 開發人員一開始可能會寫成     

身為開發人員, 我要能產生一些 debug logs, 這樣好讓我再出錯時可以方便除錯.
如果你若是能再進一步從使用這個機制的客戶來思考, 他可能要的會是像這樣
身為開發人員, 我要能產生一些可以分層且方便下載的 debug logs, 這樣好讓我再出錯時可以方便除錯, 並且不用看太多訊息, 或是收集太大的 debug log.

因為有時候產生 debug log 不是問題, 問題是產生太多, 短短時間內就產生了幾 G 大小的檔案, 在某些環境下, 你要使用者如何把這玩意下載交付到你手上.
所以你如果能異位思考, 同一個功能, 你做出來會更貼心.

3. 沒有商業價值
另外一個問題, 就是沒有撰寫商業價值的部分. 當我們沒有這部分的資訊, 我們就無法判斷他到底有多急, 或者是在該做到多少才足夠.
例如: 身為系統管理人員, 我需要產生日報表.

如果只是這樣就呆呆地去實踐日報表的功能, 通常出來的都不會是客戶要的. 你需要知道這報表出來是要給誰看的, 是要那它來做什麼, 大多時候我們都是一廂情願的給很多資料, 可是你有想過上百頁的報表他會看嗎? 或者是有時候客戶也不見得確定他想看什麼資料, 或是想交付什麼資料給老闆看, 這時候一份固定格式的報表, 對他來說效益不大. 
所以我們需要有商業價值的部分, 並且那只是起始點, 我們還需要根據這個起始點, 來和客戶好好溝通, 他們內心真的在想什麼.

4. 沒有驗收條件
寫過使用者故事的都知道, user story 只是很簡單的一兩句話, 他希望的就是你要去跟利害關係人討論, 要去了解他們著遇到什麼問題, 要這個功能的動機是什麼. 此外還有一件重要的事情, 就是要列出驗收條件, 也就是定出要做的功能的範圍, 如果沒有這個框框, 在大家認知不同的狀況下, 便會有不同的產出.

例如:
使用者故事
身為一個<使用者>, 我想要<可以根據關鍵字查詢書籍>, 因為<大多數時候我只記得一些關鍵字, 這樣對我比較方便>
是只針對書籍名稱找尋, 還是對作者或是書籍簡介也搜尋? 此外找出的書目, 是根據出版時間, 還是根據書籍名稱的字母順序排列?
雖然這些功能不見得難做, 可是一開始沒有做對, 等到事後才來修改, 不僅浪費工程師的時間, 也讓使用者覺得很不貼心. 為什麼不一開始就把驗收條件確認好呢?
 

作者：David Ko

作者簡介：David具備Certified Scrum Master以及Certified Scrum Product Owner的認證，也是台灣最早期 Agile 社群（AgileCommunity.tw）發起人之一。 為了推廣Agile知識，還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管，並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。

文章出處：David Ko的學習之旅

原文連結：撰寫使用者故事常見的問題