什么是用戶故事？
用戶故事（User Story）是一段簡單的功能描述，以用戶或者使用者的角度，寫下有價值的功能（Functionality／Feature）。與其說它是規(guī)格文件（Documentation），不如說它代表客戶的一個需求而已。
用戶故事的通用格式如下：
身為一個 {特定角色}，我希望能有 {特定功能} 以便能讓我{得到某種價值}。
As a (role of user), I want (some feature) so that (some business value).
舉個例子：
一個有最基本功能的購物APP，它的用戶可能有以下幾種：
買方
賣方
網(wǎng)站管理員
一個站在買家立場的用戶故事：
作為一個買家，我希望能瀏覽所有同類商品的圖片和價格，這樣我能全面地比價并找到最適合我的商品。
一個好的用戶故事應(yīng)該遵循INVEST原則。
以下來自于Scrum中文網(wǎng)：
獨(dú)立性（Independent）— 要盡可能的讓一個用戶故事獨(dú)立于其他的用戶故事。用戶故事之間的依賴使得制定計劃，確定優(yōu)先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。
可協(xié)商性（Negotiable）— 一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細(xì)節(jié)。具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個用戶故事卡帶有了太多的細(xì)節(jié)，實際上限制了和用戶的溝通。
有價值（Valuable）— 每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進(jìn)行協(xié)商的時候，他們將非常樂意寫下故事。
可以估算性（Estimable）—開發(fā)團(tuán)隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。但是讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
短?。⊿mall）— 一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風(fēng)險就會越大。
可測試性（Testable）—一個用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。
如何寫好用戶故事？
以下8個小技巧或許能助你一臂之力。
1. 用戶至上
用戶故事是用來描述用戶如何使用產(chǎn)品，一切內(nèi)容要圍繞用戶的角度出發(fā)。比如，用戶故事應(yīng)該是圍繞著“用戶需要一個搜索功能來尋找他想要的產(chǎn)品”來描述，而不是“搜索需要聯(lián)合幾個數(shù)據(jù)庫一起提供數(shù)據(jù)”。
2.利用用戶角色（Persona）來發(fā)現(xiàn)故事
用戶角色是根據(jù)目標(biāo)群體設(shè)定的虛構(gòu)人物，包括名字、行為習(xí)慣、目標(biāo)等。根據(jù)用戶角色的行為目標(biāo)，尋找正確的用戶故事。比如買家Amy是一個社交狂魔，那么就需要考慮到購物APP中，商品向各種社交軟件的分享功能。
3.注意用戶故事之間的協(xié)作
用戶故事不是一個規(guī)格說明書，它是一個溝通與協(xié)作的工具。用戶故事不能被單獨(dú)地傳遞給開發(fā)團(tuán)隊用于交付，它存在于一系列的完整的設(shè)計之中。比如，購物APP中，用戶故事1是買家能把商品添加到購物車，用戶故事2是買家能添加／修改地址，用戶故事3是買家能綁定支付方式，用戶故事4是買家能在線支付——這才算完成了一個買家購買的功能。
4.簡潔即美
用戶故事要簡明扼要，可讀性高，避免使用模棱兩可的描述。用戶故事的模版就是一個很好的實踐：As , I want ， so that .——我是誰，我想要什么功能，為什么。
5.不斷完善
當(dāng)我們把需求從Epic細(xì)化到Story時，有些功能范圍放在哪個用戶故事里，其實是可以商榷的。本著上述的INVEST原則，用戶故事需要不停地調(diào)整、完善，直到就緒（用戶故事清晰、可行、可測試）。
6.增加驗收標(biāo)準(zhǔn)（AC，Acceptance Criteria）
AC是驗收用戶故事的標(biāo)準(zhǔn)，有了AC，用戶故事的何時算完成，就有了更清晰的界定。一個比較普遍的AC的模版如下：Given在某種場景下 When發(fā)生了事件 Then導(dǎo)致了什么結(jié)果(簡稱Given, When, Then)。比如針對這個用戶故事“作為一個買家，我希望能搜索到所有同類商品的圖片和價格，這樣我能全面地比價并找到最適合我的商品。”，那么相應(yīng)的驗收標(biāo)準(zhǔn)就是——設(shè)定用戶想買一只錢包的情景下（Given），當(dāng)他搜索錢包的的時候（When），他能夠看到所有錢包的圖片和價格（Then）。
7.可視化用戶故事
可視化可以讓每個人清楚用戶故事的內(nèi)容，便于團(tuán)隊更方便地將故事做分類、標(biāo)記等管理，同時故事完成進(jìn)度的橫向流動，也便于讓團(tuán)隊思考有哪些已經(jīng)完成，是否有功能遺漏等。所以，無論是電子墻還是物理墻，可視化所有的用戶故事，能讓你事半功倍。
8.不僅僅依賴用戶故事
用戶故事只是需求與開發(fā)的溝通方式之一，有用，卻不萬能。它能能體現(xiàn)產(chǎn)品某些功能、特性，在產(chǎn)品設(shè)計還需要user journey map，在數(shù)據(jù)流上還需要data flow圖，在用戶體驗上還需要原型設(shè)計等
總之，如果你想快速創(chuàng)建一個一次性的原型或模型來驗證一個想法，那么撰寫故事沒有必要。然而，當(dāng)你開發(fā)一個重要應(yīng)用，編寫用戶故事是值得的，它不是記錄需求的無用開銷，而是能幫你快速啟動并盡可能快地開發(fā)軟件的工具。
