在輔導(dǎo)團(tuán)隊實踐敏捷的過程中坦敌，用戶故事的使用經(jīng)常是面臨的第一個問題零院，也是一個很難解決的棘手問題募疮，究其原因就是很多團(tuán)隊會習(xí)慣性把用戶故事作為傳統(tǒng)需求的代替退敦，認(rèn)為只是換了一種寫法而已网梢，這就導(dǎo)致很多團(tuán)隊表面在跑敏捷，實際上還是在用傳統(tǒng)的思路在工作燕耿。我們希望能通過這篇文章讓你理解敏捷需求管理的基本思路和方法。
文章由兩部分構(gòu)成，用戶故事的相關(guān)基礎(chǔ)知識以及如何使用用戶故事地圖這個工具來產(chǎn)出用戶故事针余。
前言
首先我們看一下下面這個圖，這是對需求再用戶 產(chǎn)品 研發(fā)之間流動關(guān)系的一個抽象描述，描述了產(chǎn)品經(jīng)理從用戶那里獲取新的需求或者對已有功能的反饋朴肺，作為研發(fā)團(tuán)隊的輸入需了，研發(fā)團(tuán)隊完成功能開發(fā)后提供給用戶使用挽牢，產(chǎn)品經(jīng)理收集反饋進(jìn)一步指導(dǎo)研發(fā)的開發(fā)工作。無論是傳統(tǒng)項目還是敏捷項目這個過程都是一樣的野来，而我們的目的就是促進(jìn)這個循環(huán)關(guān)系不斷改進(jìn)和提效恼除。
但是傳統(tǒng)項目管理方法在改進(jìn)這個過程中遇到了不小的困難，我們看一個如下的對話場景：
產(chǎn)品 ：
我這里有個新需求，比較急豁辉，你抓緊時間給加一下
小王 ：
好的令野，沒問題，但是能告訴我為什么要加這幾個功能嗎徽级？想解決用戶的什么問題呢气破？
產(chǎn)品 ：
你做就好了，這個是客戶（領(lǐng)導(dǎo)）要求的餐抢，一時半會兒也說不清楚现使，反正需求就是這樣
小王 ：
那你能給我講講這些功能都給哪些用戶使用？
用戶在什么情況下會使用這些功能嗎旷痕？
用戶是如何使用這些功能的碳锈？
這些功能和用戶工作是如何結(jié)合的呢？
產(chǎn)品 ：
（看奇葩一樣看著小王欺抗，不耐煩的說）
需求就是這樣的殴胧，你照著做就行了，不用問這么多佩迟，出了問題我兜著
小王 ： ...
大家可以思考一下是否遇到過類似的問題，我實際工作中就遇到過開發(fā)人員只了解一部分自己涉及的東西竿屹，甚至對功能誰來用报强、什么場景用、怎么用都沒搞清楚拱燃，最后需要業(yè)務(wù)測試時候才發(fā)現(xiàn)從開發(fā)到測試都不了解這個系統(tǒng)的使用流程秉溉，只是在按照上游輸入的信息被動的進(jìn)行工作，可以想象這種情況下產(chǎn)品的質(zhì)量碗誉。所謂需求很多時候已經(jīng)變成了命令而非信息傳遞的載體召嘶。
這段對話我分別給產(chǎn)品和研發(fā)都看過，我摘抄了幾個比較典型的觀點列到這里
產(chǎn)品：
- 我很少遇到這么負(fù)責(zé)的開發(fā)哮缺，如果真有人這么問我我會非常樂意給他講的弄跌。
- 我們這個系統(tǒng)太復(fù)雜，要想讓所有開發(fā)都搞清楚使用場景和邏輯確實有點困難尝苇。
- 需求是從領(lǐng)導(dǎo)和客戶那里來的铛只，領(lǐng)導(dǎo)要求了只能照著做，沒辦法糠溜。
研發(fā)：
- 我每天加班加點的淳玩，哪有時間管這些，讓我怎么改就改唄非竿。
- 我有興趣了解這些信息蜕着，但是大家都很忙，也不知道什么時候該問红柱。
- 研發(fā)問這些是不是在挑戰(zhàn)產(chǎn)品的專業(yè)性啊承匣，會不會讓產(chǎn)品覺得我在找理由拒絕需求蓖乘。
大家應(yīng)該都能感覺這樣是有問題的，需求流轉(zhuǎn)過程需要那幾個角色之間進(jìn)行溝通悄雅、哪些內(nèi)容需要溝通驱敲、何時溝通、如何溝通宽闲、輸入是什么众眨、輸出是什么不明確導(dǎo)致的。這就是用戶故事所希望避免的問題容诬。那么敏捷是如何看到這個問題并解決的呢呢娩梨？
敏捷方法論認(rèn)識到需求的復(fù)雜性和易變性，輸入的需求并不一定是對的或者最優(yōu)的览徒，并且想要開發(fā)的功能總比可以投入的資源多狈定，所以敏捷會以最小化輸出，最大化成果和價值交付為目的习蓬， 停止對完美文檔的追求纽什，轉(zhuǎn)而通過使用用戶故事促進(jìn)不同角色之間的溝通，確保各角色達(dá)成共識躲叼。
這里列出了敏捷需需求管理過程會經(jīng)常出現(xiàn)的一些工具：
用戶畫像芦缰、用戶故事、用戶故事地圖枫慷、用戶旅程地圖让蕾、價值流圖
由于篇幅關(guān)系我們今天不會對這些工具都進(jìn)行特別細(xì)致的說明，我們著重圍繞最常使用到的用戶故事和用戶故事地圖來進(jìn)行說明或听。
已經(jīng)有在實踐敏捷的同事可能會感覺到探孝，在敏捷團(tuán)隊中我們說的最多的一個詞就是用戶故事，接下來我們先了解一些用戶故事的基礎(chǔ)知識誉裆。
用戶故事
用戶故事最早是由極限編程提出來的顿颅，后來被Scrum等敏捷實踐者所借鑒并流行，現(xiàn)在用戶故事的使用已經(jīng)成了敏捷實踐的關(guān)鍵標(biāo)志足丢，用戶故事通過強(qiáng)調(diào)從用戶角度講述用戶的需要與價值元镀，讓團(tuán)隊成員從關(guān)注功能到關(guān)注價值的轉(zhuǎn)變。
用戶故事可以用來描述通過什么來滿足特定角色的需求霎桅，會為他帶來什么價值栖疑。它包括三個部分：角色、用戶需求滔驶、產(chǎn)品價值遇革。我們常常使用三段式來記錄用戶故事。
作為一個 [用戶角色] ,
我想要[結(jié)果],
以便[原因/價值]
用戶故事3C模型
一般對于剛開始實踐敏捷的團(tuán)隊我們建議大家嚴(yán)格按照這個三段式的模式來編寫用戶故事。為了便于大家理解并掌握用戶故事的基本用法萝快，可以按照用戶故事的3C模型來使用用戶故事锻霎。所謂3C模型就是指用于指導(dǎo)使用用戶故事的三個以C開頭的英文單詞，分別是：Card 卡片揪漩，Conversation 交談 旋恼，Confirmation 確認(rèn)，下面我們分別說明：
卡片（Card）
一般我們會用卡片來記錄用戶故事的相關(guān)信息奄容，用戶卡片記錄可以方便的挪動冰更、備注、討論這個故事昂勒，不同的人都可以用做標(biāo)記蜀细，做批注，更利于討論和理解戈盈，卡片上描述需要盡量簡潔奠衔，確保詞匯含義統(tǒng)一，項目成員不會對同一描述有差異性理解塘娶。
交談（Conversation）
卡片內(nèi)容是通過產(chǎn)品归斤、客戶、研發(fā)等關(guān)鍵角色之間的交談的記錄刁岸，是在溝通中獲得的脏里，而非由同一個人輸出或更新的，否則它與傳統(tǒng)的需求分析方法就沒什么區(qū)別了难捌；項目成員需要在一起共同待開發(fā)內(nèi)容進(jìn)行討論，梳理出清晰的脈絡(luò)鸦难，并達(dá)成共識根吁。
確認(rèn)（Confirmation）
每個故事應(yīng)具有驗收標(biāo)準(zhǔn)（驗收條件），以達(dá)到讓各個角色對故事的完成有統(tǒng)一的判斷標(biāo)準(zhǔn)合蔽，能夠基于這些信息來確認(rèn)故事是否被正確完成击敌。 這些信息是TDD BDD 等工程實踐得以正確執(zhí)行的基礎(chǔ)。
基于以上3C模型我們可以描述了一個用戶故事產(chǎn)生過程：PO有了一個想法拴事，按照用戶故事的三段式講故事寫到一張卡片上沃斤，然后PO與相關(guān)人一起講述故事并進(jìn)行討論，討論過程中講這個故事需要具備的要點進(jìn)行記錄刃宵，作為確認(rèn)故事完成的判定條件衡瓶。
用戶故事示例
這里是一個用戶故事的示例，可以看到卡正面是故事描述牲证，左上角是故事編號哮针，這個編號可以作為這個故事關(guān)聯(lián)文檔資料的索引線索，中間的黑體是故事標(biāo)題，我們?nèi)粘Ｕ緯帷⒂懻撎岬竭@個故事的時候一般都會通過標(biāo)題來指代這個故事卡等太，所以這個標(biāo)題既要簡潔又要能明確表明這個故事的內(nèi)容。正文部分是故事的內(nèi)容描述蛮放，這里采用的是三段式寫法缩抡。
右側(cè)這個圖是卡片的背面，這里列出了這個故事的幾個驗收標(biāo)準(zhǔn)包颁，驗收標(biāo)準(zhǔn)一般會描述在什么情況下做了什么操作得到了什么結(jié)果或反饋瞻想。大家需要注意，這里的驗收標(biāo)準(zhǔn)是用戶視角的驗收標(biāo)準(zhǔn)徘六，用于統(tǒng)一用戶内边、PO、開發(fā)團(tuán)隊對這個故事最終的完成標(biāo)準(zhǔn)的理解待锈。
Acceptance Criteria
Given 在什么情景或條件下
When 做了什么操作或采取了什么行動
Then 得到了什么結(jié)果
一般AC會由團(tuán)隊共同完成漠其，由PO和用戶做最終確認(rèn)。如果有條件我們也建議由潛在的開發(fā)人員來編寫竿音，這樣做的好處是促使更廣泛的針對故事的交流與溝通和屎。
用戶故事是另一種需求的書寫形式嗎？
用戶故事是不是只是另一種需求形式呢春瞬？只是換一個名字還是有什么不同嗎柴信？
這個問題是初入敏捷實踐的人最容易產(chǎn)生的疑惑，也是最容易陷入的誤區(qū)宽气，如果你們正在實踐敏捷随常，并且你們的故事是由產(chǎn)品人員悶頭寫出來的，那么很可能你們只是把用戶故事當(dāng)成了另一種需求寫法萄涯，而且是十分不好用的寫法绪氛，因為用戶故事本身能承載的信息十分有限，而往往需求想表達(dá)的內(nèi)容又十分繁雜涝影。
用戶故事并不簡單的只是一種新的書寫需求的方式枣察，用戶故事最主要作用是讓不同角色的人通過一起講述用戶故事， 過程通過使用文字燃逻，圖片序目，白板等方式進(jìn)行討論，最終達(dá)成共識伯襟。
用戶故事本身也不能認(rèn)為是一種需求猿涨，他可以看作是一個索引卡，代表了一系列關(guān)于卡片上問題解決方案的討論姆怪、結(jié)論嘿辟。
一個好的用戶故事應(yīng)該討論為誰做和為什么做舆瘪，而不僅僅是做什么和怎么做，對于故事卡來說红伦，重要的不是卡片上寫了什么英古，而是看到卡片時候能想到什么。
總結(jié)
希望大家至少記住下面這句話：用戶故事并不簡單的只是一種新的書寫需求的方式昙读，用戶故事最主要作用是讓不同角色的人通過一起講述用戶故事召调， 過程通過使用文字，圖片蛮浑，白板等方式進(jìn)行討論唠叛，最終達(dá)成共識。用戶故事本身也不能認(rèn)為是一種需求沮稚，他可以看作是一個索引卡艺沼，代表了一系列關(guān)于卡片上問題解決方案的討論、結(jié)論蕴掏、關(guān)聯(lián)的文檔等障般。一個好的用戶故事應(yīng)該討論為誰做和為什么做，而不僅僅是做什么和怎么做盛杰，對于故事卡來說挽荡，重要的不是卡片上寫了什么，而是看到卡片時候能想到什么即供。
說了這么多定拟，那么如果現(xiàn)在我在面臨一個項目，我該如何去產(chǎn)出用戶故事呢逗嫡？我應(yīng)該做什么準(zhǔn)備青自？我應(yīng)該從哪兒入手，到哪兒結(jié)束呢驱证？下一篇我們來介紹一個完整的用戶故事產(chǎn)生的過程延窜。
