摘要:
一件用戶通過系統完成他一個有價值的目標（買一罐飲料）的事。這樣的過程就叫“用戶案例(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
補充飲料
取出錢箱裏的錢
安全警報
打印月銷售報表
不過一般我們不會列出清單，而是做出一堆卡片貼在牆上，每張卡片記錄一個用戶故事，然後將故事點寫在卡片上面：
![敏捷開發技巧：以用戶故事管理項目]( "[轉載]敏捷開發XP <wbr> <wbr> <wbr>用戶故事")
這樣的一張卡片就叫“故事卡（story card）”。
然後開始考慮其他用戶故事。比如，對於“取出錢箱裏的錢”這個故事，我們認爲它跟“輸入管理密碼”這個故事一樣簡單，所以它應該也是算1個故事點。我們在列表裏面標上。當然，實際操作的時候，我們是在“取出錢箱裏的錢”的故事卡上填上故事點。
用戶故事 故事點
賣飲料
取消購買
輸入管理密碼 1
補充飲料
取出錢箱裏的錢 1
安全警報
打印月銷售報表
對於“取消購買”，我們認爲它應該是“取出錢箱裏的錢”的兩倍的工作量，所以它算2個故事點。
用戶故事 故事點
賣飲料
取消購買 2
輸入管理密碼 1
補充飲料
取出錢箱裏的錢 1
安全警報
打印月銷售報表
對於“賣飲料”，我們認爲它應該是“取消購買”兩倍的複雜度，所以它應該算4個故事點。
用戶故事 故事點
賣飲料 4
取消購買 2
輸入管理密碼 1
補充飲料
取出錢箱裏的錢 1
安全警報
一件用戶通過系統完成他一個有價值的目標（買一罐飲料）的事。這樣的過程就叫“用戶案例(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）”。
然後開始考慮其他用戶故事。比如，對於“取出錢箱裏的錢”這個故事，我們認爲它跟“輸入管理密碼”這個故事一樣簡單，所以它應該也是算1個故事點。我們在列表裏面標上。當然，實際操作的時候，我們是在“取出錢箱裏的錢”的故事卡上填上故事點。
用戶故事 故事點
賣飲料
取消購買
輸入管理密碼 1
補充飲料
取出錢箱裏的錢 1
安全警報
打印月銷售報表
對於“取消購買”，我們認爲它應該是“取出錢箱裏的錢”的兩倍的工作量，所以它算2個故事點。
用戶故事 故事點
賣飲料
取消購買 2
輸入管理密碼 1
補充飲料
取出錢箱裏的錢 1
安全警報
打印月銷售報表
對於“賣飲料”，我們認爲它應該是“取消購買”兩倍的複雜度，所以它應該算4個故事點。
用戶故事 故事點
賣飲料 4
取消購買 2
輸入管理密碼 1
補充飲料
取出錢箱裏的錢 1
安全警報