什麼是 User Story?

User stories 是一種非常好用且容易上手的需求文件，它是一種極簡主義，只要求寫下最有價值不要忘記的東西，而且夠讓我們足以估計時程以及與客戶溝通。

嚴謹、漂亮、詳細的文件有兩大危險，一是製作厲害的文件本身變成了一個目標，而不是製作軟體。二是語言本身是模糊的，”詳細”的文件會造成”確定性的幻覺”，以為規格都確定了無需要溝通，最後做出根本不符合預期的軟體。敏捷開發鼓勵我們將時間多花在開發者、客戶、使用者之間頻繁的溝通，而不是製作文件。

什麼是 User Story?

User Story(使用者敘述)是一段簡單的功能敘述，以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶的一個需求而已，因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下：

• 使用者可以在網站上張貼履歷
• 使用者可以搜尋有哪些工作
• 公司可以張貼新工作
• 使用者可以限制誰可以看到他的履歷

初學的範本可以是：作為一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。

As a (role of user), I want (some feature) so that (some business value).

因為 User stories 僅描述對使用者有價值的功能，因此像是 “這個軟體由 C++ 撰寫” 或 “這隻程式將透過 connection pool 與資料庫連結” 這種技術規格就不適合寫在 User stories (但是你可以思考說，這些技術規格帶來的商業價值是什麼，然後重新用 user stories 不帶技術詞彙表達出來)。

回頭看看上述的 User Stories，作為一個初步的 Story 粒度可能足夠讓程式設計師忙上一個禮拜了，但是當粒度太大了，我們會持續跟客戶溝通產生更多的子 User Stories (請用更多小條目的 story 而不是一個很長的 story 來描述)，例如：

• 使用者可以用條件搜尋工作，例如地點、薪資範圍、工作職稱、公司名字等
• 使用者可以瀏覽詳細的工作內容
• 使用者可以瀏覽詳細的公司資料

寫到這裡的粒度其實就差不多了(系列下一篇會更一步說明怎麼寫好 User stories)。我們不需要在這時候再寫下瀏覽工作內容的頁面上到底有哪些東西，只需要在這些細節變重要的時候再討論確定即可。

除了 Stories 的部份，一開始如果能夠順便補充如何做 Acceptance Test 將會很有幫助，程式設計師就可以知道客戶會做哪些驗收測試、期望跟假設。例如會有哪些資料會被輸入、使用者輸入之後期望看到什麼、任何其他潛在的商業邏輯?? 有什麼可能的邊際條件出錯需要處理? 例如:

• 輸入空白的工作描述
• 使用超級長的工作描述
• 輸入空白的薪資範圍

這裡的補充絕對是不完整的，所以可能隨時會增補，主要的作用在於傳達額外的資訊告訴程式設計師怎樣才算完成這個 Story 以及有哪些意外情況要處理。而身為客戶，驗收測試可以知道系統是否成功地被實作出來。身為程式設計師，則可以了解哪些是必要的功能。

因此，建議能在每次開發週期(Iteration)開始的會議中(最慢也要在Iteration中期前)，把會有哪些驗收測試都提供給程式設計師，並且提供必要的測試資訊。測試可以的話，盡量能夠自動化。其中又因為客戶不會寫程式，所以可能會透過文字或試算表格的形式提供測試資料，這時就需要測試人員撰寫能夠讀取這些資料的程式來進行測試。

以 User stories 導向的軟體開發，客戶最好要實際參與 user stories 撰寫，而不只是簽名而已。作為開發者我們可以協助撰寫和提供建議，但是這應該是客戶的責任。由客戶主導的好處有 1. 由自然語言撰寫，不會充滿技術詞彙，這樣客戶也才可以根據商業價值排定優先順序。而不是由開發人員根據技術相依性來決定順序。(不過這其實也有新的問題：技術風險。開發人員會希望先進行技術風險高的 stories，這時候就需要與客戶協商討論) 2. 承上，也因為是自然語言，非技術人員也可以輕易了解內容，進行跨部門的合作 3. 由實際的使用者來描述軟體行為，再適當也不過了。

Stories 非常適合搭配 Iteration 的開發方式，在一個開發週期內(例如兩週)內做好分析/設計/實做/測試，然後得到 feedback。我們會將 User stories 分配到各個 Iteration 中，而一個 Iteration 可以放多少 User stories 呢? 我們會估計團隊 Velocity 開發速度(一個 Iteration 可以完成多少 story points)，然後根據 story 的複雜度跟大小估計 story points，再由客戶依照優先順序排入 Iteration 中。那 Velocity 要怎麼估計，第一個週期當然會很不準，之後則是每次 Iteration 結束後，重新計算 Velocity 來調整 Iteration 計畫，也很可能新增或移除一些 User stories。

