實(shí)際的開發(fā)過程中，我們運(yùn)用如禪道、TAPD等團(tuán)隊(duì)協(xié)作軟件建立管理用戶故事，對于故事我們就可以進(jìn)行更加豐富的記錄。

一個(gè)完整的用戶故事需要寫的內(nèi)容包含：

展現(xiàn)形式如下：

一、故事標(biāo)題

用戶故事的描述在列表中進(jìn)行管理時(shí)，不利于快速理解，也不能一行展示。為每個(gè)故事取個(gè)標(biāo)題（名字）就很有必要，而且像禪道、TAPD軟件的需求表述格式中標(biāo)題也是必填項(xiàng)。

就行郵件的主題，用戶故事的標(biāo)題是為了讓讀者能快速了解這個(gè)用戶故事的要點(diǎn)和大致范圍；怎么寫好標(biāo)題也是有章可循的。
常見的做法有：

1. 用戶角度的動(dòng)賓短語

如：創(chuàng)建商品、輸入名稱、修改頭像等等這是動(dòng)作+對象形式，擅長描述從用戶看到的活動(dòng)或功能。

2. 系統(tǒng)角度的動(dòng)賓短語

此處的系統(tǒng)是指待開發(fā)的對象。

如，toast提示網(wǎng)絡(luò)異常，記錄用戶訪問次數(shù)，顯示搜索結(jié)果，顯示倒計(jì)時(shí)。擅長描述系統(tǒng)要執(zhí)行的反饋和操作。

3. 主謂賓短語

有時(shí)動(dòng)賓短語不能推斷主語時(shí)使用主謂賓短句，或者可能有可能混淆時(shí)需要明確主語，此時(shí)就需要增加動(dòng)作主語，如，超級管理員重置普通管理員的口令；A系統(tǒng)推送批量客戶和合同信息。

隨著時(shí)間推移，新增的用戶故事有不少是基于原有的功能來再提升修改，這時(shí)往往要在標(biāo)題里加上狀語來區(qū)分，比如根據(jù)客戶所在城市來查詢客戶列表，在客戶沒有登記電話號碼時(shí)強(qiáng)制客戶登記號碼。 狀語要清晰得說明用戶故事所處的情況，能夠區(qū)分類似的用戶故事。

4. 差勁標(biāo)題舉例

（1）外訪業(yè)務(wù)處理

點(diǎn)評：處理是萬金油詞語，沒有突出重點(diǎn)。

（2）設(shè)計(jì)資產(chǎn)逾期流入流出報(bào)表

點(diǎn)評：主語既不是用戶，也不是待開發(fā)的系統(tǒng)，而是開發(fā)人員，這更像是一個(gè)任務(wù)的標(biāo)題。

（3）角色分配資源

點(diǎn)評：要做什么呢？不能快速理解故事核心。

二、故事描述

固定格式“作為……（用戶角色），我想要……（完成活動(dòng)），以便于……（實(shí)現(xiàn)價(jià)值）”的格式。故事描述一這種三段式表述，相比較于傳統(tǒng)需求表述，體現(xiàn)了需求方和需求價(jià)值的重要性，也為保證了需求描述的可協(xié)商性。

三、規(guī)則描述

為了完成故事，有時(shí)需要制定故事的實(shí)現(xiàn)規(guī)則，涉及的名詞定義等。規(guī)則描述由產(chǎn)品經(jīng)理初步制定，在故事討論后，進(jìn)行修訂確認(rèn)。寫作方式就是一條條窮舉列出。注意這里不涉及原型頁面和交互規(guī)則。

四、驗(yàn)收標(biāo)準(zhǔn)

可作為驗(yàn)收測試用例的具體例子。這也是我們常說的實(shí)例化需求，也是為了避免誤讀，讓抽象的需求變得具體和可測試。
這一步很難，但非常重要。沒有明確的驗(yàn)收條件，我們便不知道如何測試，業(yè)務(wù)也不知道如何驗(yàn)收。

通常，一個(gè)用戶故事包含若干個(gè)驗(yàn)收條件，包括快樂路徑（Happy Path）與意外場景（Exceptional Scenario）。

建議將驗(yàn)收條件全部寫成“Given…When…Then”的 Gherkin 語言格式，這種寫法和測試用例類型，是一條條具體的路徑/場景，信息傳遞誤差小。延伸開來，這一原則適用于任何事情。做一件事情，以終為始，在一開始明確要做成什么樣子，行成閉環(huán)，才能指導(dǎo)行動(dòng)并確保結(jié)果正確。

五、具體設(shè)計(jì)方案

故事完成需要具體的執(zhí)行方案，方案一般都有故事實(shí)現(xiàn)的原型界面，交互規(guī)則；如果是數(shù)據(jù)類故事需求，還有數(shù)據(jù)指標(biāo)的定義等。具體設(shè)計(jì)方案的產(chǎn)出可以在故事確認(rèn)前也可以在故事確認(rèn)后，具體看產(chǎn)品的時(shí)間和團(tuán)隊(duì)的要求。

方案文件一般為附件或原型鏈接。

六、上線檢查清單

有些用戶故事的上線可能需要一些額外的步驟，在做用戶故事開發(fā)時(shí)就應(yīng)該時(shí)刻想著上線時(shí)要留意的問題，及時(shí)記錄作為備忘，以確保上線成功。
這里，確認(rèn)理解、問為什么以及驗(yàn)收條件是重點(diǎn)，作為“就緒定義”（Definition of Ready, DoR），幫助我們厘清用戶故事的具體需求。

系列文章目錄

用戶故事（一）：什么是用戶故事？

用戶故事（二）：為什么要使用用戶故事表達(dá)需求？

用戶故事（三）：用戶故事該怎么寫？

參考文章

用戶故事之好標(biāo)題

本文由 @chun 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議。