在輔導(dǎo)團(tuán)隊(duì)實(shí)踐敏捷的過程中，用戶故事的使用經(jīng)常是面臨的第一個(gè)問題，也是一個(gè)很難解決的棘手問題，究其原因就是很多團(tuán)隊(duì)會(huì)習(xí)慣性把用戶故事作為傳統(tǒng)需求的代替，認(rèn)為只是換了一種寫法而已，這就導(dǎo)致很多團(tuán)隊(duì)表面在跑敏捷，實(shí)際上還是在用傳統(tǒng)的思路在工作。我們希望能通過這篇文章讓你理解敏捷需求管理的基本思路和方法。
文章由兩部分構(gòu)成，用戶故事的相關(guān)基礎(chǔ)知識(shí)以及如何使用用戶故事地圖這個(gè)工具來產(chǎn)出用戶故事。
前言
首先我們看一下下面這個(gè)圖，這是對需求再用戶 產(chǎn)品 研發(fā)之間流動(dòng)關(guān)系的一個(gè)抽象描述，描述了產(chǎn)品經(jīng)理從用戶那里獲取新的需求或者對已有功能的反饋，作為研發(fā)團(tuán)隊(duì)的輸入，研發(fā)團(tuán)隊(duì)完成功能開發(fā)后提供給用戶使用，產(chǎn)品經(jīng)理收集反饋進(jìn)一步指導(dǎo)研發(fā)的開發(fā)工作。無論是傳統(tǒng)項(xiàng)目還是敏捷項(xiàng)目這個(gè)過程都是一樣的，而我們的目的就是促進(jìn)這個(gè)循環(huán)關(guān)系不斷改進(jìn)和提效。
但是傳統(tǒng)項(xiàng)目管理方法在改進(jìn)這個(gè)過程中遇到了不小的困難，我們看一個(gè)如下的對話場景：
產(chǎn)品 ：
我這里有個(gè)新需求，比較急，你抓緊時(shí)間給加一下
小王 ：
好的，沒問題，但是能告訴我為什么要加這幾個(gè)功能嗎？想解決用戶的什么問題呢？
產(chǎn)品 ：
你做就好了，這個(gè)是客戶（領(lǐng)導(dǎo)）要求的，一時(shí)半會(huì)兒也說不清楚，反正需求就是這樣
小王 ：
那你能給我講講這些功能都給哪些用戶使用？
用戶在什么情況下會(huì)使用這些功能嗎？
用戶是如何使用這些功能的？
這些功能和用戶工作是如何結(jié)合的呢？
產(chǎn)品 ：
（看奇葩一樣看著小王，不耐煩的說）
需求就是這樣的，你照著做就行了，不用問這么多，出了問題我兜著
小王 ： ...
大家可以思考一下是否遇到過類似的問題，我實(shí)際工作中就遇到過開發(fā)人員只了解一部分自己涉及的東西，甚至對功能誰來用、什么場景用、怎么用都沒搞清楚，最后需要業(yè)務(wù)測試時(shí)候才發(fā)現(xiàn)從開發(fā)到測試都不了解這個(gè)系統(tǒng)的使用流程，只是在按照上游輸入的信息被動(dòng)的進(jìn)行工作，可以想象這種情況下產(chǎn)品的質(zhì)量。所謂需求很多時(shí)候已經(jīng)變成了命令而非信息傳遞的載體。
這段對話我分別給產(chǎn)品和研發(fā)都看過，我摘抄了幾個(gè)比較典型的觀點(diǎn)列到這里
產(chǎn)品：
- 我很少遇到這么負(fù)責(zé)的開發(fā)，如果真有人這么問我我會(huì)非常樂意給他講的。
- 我們這個(gè)系統(tǒng)太復(fù)雜，要想讓所有開發(fā)都搞清楚使用場景和邏輯確實(shí)有點(diǎn)困難。
- 需求是從領(lǐng)導(dǎo)和客戶那里來的，領(lǐng)導(dǎo)要求了只能照著做，沒辦法。
研發(fā)：
- 我每天加班加點(diǎn)的，哪有時(shí)間管這些，讓我怎么改就改唄。
- 我有興趣了解這些信息，但是大家都很忙，也不知道什么時(shí)候該問。
- 研發(fā)問這些是不是在挑戰(zhàn)產(chǎn)品的專業(yè)性啊，會(huì)不會(huì)讓產(chǎn)品覺得我在找理由拒絕需求。
大家應(yīng)該都能感覺這樣是有問題的，需求流轉(zhuǎn)過程需要那幾個(gè)角色之間進(jìn)行溝通、哪些內(nèi)容需要溝通、何時(shí)溝通、如何溝通、輸入是什么、輸出是什么不明確導(dǎo)致的。這就是用戶故事所希望避免的問題。那么敏捷是如何看到這個(gè)問題并解決的呢呢？
敏捷方法論認(rèn)識(shí)到需求的復(fù)雜性和易變性，輸入的需求并不一定是對的或者最優(yōu)的，并且想要開發(fā)的功能總比可以投入的資源多，所以敏捷會(huì)以最小化輸出，最大化成果和價(jià)值交付為目的， 停止對完美文檔的追求，轉(zhuǎn)而通過使用用戶故事促進(jìn)不同角色之間的溝通，確保各角色達(dá)成共識(shí)。
這里列出了敏捷需需求管理過程會(huì)經(jīng)常出現(xiàn)的一些工具：
用戶畫像、用戶故事、用戶故事地圖、用戶旅程地圖、價(jià)值流圖
由于篇幅關(guān)系我們今天不會(huì)對這些工具都進(jìn)行特別細(xì)致的說明，我們著重圍繞最常使用到的用戶故事和用戶故事地圖來進(jìn)行說明。
已經(jīng)有在實(shí)踐敏捷的同事可能會(huì)感覺到，在敏捷團(tuán)隊(duì)中我們說的最多的一個(gè)詞就是用戶故事，接下來我們先了解一些用戶故事的基礎(chǔ)知識(shí)。
用戶故事
用戶故事最早是由極限編程提出來的，后來被Scrum等敏捷實(shí)踐者所借鑒并流行，現(xiàn)在用戶故事的使用已經(jīng)成了敏捷實(shí)踐的關(guān)鍵標(biāo)志，用戶故事通過強(qiáng)調(diào)從用戶角度講述用戶的需要與價(jià)值，讓團(tuán)隊(duì)成員從關(guān)注功能到關(guān)注價(jià)值的轉(zhuǎn)變。
用戶故事可以用來描述通過什么來滿足特定角色的需求，會(huì)為他帶來什么價(jià)值。它包括三個(gè)部分：角色、用戶需求、產(chǎn)品價(jià)值。我們常常使用三段式來記錄用戶故事。
作為一個(gè) [用戶角色] ,
我想要[結(jié)果],
以便[原因/價(jià)值]
用戶故事3C模型
一般對于剛開始實(shí)踐敏捷的團(tuán)隊(duì)我們建議大家嚴(yán)格按照這個(gè)三段式的模式來編寫用戶故事。為了便于大家理解并掌握用戶故事的基本用法，可以按照用戶故事的3C模型來使用用戶故事。所謂3C模型就是指用于指導(dǎo)使用用戶故事的三個(gè)以C開頭的英文單詞，分別是：Card 卡片，Conversation 交談 ，Confirmation 確認(rèn)，下面我們分別說明：
卡片（Card）
一般我們會(huì)用卡片來記錄用戶故事的相關(guān)信息，用戶卡片記錄可以方便的挪動(dòng)、備注、討論這個(gè)故事，不同的人都可以用做標(biāo)記，做批注，更利于討論和理解，卡片上描述需要盡量簡潔，確保詞匯含義統(tǒng)一，項(xiàng)目成員不會(huì)對同一描述有差異性理解。
交談（Conversation）
卡片內(nèi)容是通過產(chǎn)品、客戶、研發(fā)等關(guān)鍵角色之間的交談的記錄，是在溝通中獲得的，而非由同一個(gè)人輸出或更新的，否則它與傳統(tǒng)的需求分析方法就沒什么區(qū)別了；項(xiàng)目成員需要在一起共同待開發(fā)內(nèi)容進(jìn)行討論，梳理出清晰的脈絡(luò)，并達(dá)成共識(shí)。
確認(rèn)（Confirmation）
每個(gè)故事應(yīng)具有驗(yàn)收標(biāo)準(zhǔn)（驗(yàn)收條件），以達(dá)到讓各個(gè)角色對故事的完成有統(tǒng)一的判斷標(biāo)準(zhǔn)，能夠基于這些信息來確認(rèn)故事是否被正確完成。 這些信息是TDD BDD 等工程實(shí)踐得以正確執(zhí)行的基礎(chǔ)。
基于以上3C模型我們可以描述了一個(gè)用戶故事產(chǎn)生過程：PO有了一個(gè)想法，按照用戶故事的三段式講故事寫到一張卡片上，然后PO與相關(guān)人一起講述故事并進(jìn)行討論，討論過程中講這個(gè)故事需要具備的要點(diǎn)進(jìn)行記錄，作為確認(rèn)故事完成的判定條件。
用戶故事示例
這里是一個(gè)用戶故事的示例，可以看到卡正面是故事描述，左上角是故事編號，這個(gè)編號可以作為這個(gè)故事關(guān)聯(lián)文檔資料的索引線索，中間的黑體是故事標(biāo)題，我們?nèi)粘Ｕ緯?huì)、討論提到這個(gè)故事的時(shí)候一般都會(huì)通過標(biāo)題來指代這個(gè)故事卡，所以這個(gè)標(biāo)題既要簡潔又要能明確表明這個(gè)故事的內(nèi)容。正文部分是故事的內(nèi)容描述，這里采用的是三段式寫法。
右側(cè)這個(gè)圖是卡片的背面，這里列出了這個(gè)故事的幾個(gè)驗(yàn)收標(biāo)準(zhǔn)，驗(yàn)收標(biāo)準(zhǔn)一般會(huì)描述在什么情況下做了什么操作得到了什么結(jié)果或反饋。大家需要注意，這里的驗(yàn)收標(biāo)準(zhǔn)是用戶視角的驗(yàn)收標(biāo)準(zhǔn)，用于統(tǒng)一用戶、PO、開發(fā)團(tuán)隊(duì)對這個(gè)故事最終的完成標(biāo)準(zhǔn)的理解。
Acceptance Criteria
Given 在什么情景或條件下
When 做了什么操作或采取了什么行動(dòng)
Then 得到了什么結(jié)果
一般AC會(huì)由團(tuán)隊(duì)共同完成，由PO和用戶做最終確認(rèn)。如果有條件我們也建議由潛在的開發(fā)人員來編寫，這樣做的好處是促使更廣泛的針對故事的交流與溝通。
用戶故事是另一種需求的書寫形式嗎？
用戶故事是不是只是另一種需求形式呢？只是換一個(gè)名字還是有什么不同嗎？
這個(gè)問題是初入敏捷實(shí)踐的人最容易產(chǎn)生的疑惑，也是最容易陷入的誤區(qū)，如果你們正在實(shí)踐敏捷，并且你們的故事是由產(chǎn)品人員悶頭寫出來的，那么很可能你們只是把用戶故事當(dāng)成了另一種需求寫法，而且是十分不好用的寫法，因?yàn)橛脩艄适卤旧砟艹休d的信息十分有限，而往往需求想表達(dá)的內(nèi)容又十分繁雜。
用戶故事并不簡單的只是一種新的書寫需求的方式，用戶故事最主要作用是讓不同角色的人通過一起講述用戶故事， 過程通過使用文字，圖片，白板等方式進(jìn)行討論，最終達(dá)成共識(shí)。
用戶故事本身也不能認(rèn)為是一種需求，他可以看作是一個(gè)索引卡，代表了一系列關(guān)于卡片上問題解決方案的討論、結(jié)論。
一個(gè)好的用戶故事應(yīng)該討論為誰做和為什么做，而不僅僅是做什么和怎么做，對于故事卡來說，重要的不是卡片上寫了什么，而是看到卡片時(shí)候能想到什么。
總結(jié)
希望大家至少記住下面這句話：用戶故事并不簡單的只是一種新的書寫需求的方式，用戶故事最主要作用是讓不同角色的人通過一起講述用戶故事， 過程通過使用文字，圖片，白板等方式進(jìn)行討論，最終達(dá)成共識(shí)。用戶故事本身也不能認(rèn)為是一種需求，他可以看作是一個(gè)索引卡，代表了一系列關(guān)于卡片上問題解決方案的討論、結(jié)論、關(guān)聯(lián)的文檔等。一個(gè)好的用戶故事應(yīng)該討論為誰做和為什么做，而不僅僅是做什么和怎么做，對于故事卡來說，重要的不是卡片上寫了什么，而是看到卡片時(shí)候能想到什么。
說了這么多，那么如果現(xiàn)在我在面臨一個(gè)項(xiàng)目，我該如何去產(chǎn)出用戶故事呢？我應(yīng)該做什么準(zhǔn)備？我應(yīng)該從哪兒入手，到哪兒結(jié)束呢？下一篇我們來介紹一個(gè)完整的用戶故事產(chǎn)生的過程。
