實(shí)際的開發(fā)過程中耕餐，我們運(yùn)用如禪道、TAPD等團(tuán)隊(duì)協(xié)作軟件建立管理用戶故事辟狈，對于故事我們就可以進(jìn)行更加豐富的記錄肠缔，一個完整的用戶故事需要寫的內(nèi)容包含：
展現(xiàn)形式如下：
（1）故事標(biāo)題
用戶故事的描述在列表中進(jìn)行管理時，不利于快速理解哼转，也不能一行展示明未。為每個故事取個標(biāo)題（名字）就很有必要，而且像禪道趟妥、TAPD軟件的需求表述格式中標(biāo)題也是必填項(xiàng)。就行郵件的主題佣蓉，用戶故事的標(biāo)題是為了讓讀者能快速了解這個用戶故事的要點(diǎn)和大致范圍披摄。怎么寫好標(biāo)題也是有章可循的。
常見的做法有：?
用戶角度的動賓短語
如勇凭，創(chuàng)建商品疚膊，輸入名稱，修改頭像虾标，等等這是動作+對象形式寓盗，擅長描述從用戶看到的活動或功能。
系統(tǒng)角度的動賓短語
此處的系統(tǒng)是指待開發(fā)的對象璧函。?
如傀蚌，toast提示網(wǎng)絡(luò)異常，記錄用戶訪問次數(shù)蘸吓，顯示搜索結(jié)果善炫，顯示倒計時。擅長描述系統(tǒng)要執(zhí)行的反饋和操作美澳。
主謂賓短語
有時動賓短語不能推斷主語時使用主謂賓短句销部，或者可能有可能混淆時需要明確主語摸航，此時就需要增加動作主語制跟，如舅桩，超級管理員重置普通管理員的口令；A系統(tǒng)推送批量客戶和合同信息雨膨。
隨著時間推移擂涛，新增的用戶故事有不少是基于原有的功能來再提升修改，這時往往要在標(biāo)題里加上狀語來區(qū)分聊记，比如根據(jù)客戶所在城市來查詢客戶列表撒妈，在客戶沒有登記電話號碼時強(qiáng)制客戶登記號碼。 狀語要清晰得說明用戶故事所處的情況排监，能夠區(qū)分類似的用戶故事狰右。
差勁標(biāo)題舉例
1，外訪業(yè)務(wù)處理
點(diǎn)評：處理是萬金油詞語舆床，沒有突出重點(diǎn)棋蚌。
2，設(shè)計資產(chǎn)逾期流入流出報表挨队。
點(diǎn)評：主語既不是用戶谷暮，也不是待開發(fā)的系統(tǒng)，而是開發(fā)人員盛垦，這更像是一個任務(wù)的標(biāo)題湿弦。
3，角色分配資源
點(diǎn)評：要做什么呢腾夯？不能快速理解故事核心颊埃。
（2）故事描述
固定格式“作為……（用戶角色），我想要……（完成活動）蝶俱，以便于……（實(shí)現(xiàn)價值）”的格式班利。故事描述一這種三段式表述，相比較于傳統(tǒng)需求表述跷乐，體現(xiàn)了需求方和需求價值的重要性肥败，也為保證了需求描述的可協(xié)商性。
（3）規(guī)則描述
為了完成故事愕提，有時需要制定故事的實(shí)現(xiàn)規(guī)則馒稍，涉及的名詞定義等。規(guī)則描述由產(chǎn)品經(jīng)理初步制定浅侨，在故事討論后纽谒，進(jìn)行修訂確認(rèn)。寫作方式就是一條條窮舉列出如输。注意這里不涉及原型頁面和交互規(guī)則鼓黔。
（4）驗(yàn)收標(biāo)準(zhǔn)
可作為驗(yàn)收測試用例的具體例子央勒。這也是我們常說的實(shí)例化需求，也是為了避免誤讀澳化，讓抽象的需求變得具體和可測試崔步。
這一步很難，但非常重要缎谷。沒有明確的驗(yàn)收條件井濒，我們便不知道如何測試，業(yè)務(wù)也不知道如何驗(yàn)收列林。
通常瑞你，一個用戶故事包含若干個驗(yàn)收條件，包括快樂路徑（Happy Path）與意外場景（Exceptional Scenario）希痴。
建議將驗(yàn)收條件全部寫成“Given…When…Then”的 Gherkin 語言格式者甲，這種寫法和測試用例類型，是一條條具體的路徑/場景砌创，信息傳遞誤差小虏缸。延伸開來，這一原則適用于任何事情纺铭。做一件事情寇钉，以終為始，在一開始明確要做成什么樣子舶赔，行成閉環(huán)扫倡，才能指導(dǎo)行動并確保結(jié)果正確。
（5）具體設(shè)計方案
故事完成需要具體的執(zhí)行方案竟纳，方案一般都有故事實(shí)現(xiàn)的原型界面撵溃，交互規(guī)則；如果是數(shù)據(jù)類故事需求锥累，還有數(shù)據(jù)指標(biāo)的定義等缘挑。具體設(shè)計方案的產(chǎn)出可以在故事確認(rèn)前也可以在故事確認(rèn)后，具體看產(chǎn)品的時間和團(tuán)隊(duì)的要求桶略。
方案文件一般為附件或原型鏈接语淘。
（6）上線檢查清單
有些用戶故事的上線可能需要一些額外的步驟，在做用戶故事開發(fā)時就應(yīng)該時刻想著上線時要留意的問題际歼，及時記錄作為備忘惶翻，以確保上線成功。
這里鹅心，確認(rèn)理解吕粗、問為什么以及驗(yàn)收條件是重點(diǎn)，作為“就緒定義”（Definition of Ready, DoR）旭愧，幫助我們厘清用戶故事的具體需求颅筋。
---
參考：
