這是敏捷開發使用者故事系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）
全系列將涉及何為使用者故事，面向客戶價值編寫故事，使用者建模，產品待開發項的分類，故事顆粒度，故事的組織結構，等等若干問題，力求將此中問題盡量解決乾淨。
按「作為乙個……，可以……，以便……」樣式和思路寫成的使用者需求，就是使用者故事。
樣式是技法層面的東西，它保證了無需太多思考，使用者故事中即包含角色、功能、價值這三個要素。
角色切記不要總是寫「作為乙個使用者」，而是要把使用者區別對待。這樣才能更好地理解他們使用什麼功能，如何使用，為何使用。
比如「作為乙個開發人員，可以登入批量編輯頁面，以便高效率地編輯多個故事」就是乙個危險的舉動，因為如果有多個程式設計師同時這麼做，儲存的時候會發生衝突（這個頁面後來被刪除了）。但「作為乙個專案經理，可以登入迭代計畫首頁，同時編輯多個迭代的資訊」則是可行的，因為專案經理一般就有乙個，而且這個功能使用次數很少，即使有多個人有許可權使用，偶然發生衝突的損害，與平時效率提高相比，也微乎其微。
所以把角色特化出來後，更容易理解功能的價值和風險。
日後另有文章詳述如何識別角色，以及如何基於關鍵角色編寫故事。
功能即使用者能親自執行的操作。
應區分使用者操作和產品功能之間的關係，因為產品功能可能也提供了使用者所需的價值，但卻極可能不便於操作。
乙個例子是之前我使用乙個xx手機，****上在「呼出」之外，總是有乙個「編輯呼出」，後來才知道是為了能在前面加撥17951之類的ip**字首。寫成使用者故事，差不多是：「作為乙個使用者，可以使用編輯撥出在撥打長途前輸入ip字首，以便節省話費。」不過這個功能從來沒用過，因為太費勁。實際使用中要麼我會把外地**錄入的時候就加上17951，要麼乙個**就打出去了管它三七二十一。
後來又使用另外一款android手機，因為別的原因安裝了360，發現它有乙個自動ip功能，寫成使用者故事，就是「作為乙個使用者，可以在撥打長途的時候自動使用ip撥出功能，以便節省話費。」這個功能每月可以給我節省不下20塊錢，如果他有一天收費，我必會買。
價值是完成操作後，客戶所得到的價值。
價值裡邊，常常要帶有一點褒義詞，或有一些吸引人的內容，比如前面的「高效地」「節省話費」。
潘家宇老師當年提到何為「用例」的時候提到了類似的概念：「用例就是那個你能賣掉的東西。」使用者故事也是用來被賣掉的東西，看不到價值的就不是使用者故事。
比如上面的360的使用者故事寫得就比較好，估計如果有讀者沒裝360，看完本文立刻就去。
底層的一些功能看不到直接的使用者價值，怎麼辦？系列中另有一篇描述使用者故事的分類。
敏捷開發使用者故事系列之五 使用者故事的分類
這是敏捷開發使用者故事系列的第五篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 在之一 之二 之三中，我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...
敏捷開發使用者故事系列之三 使用者建模
這是敏捷開發使用者故事系列的第三篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話 真的啊 我好像不知道誰會使用我的產品 這其實是一種常見的現象。比如前文所說...
敏捷開發使用者故事系列之三 使用者建模
這是敏捷開發使用者故事系列的第三篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話 真的啊 我好像不知道誰會使用我的產品 這其實是一種常見的現象。比如前文所說...