User Story 不是什麼?

有學習過UML的話，User Stories 不是 Use Case (不同之處)，也不是 Scenarios。

User Story 的特點

非常強調口頭上的溝通

我們會以為只要我們把所有規格需求都好好精準地寫下來，那麼開發人員就會精準地知道客戶要什麼、測試人員就會知道要測什麼，最後客戶就會正確地得到他們想要的東西。錯錯錯，客戶只會得到開發人員從寫下來的文件上理解出來的東西，而且往往：

1. 使用者和客戶一般來說不真的明確知道到底什麼是他們要的
2. 即使開發者知道所有需求，也還是有很多細節直到真正開發的時候才知道需要
3. 即使所有細節都可以事先知道，人類也沒有能力能一次全部理解
4. 即使我們可以了解所有細節，專案需求還是會變動
5. 人們會犯錯

自然語言是不精準的，要用文字精準描述到開發者可以完全符合需要，太困難了，傳統作法會要求寫規格要盡善盡美，但那太崇高了。User stories 的用意就不在於寫下完整的細節，而是一個文字記錄說提醒開發者跟客戶，這裡需要再討論溝通細節。

對每個人都容易了解

簡單扼要的 user stories 對每個人都容易了解，無論是不是技術人員。

大小剛好適合計畫

User stories 很容易拿來根據商業價值來排定開發優先順序，決定發行計畫 release。

適合 iterative 開發

不需要寫下全部的 stories，就可以開始動工了。非常適合 iterative 開發。

鼓勵延後細節

除了實作細節延後之外。連 stoies 一開始可以也不需要寫完整。專案一開始，只要寫下目標層級的大 stories 即可，隨著進展再逐步寫下較細的 stories。對於計時合約專案超適合。

鼓勵人人參與的設計

許多軟體開發會失敗，就是因為缺乏使用者參與設計。由於 stories 具有親和力，鼓勵了使用者也參與設計。

我的一些經驗

採用敏捷方法的軟體開發合約該怎麼簽？ 一文所提，很多時候只能玩成價格固定、交期不變、規模求個大概。而這個規模用 User Stories 來描述，來做為專案估計時程和報價的重要參考。不過這種情況下，嗯，就沒有上述計時合約可以慢慢寫 user stories 的好處，必須一開始就把 user stories 寫比較完整。

這裡顯然就是一個拉鋸戰啊，如果一開始合約中的 user stories 可以越大概，就可以越偏向 Agile 想要的彈性。但是實際的情況，不把規模定詳細一點又不行。我認為這種所謂的實際情況，並不是單方面客戶的問題。而是號稱敏捷的接案方常常也提不出信心跟有利證明說，這N個月到底可以給出什麼東西跟保證? 如果沒有實際認真在做 Iteration、並測量實際的開發速度，接案方又怎麼能夠讓客戶相信你的 “每個月提供三個人力” 到底是不是真的有三個人在做??? 是不是在呼弄客戶?? 既然沒個辦法可以相信，那還是回到規模固定、價格固定，交期就大家心照不宣(反正十之八九會 delay)，這樣還比較保險心安。

不過呢，即使採用保險作法把 user stories 寫完整，而接案方誤把”詳細”的 user stories 當做規格，以為規格都確定了無需要頻繁溝通，那也是凶險異常。

另外，客戶們多半沒有辦法第一次就提供接近良好的 User Stories 文件，一種是資訊太少，沒有想清楚需求，即使看過範例，也沒有辦法寫出像樣的 user story (well, 這還有兩種可能，一是不知道要做什麼，二是他可能知道他要做什麼，但是沒辦法用自然語言表達出來，不管哪一種對雙方溝通都有困難)。這種情況恐怕只得多花開會時間成本幫助客戶”思考需求”並一同撰寫 User Stories 了(不過我還是覺得 user stories 已經是各種需求文件中，最簡單學習使用的了)，實務上也許會另外收取需求分析的費用。如果是走計時合約的方向應該就不需要另外收費了，因為一開始的 User stories 不完整也沒關係。

