摘要:

    一件使用者通過系統完成他一個有價值的目標（買一罐飲料）的事。這樣的過程就叫“使用者案例(user case)”或者“使用者故事(user story)”。本文描述了敏捷開發的技巧：如何以使用者故事管理專案.

什麼是使用者故事(user story)

    假定這個專案的客戶是個飲料自動售貨機的製造商。他們要求我們為他們的售貨機開發一款軟體。我們可以找他們的市場經理了解這個軟體的需求。

    因此，我們的客戶就是他們的市場經理。談需求的時候，有一回他這樣說：“使用者往售貨機每塞一個硬幣，售貨機都要顯示當前該客戶已經投了多少錢。當用戶投的錢夠買某一款飲料時，代表這款飲料的按鈕的燈就會亮。如果那個使用者按了這個按鈕，售貨機就放一罐飲料到出口，然後找零錢給他。”

    上面的話描述的是一件事情，一件使用者通過系統完成他一個有價值的目標（買一罐飲料）的事。這樣的過程就叫“使用者案例(user case)”或者“使用者故事(user story)”。也就是說，上面我們的客戶所說的話，就是在描述一個使用者故事（user story）。
    (我解釋一下為什麼用故事這個詞，沒興趣也可以忽略。在一個系統面前，每個使用者要完成同樣的目標，都要做這個系統設定的例行的事，這件事情不是一個例子，所以不叫事例，這也不是故事，也不能算一段歷程，而是一個例行的事。)

    如果我們想要記下這段使用者故事，我們可能會用這樣的格式：

    名稱：賣飲料

    事件：

    1. 使用者投入一些錢。

    2. 售貨機顯示使用者已經投了多少錢。

    3. 如果投入的錢足夠買某種飲料，這種飲料對應的按鈕的燈就會亮。

    4. 使用者按了某個亮了的按鈕。

    5. 售貨機賣出一罐飲料給他。

    6. 售貨機找零錢給他。

    注意到，一個使用者故事裡面的事件可以這樣描述：

    1. 使用者做XX。

    2. 系統做YY。

    3. 使用者做ZZ。

    4. 系統做TT。

    5.  ...

使用者故事只是描述系統的外在行為

    一個使用者故事只是以客戶能夠明白的方式，描述了一個系統的外在行為，它完全忽略了系統的內部動作。比如，下面有下劃線的那些文字，就屬於不應該出現在使用者故事中的系統內部動作：

    1. 使用者投入一些錢。

    2. 售貨機將塞進來的錢存在錢箱裡，然後傳送一條命令給螢幕，螢幕顯示目前已經投入的金額。

    3. 售貨機查詢資料庫裡面所有飲料的價格，判定錢足夠買哪些飲料，對於錢足夠買的那些飲料，對應的按鈕的燈就會亮起來。

    4. 使用者按下一個亮起來的按鈕。

    5. 售貨機賣出一罐飲料給使用者，然後將資料庫裡面該飲料的存貨數量減1。

    6. 售貨機找零錢給使用者。

    不管是口頭描述的，還是書面形式，這樣的內容是描述使用者故事時一個很常見的錯誤。特別的，千萬不要提及任何有關資料庫，記錄，欄位之類的對客戶一點意義都沒有的東西。

評估釋出時間

    使用者故事是用來幹嘛的？假定客戶希望在50天內遞交這個系統。我們做得了嗎？為了解答這個問題，我們就要在專案開始的階段，試著找出所有的使用者故事，然後評估一下，每一項歷程需要多長的開發時間。可是，怎麼評估呢？
    比如，我們現在收集了下面這些使用者故事：

    賣飲料：如上面所說的。
    取消購買：在投入了一些錢後，使用者可以取消購買。
    輸入管理密碼：授權的人可以輸入管理密碼，然後增加存貨，設定價格，拿走裡面的錢等等。
    補充飲料：授權的人可以在輸入管理密碼後增加存貨。
    取出錢箱裡的錢：授權的人在輸入管理密碼後，可以取出錢箱裡的錢箱裡面的錢。
    安全警報：有些事情經常發生的話，系統會自動開啟安全警報。
    列印月銷售報表：授權的人可以打印出月銷售報表。

    然後找出裡面最簡單的使用者故事（這裡的“簡單”，意思是說實現週期最短）。我們不一定非常精準的判斷哪個最簡單。只要挑出你覺得最簡單的就行了。比如，我們覺得“輸入管理密碼”是最簡單的使用者故事。然後我們判斷說，這個使用者故事算1個“故事點（story point）”。
                       
使用者故事          故事點
賣飲料       
取消購買       
輸入管理密碼   1
補充飲料       
取出錢箱裡的錢       
安全警報       
列印月銷售報表       

不過一般我們不會列出清單，而是做出一堆卡片貼在牆上，每張卡片記錄一個使用者故事，然後將故事點寫在卡片上面：

這樣的一張卡片就叫“故事卡（story card）”。

使用者故事通常按照如下的格式來表達：

英文：

As a <Role>, I want to <Activity>, so that <Business Value>.

中文：

作為一個<角色>, 我想要<活動>, 以便於<商業價值>

舉例：

作為一個“網站管理員”，我想要“統計每天有多少人訪問了我的網站”，以便於“我的贊助商瞭解我的網站會給他們帶來什麼收益。”

需要注意的是使用者故事不能夠使用技術語言來描述，要使用使用者可以理解的業務語言來描述。

Ron Jeffries的3個C

關於使用者故事，Ron Jeffries用3個C來描述它：

卡片（Card） - 使用者故事一般寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工作量估算等。

交談（Conversation）- 使用者故事背後的細節來源於和客戶或者產品負責人的交流溝通。

確認（Confirmation）- 通過驗收測試確認使用者故事被正確完成。