用戶故事(三):用戶故事該怎么寫?
實(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),幫助我們厘清用戶故事的具體需求。
系列文章目錄
參考文章
本文由 @chun 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于CC0協(xié)議。
希望有個(gè)實(shí)例哈
最差的文章就是純理論,而不結(jié)合實(shí)例
用戶故事,能舉個(gè)示例嗎,沒有實(shí)例對照,看著蒙,不理解。
展現(xiàn)形式那張圖對應(yīng)的是前端一個(gè)頁面的一個(gè)功能點(diǎn),這下你懂了吧。如果描述還很模糊則需要繼續(xù)拆story
如果是一整個(gè)完整的新系統(tǒng),要講好這個(gè)系統(tǒng)的用戶故事,這個(gè)格式仍然適用嗎?
同求規(guī)則描述的具體說明啊,不是很理解
您好,規(guī)則描述能舉個(gè)具體一些的例子嗎?根據(jù)文章描述還不是很理解應(yīng)該要寫什么?
我的了解 哈,比如設(shè)計(jì)了一個(gè)指標(biāo)是商戶調(diào)用的活躍度,分為高中低,就需要在規(guī)則描述中詳細(xì)定義高中低分別表示哪些條件
我對這個(gè)問題也同樣疑惑,文中說的“具體設(shè)計(jì)方案”就有數(shù)據(jù)指標(biāo)的定義,這個(gè)規(guī)則描述有什么區(qū)別嗎?這些規(guī)則和交互規(guī)則有點(diǎn)難區(qū)分