另一種是有想了很多，也做了很多文件，但不是 user stories 的格式(例如每頁每頁用 M$ Word 畫出來的企劃文件)，通常這種客戶只要看過 user stories 的範例，加上回頭檢視本來的企劃書，就可以”簡化”出真正的”需求”，而不是畫面跟實做的細節。對開發者來說，User stories 可以給開發者很快的了解開發”目標”、要做到什麼功能，而不會見樹不見林。對客戶來說，撰寫 User story 可以幫助他們思考什麼才是真正他們想要做到的東西(商業價值 business value)，而不是思考畫面怎麼配置、怎麼操作等怎麼實做的問題，這些細節應該是開發者的專業，思考如何設計出一個好用、經濟、快速、有效率的實做方式。

最近看到的這則寓言故事也非常適合說明以上這種情況: 輕鬆談軟工，你應該告訴開發者 what 是目標，而不是 how 怎麼做。

管理系統

要怎麼管理 user stories 呢? 書都講說用卡片最好，因為最方便，要撕掉重寫也很快(無誤)。電子形式來說，使用 Wiki 是最方便修改的方式。以一般最常用的 Issue tracking systems (例如: Redmine) 來說，將一條條 stories 開成 ticket 也是最常看到的管理方式(Redmine 也有提供 Wiki 功能)，而專案的 Milestore 可以對應到 Iteration。

不過使用上我個人建議不要專案一開始就把所有 stories 一次直接開成 tickets。一開始就將 User stories 都開成 Ticket 會妨礙溝通，大家會有規格已經全部定案的錯覺，也不鼓勵繼續修改增補 User stories，因為這樣就得修改 ticket，也許是切割、也許是取消不做……等。每次開 stories 為 tickets 的時機應該在 Iteration 一開始的會議中，這個會議會決定這一個 Iteration 會有哪些 User stories。

另外，我發現將 User story 直接對應到 Ticket 其實也是有疑義的，因為:

1. 一條 User Story 可以包含多個實作 Tasks 任務。User story 不會有任何技術細節(可以給 manager 看的)，但我們會在 Task 裡描述技術細節(會給 programmer 看的)
2. 每次 Iteration 開始時，才由 Architect 根據 Stories 拆成 Tasks 分配給 programmer, tester 甚至是 art。
3. 一條 User story 如果對應到一條 Ticket，對於 programmer 來說，粒度有時候太大了，而且一條 User story 很可能包含多個實作者，例如實作 Model、實作 Controller、美術設計、套版和整合測試。

總之，我認為 Ticket 應該對應到 Task 實作層次，而非只有 User story。此外，如果有單純一定要做的 task，但是不在 user stories 裡面。這時候要可以想辦法改用一條 user stories 來詮釋它，一件事一定有其商業價值可以讓客戶了解並選擇。

這樣看起來預設的 redmine 需要做一點調整，首先我們可以增加一個追蹤標籤叫 “Story 使用者敘述”，然後開 Story tickets。接下來如果需要描述到技術細節，就必須加開實作 Task ticket，並設定 “相關的項目清單” 為 “阻擋 Blocks” 它所屬的 Story ticket，這樣就可以建立關聯。這樣 Story ticket 擁有的 task tickets 必須都完成後，才能關閉該 Story ticket。

不過還是有點不是很好用，找了一下市面上的服務，發現 ScrumNinja 最符合我想要的方式。例如它的範例: 一條 user story 是 As a user, I want to reset my password in the event that I forget it so that I won’t get locked out，而其就包含了三個任務 1. reset password to temporary password 2. send email with temporary password 3. prompt user to change password after logging in with temporary password。

結論

溝通再溝通，每個 story 進行前，開發者與測試人員都主動與客戶進行實作上溝通(溝通啥? 寫下驗收測試)，確保他們的理解無誤，再忙也要問而不是亂猜。好的PM也會鼓勵這種溝通。
另一個溝通點則是每次 Iteration 的開始會議，會討論出這次要進行的 stories，可能是將大的 story 拆小、可能加入新的 stories 或任何改進。

User stories 非常非常強調開發過程中的溝通，如果你偷懶沒有頻繁溝通細節或是一開始定好 User Stories 開成 tickets 就不再修改內容，就讓我想起 Qing 長輩的這篇半吊子的敏捷開發，也是兇險異常啊。這篇文章簡直就是吾等愛好 Agile 開發的警世之語啊，隨時提醒自己半吊子的凶險。

參考資料

• User Stories Applied, Mike Cohn
• 深入淺出軟體開發 第2章
• 規劃極致軟體製成(Planning Extreme Programming) 第11章
• 極致軟體製程: 專案應用(Extreme Programming Installed) 第4章
• Agile Coaching Chap.6 Understanding What to Build
• User Stories – An Agile Requirements Approach