建站
咨詢
售后
建站咨詢
新聞中心
故事卡應(yīng)盡量簡練，而非事無巨細(xì)應(yīng)寫都寫;同時，應(yīng)盡量完整、準(zhǔn)確，而非缺少細(xì)節(jié)、模棱兩可。
這是我的基礎(chǔ)觀點，我的考慮如下：
- 簡練意味著讀者獲取的信息是經(jīng)過提煉的，讀者閱讀起來是更高效的。
- 簡練意味著 BA 寫卡可以更高效，可以投入更多精力在其他更具挑戰(zhàn)的工作內(nèi)容上。
- 完整、準(zhǔn)確意味著故事卡是經(jīng)過討論并達(dá)成一致的。
- 完整、準(zhǔn)確意味著故事卡是有著清晰驗收標(biāo)準(zhǔn)的。
- 完整、準(zhǔn)確意味著故事卡是便于追溯、便于傳遞的。
- ……
基于以上觀點再分類別展開聊下。
關(guān)于對頁面交互的描述
上圖展示了一個添加新賬號功能的 UI 設(shè)計。一種對該功能需求的描述可能是：
- 用戶通過主菜單進(jìn)入“權(quán)限管理”模塊，選擇“賬號管理” Tab 頁，可以看到“新增賬號”按鈕。
- 點擊“新增賬號”按鈕，系統(tǒng)彈出新增賬號窗口(可能還會寫一句“背景置灰”)。
- 用戶可在窗口中填寫姓名、登錄郵箱……
- 若用戶未填寫必填字段，則點擊“確認(rèn)”時給出錯誤提醒“請完成所有必填字段的填寫!”
- 點擊“確認(rèn)”按鈕后彈出二次確認(rèn)窗口，二次確認(rèn)信息為“確認(rèn)創(chuàng)建該賬號?賬號一旦創(chuàng)建成功即會郵件通知對應(yīng)用戶”。用戶再次選擇“確認(rèn)”則系統(tǒng)創(chuàng)建賬號，若用戶選擇“取消”則返回填寫賬號窗口。
這些文字描述沒有任何錯誤，應(yīng)該還符合不少 Dev 同學(xué)或 QA 同學(xué)的胃口，但在我看來過于臃腫。嘗試思考簡化哪些信息不會影響 Dev 編碼和各角色理解業(yè)務(wù)：
(1) 詳細(xì)的操作步驟描述是否必要？
通常是不必要的。一般情況下設(shè)計圖或簡單的溝通是很容易表達(dá)這些內(nèi)容的，故事卡中簡單地表述主要路徑即可，詳細(xì)的描述反而約束了設(shè)計和實現(xiàn)，并且讓故事卡變得臃腫。
(2) 描述所有字段是否有必要?
通常是需要的，但應(yīng)該是從業(yè)務(wù)角度描述，后文有詳細(xì)聊到。
(3) 詳細(xì)地描述用戶操作后的系統(tǒng)反饋是否有必要？
通常不是必要的，因為絕大多數(shù)的系統(tǒng)反饋是約定俗稱或顯而易見的。比如 popup 窗口下方的頁面是被置灰的，popup 窗口上的“取消”按鈕點了后會關(guān)閉窗口，等等。那什么是“不通?！钡那闆r呢?常見的是期望系統(tǒng)根據(jù)業(yè)務(wù)目標(biāo)給出的反饋，比如我會注明“創(chuàng)建用戶成功后頁面應(yīng)跳轉(zhuǎn)回列表頁”，因為我知道管理員通常會批量創(chuàng)建多個用戶，這樣效率更高。
(4) 二次確認(rèn)功能中的文案是否有必要詳細(xì)描述呢？
很多時候是需要的，因為這些文案通常是想表達(dá)特定的業(yè)務(wù)含義的，用完美的文案將這層業(yè)務(wù)含義表達(dá)出來是 BA 的職責(zé)。那反過來的情況呢?比如一些常規(guī)的刪除操作的確認(rèn)文案就不需要一一描述，可以與團(tuán)隊約定好所有的刪除操作都需要二次確認(rèn)，所有的二次確認(rèn)文案都是“確認(rèn)刪除該xx?刪除后不可恢復(fù)”，如有特殊情況再單獨表述。
那么對于上面的需求，我的描述會是這樣的：
權(quán)限管理員可創(chuàng)建新的用戶：
(1) 路徑：后臺管理端 - 權(quán)限管理 - 賬號管理 - “新增賬號” button
(2) 新增賬號所需字段
- 姓名…
- 登錄郵箱…
- ……
(3) 確認(rèn)創(chuàng)建賬號需二次確認(rèn)，文案“確認(rèn)創(chuàng)建該賬號?賬號一旦創(chuàng)建成功即會郵件通知對應(yīng)用戶”
簡單總結(jié)一下，在我的觀點中，故事卡通常不應(yīng)對頁面交互做過多描述，這樣可能會約束設(shè)計和實現(xiàn)，還容易讓故事卡失去業(yè)務(wù)焦點。但若某個期望的交互具有獨特性或交互本身就是重要的驗收點，那么將他們簡練、準(zhǔn)確地表述出來也是必要的。
關(guān)于對業(yè)務(wù)邏輯的描述
這里的業(yè)務(wù)邏輯可以狹義地理解為功能需求中的規(guī)律或規(guī)則，是我認(rèn)為“如果有則必須體現(xiàn)在故事卡”的內(nèi)容。我的理由如下：
- 它們通常是適配特定業(yè)務(wù)場景的，不是可以通過普遍認(rèn)知推導(dǎo)出來的。
- 它們通常是核心的，直接決定著需求是否能達(dá)到預(yù)期收益。
- 它們通常是復(fù)雜的、難以記憶的。
所以我們可以直接討論下如何簡潔、準(zhǔn)確地描述這些規(guī)則。
曾經(jīng)處理過一個關(guān)于預(yù)約送貨的需求。背景是客戶采購“我們”的商品，物流承運商負(fù)責(zé)將貨物運送到客戶倉庫，但客戶倉庫常出現(xiàn)沒有可用倉位而導(dǎo)致承運商送貨到庫卻又無法卸貨入庫的情況。解決方案是客戶側(cè)開發(fā)預(yù)約留庫位功能并提供接口，我們調(diào)用該接口，告訴客戶方系統(tǒng)預(yù)計送貨信息，客戶系統(tǒng)對應(yīng)預(yù)留倉位并反饋期望送貨時間，承運商確認(rèn)后按該時間送貨。
這個業(yè)務(wù)場景的特點在于每個節(jié)點都有多種不確定性，由此為后續(xù)流程帶來不同的影響。在業(yè)務(wù)已經(jīng)梳理清晰的前提下，這其實就是一個如何表達(dá)結(jié)構(gòu)化信息的問題。
首先試下 Given When Then 的表達(dá)方式：
AC01 預(yù)約日期在窗口范圍內(nèi)
When 客戶系統(tǒng)返回了“在預(yù)約窗口范圍內(nèi)”的預(yù)約日期
Then 郵件通知承運商確認(rèn)，變更預(yù)約單狀態(tài)為“待承運商確認(rèn)”
AC02 預(yù)約日期在窗口范圍外
When 客戶系統(tǒng)返回了“不在預(yù)約窗口范圍內(nèi)”的預(yù)約日期，且未人工確認(rèn)
Then 郵件通知銷售負(fù)責(zé)人協(xié)調(diào)處理，變更預(yù)約單狀態(tài)為“待銷售確認(rèn)”
AC03 預(yù)約日期已人工確認(rèn)
WHEN 客戶系統(tǒng)返回了“不在預(yù)約窗口范圍內(nèi)”但被標(biāo)記為“已人工確認(rèn)”的預(yù)約日期
Then 預(yù)約成功，變更預(yù)約單狀態(tài)為“預(yù)約完成”，郵件通知承運商按預(yù)約日期送貨
……
看起來能把每個細(xì)節(jié)表達(dá)清楚，但可讀性比較差，讀者可能需要額外的 effort 才能理清各場景間的邏輯關(guān)系。
然后嘗試下 “BA 式” 的偽代碼：
「
If 約定時限內(nèi)獲取到了客戶系統(tǒng)反饋的預(yù)約日期
{
if 日期在預(yù)約窗口范圍內(nèi)
郵件通知承運商確認(rèn)，變更預(yù)約單狀態(tài)為“待承運商確認(rèn)”；
else if 日期已人工確認(rèn)
預(yù)約成功，變更預(yù)約單狀態(tài)為“預(yù)約完成”
else
郵件通知銷售負(fù)責(zé)人協(xié)調(diào)處理，變更預(yù)約單狀態(tài)為“待銷售確認(rèn)”
}
else…
」
邏輯關(guān)系表述清楚了，但閱讀大段滿載邏輯的文字的體驗仍然不好，似乎可以再簡潔點。
最終我將這些規(guī)則用狀態(tài)轉(zhuǎn)換圖描述出來，然后與 Dev 和 QA 同學(xué)溝通是否可以用這張圖當(dāng)做驗收條件。在與他們講解了這個圖后，大家認(rèn)為只要對圖中各節(jié)點的業(yè)務(wù)意義達(dá)成一致并約定好 Scope(而這些是比較容易的)，這樣的表述是更清晰、更友好的，于是我們愉快地接受了這種方式。
簡單總結(jié)一下，在我看來，對業(yè)務(wù)邏輯的表述是寫故事卡的重點和難點，BA 應(yīng)該結(jié)合項目和需求特征選擇最佳表達(dá)形式，不用拘泥于固定的格式，其中圖表經(jīng)常是不錯的選擇。關(guān)于圖表的使用有以下 tips 供參考：
- 復(fù)雜條件組合產(chǎn)生不同系統(tǒng)行為 (比如積分判定規(guī)則)> 判定表、判定樹或事件 - 響應(yīng)表
- 復(fù)雜狀態(tài)規(guī)則(比如訂單狀態(tài)規(guī)則)> 狀態(tài)流轉(zhuǎn)圖或狀態(tài)表
- 復(fù)雜業(yè)務(wù)流程 (比如采購流程)> 業(yè)務(wù)流程圖
- ……
另外，團(tuán)隊需要就如何理解這些新的表達(dá)方式達(dá)成一致。
關(guān)于對列表和表單的描述
列表和表單是最常見和最基礎(chǔ)的需求，往往套用固定的模式就可以將其表述清楚。
列表類需求常見的幾要素：
- 功能權(quán)限：誰在什么條件下可以使用該表單
- 數(shù)據(jù)權(quán)限：數(shù)據(jù)范圍的控制通常體現(xiàn)在列表上，比如用戶僅可見owner 是他自己的訂單記錄。
- 排序規(guī)則：列表中的記錄通常需要按一定的規(guī)則進(jìn)行排序以便查看
- 分頁規(guī)則：如果某些列表中可以預(yù)見地記錄不會太多，那么不一定需要分頁，Dev 可以更簡單地處理這樣的列表。
- 字段清單：對列表中所有字段的描述。UX 的設(shè)計圖中會有這部分內(nèi)容的體現(xiàn)，但經(jīng)驗看來設(shè)計圖中不容易也不需要很及時地反饋字段的變化，在某些條件下設(shè)計圖也無法體現(xiàn)所有字段。
- 字段屬性：字段對應(yīng)的業(yè)務(wù)含義，告訴讀者這個字段的值從何而來，如果某字段有特殊規(guī)則也可以在這里體現(xiàn)。比如【持續(xù)時長】字段是為了方便用戶查看，實際不對應(yīng)數(shù)據(jù)庫字段，那這里就可以描述它的取值規(guī)則為“【當(dāng)前時間】 - 【開始時間】，向上取整天”;再比如【門店名稱】通常較長但又很重要，我會描述“鼠標(biāo)hover 在【門店名稱】時可查看其完整信息”。
一個有關(guān)列表的驗收條件參考如下：
AC01 查看發(fā)貨單列表：
(1) 路徑：主菜單 > 發(fā)貨單列表
(2) 功能權(quán)限：權(quán)限管理中新增“查看發(fā)貨單”權(quán)限，僅具有該權(quán)限的用戶可見“發(fā)貨單列表”菜單并訪問列表數(shù)據(jù)
(3) 數(shù)據(jù)權(quán)限：承運商用戶僅可查看他負(fù)責(zé)的發(fā)貨單，銷售用戶僅可查看他負(fù)責(zé)的客戶的發(fā)貨單，其他角色可見所有發(fā)貨單
(4) 排序規(guī)則：按發(fā)貨單創(chuàng)建時間倒序排列
(5) 分頁規(guī)則：15個/頁
(6) 字段詳情及順序
- 【發(fā)貨單創(chuàng)建時間】系統(tǒng)接收到承運商 TMS 系統(tǒng)推送的發(fā)貨單的時間，精確到分鐘
- 【發(fā)貨單號】承運商 TMS 系統(tǒng)的發(fā)貨單號
- 【門店訂單號】發(fā)貨單對應(yīng)門店訂單的編號
- 【門店名稱】發(fā)貨單對應(yīng)的收貨門店名稱，鼠標(biāo) hover 可查看完整名稱
- ……
關(guān)于表單類功能需求
表單通常是用于創(chuàng)建記錄、更新記錄、查看記錄的詳細(xì)信息，相比列表類需求對字段屬性的描述有以下幾點需要注意：
- 是否必須。
- 數(shù)據(jù)類型：比如對于時間類型字段，前端同學(xué)會處理為日期&時間選擇器。
- 校驗規(guī)則：比如對用戶名格式或?qū)γ艽a復(fù)雜度的校驗。
- 若是pick list，那么選項是什么：選項可能是一些枚舉值，也可能是自另外的一個業(yè)務(wù)實體(比如為訂單選擇客戶)，需要詳細(xì)說明。
- 字符長度：從業(yè)務(wù)角度給出字段長度建議。
所以某個表單的描述可能是這樣的：
(1) ……
(2) 字段詳情及順序
- 【姓名】必填，50字符
- 【出生年月】必填，日期類型
- 【省份】必填，單選，從基礎(chǔ)數(shù)據(jù) region 表中取值
- 【城市】必填，單選，從基礎(chǔ)數(shù)據(jù) region 表中取值，與【省份】聯(lián)動
- 【家庭成員數(shù)量】必填，正整數(shù)
- 【聯(lián)系郵箱】非必填，100字符，校驗為郵箱格式
- ……
這里面也有幾個可以探討的問題：
(1) 對于【聯(lián)系人郵箱】字段，通常會有對于郵箱格式的校驗。那么 BA 在故事卡里是否需要詳細(xì)描述校驗規(guī)則?
我的建議是沒必要。因為郵箱的格式校驗是一個有著“普遍認(rèn)同”的規(guī)則，并不具備獨特的業(yè)務(wù)價值，不該因為 BA 的表述不同而不同。所以，這種問題可以交給 Dev 同學(xué)。
(2) 是否需要以及如何描述字符長度/數(shù)值范圍?
我的建議是可以描述。以字符長度為例，大多數(shù)字段其實是比較容易推斷出字符長度的，比如“訂單狀態(tài)”，10個字符足矣，Dev 和 BA 從各自視角判斷通常也偏差不大。那既然如此，BA 就順手寫出來吧，更何況存在某些字段在特定業(yè)務(wù)場景下有特殊要求的可能。
可能還有其他問題可以進(jìn)一步討論，但總而言之，對于列表和表單類需求通?？梢詮?fù)用一套模板，再結(jié)合業(yè)務(wù)場景調(diào)整就可以搞定。
關(guān)于對接口的描述
個人最喜歡的就是接口類的故事卡了，無他，但簡單爾。
對于接口類需求，我通常做法是：
- BA 定義好接口業(yè)務(wù)上的數(shù)據(jù)結(jié)構(gòu)、業(yè)務(wù)主鍵
- 與 Dev 線下討論達(dá)成一致
- Dev 補(bǔ)充技術(shù)細(xì)節(jié)形成接口文檔
- 把接口文檔附在故事卡里，補(bǔ)充業(yè)務(wù)場景、調(diào)用頻率(對于主動拉取數(shù)據(jù)類接口)、錯誤處理機(jī)制(比如提交訂單失敗后應(yīng)重試還是立即報錯)、接口獲取/提供的信息的特殊處理(比如外系統(tǒng)給到的訂單我們要按照自己的規(guī)則生成新的訂單編號)等必要信息。
最后，對用戶故事業(yè)務(wù)價值的描述和故事卡的拆分也簡單分享下我的理解
我非常贊同每個故事卡都應(yīng)該產(chǎn)生業(yè)務(wù)價值，并且我們應(yīng)當(dāng)將這個價值顯式地表達(dá)出來。而實踐下來，我發(fā)現(xiàn)一段“freestyle” 式的描述常常比“作為一個 <角色> , 我想要 <功能> , 以便于 <業(yè)務(wù)價值> ”這樣的表述方式更容易上手。
比如，某個需求是從主數(shù)據(jù)系統(tǒng)定時獲取最新的產(chǎn)品主數(shù)據(jù)，那么我會用這樣的一段文字來描述：
Summary：當(dāng)前條件下，系統(tǒng)中的產(chǎn)品數(shù)據(jù)來自于每月客戶側(cè)產(chǎn)品經(jīng)理給到的Excel 文件更新。客戶自主研發(fā)的主數(shù)據(jù)平臺已與上個月正式上線，并對外提供了數(shù)據(jù)分發(fā)接口，我們可以通過它提供的產(chǎn)品主數(shù)據(jù)接口每天獲取產(chǎn)品主數(shù)據(jù)的更新，以解決手工更新帶來的更新不及時、手工處理出錯等問題。
基于這種更自然的表達(dá)方式，我可以輕松地描述更多有價值的信息。
最后是我對 INVEST 原則(好的用戶故事的編寫應(yīng)滿足的幾個原則)的一些理解：
- 獨立性(Independent) ：應(yīng)盡量避免故事間的強(qiáng)依賴，但若必須有強(qiáng)依賴，那么這些卡片應(yīng)該可以在同一個迭代中完成。非獨立的故事會造成估算、排優(yōu)先級和制定技術(shù)方案的難度。避免強(qiáng)依賴的方法可以有合并故事卡、換個維度拆分故事等，實在不行也不用強(qiáng)求，按依賴排好優(yōu)先級即可。
- 可討論的(Negotiable)：實現(xiàn)方案是可討論的，但業(yè)務(wù)目標(biāo)應(yīng)是明確的;討論是必要的，對方案達(dá)成一致更不可缺少;可討論不是BA 不去提前思考具體解決方案的借口，更不是卡片中驗收標(biāo)準(zhǔn)不明確的說辭。
- 有價值(Valuable)：我想不出我們?nèi)プ鲆粋€沒有價值的需求的理由…… 姑且把這一條理解為在寫下這張卡片時我們應(yīng)該已充分了解它能解決的問題或帶來的收益，并且所有角色已經(jīng)對此達(dá)成一致。
- 可以估算(Estimable)：估算通常是為了排期，為了可以估算故事的規(guī)模應(yīng)該足夠小，團(tuán)隊對故事應(yīng)該有充分的了解，并可以就故事內(nèi)容對技術(shù)實現(xiàn)方案基本達(dá)成一致。
- 足夠小(Small)：更小的故事有助于更準(zhǔn)確的工作量評估或多人并行工作，可以讓故事卡在卡墻上更快流動起來，但也不必過分追求小故事，不少情況下 Dev 一次代碼提交同時處理兩個關(guān)聯(lián)需求要比先后處理這兩個需求要更簡單、高效，如果 Dev 經(jīng)常說“這幾張卡我一起開了吧”或“關(guān)了吧”時，BA 可以請教一下他的想法，也許能發(fā)現(xiàn)值得改進(jìn)的地方。
- 可測試(Testable)：故事卡中描述的輸入和輸出是明確的、可度量的。
文章的最最后，再總結(jié)下我的觀點
- 我認(rèn)同故事卡里非常詳細(xì)的描述可以帶來價值，但我也相信“簡練的表述 + 充分的溝通”可以更高效、更靈活。
- 我認(rèn)同故事卡不是契約或合同，但我也相信完整、準(zhǔn)確的表述可以顯著降低各角色間的溝通成本。
- 我認(rèn)同可工作的軟件高于詳盡的需求文檔，但我也相信高質(zhì)量的需求文檔可以帶來很多收益。
- 我認(rèn)同最佳實踐和個人經(jīng)驗(包括本文以上所有內(nèi)容)的參考價值，但我更相信因地制宜、團(tuán)隊共建的實踐才是最好的選擇。
網(wǎng)站題目：關(guān)于編寫故事卡的一些經(jīng)驗
文章鏈接：http://www.dlmjj.cn/article/cdgsejs.html
