今天芝士將以聚美優品的購物車流程作為用戶故事例子。

什么是用戶故事？

用戶故事描述對用戶，系統或軟件購買者有價值的功能。由以下2方面構成：

• 一個故事描述
• 驗收測試

用戶故事描述公式如下：

作為XXX，我想XXX，以至于XXX。

標準寫法是：作為聚美優品用戶，我想將可能購買的商品放入購物車，以至于我可以隨時付款。

由于原型已經構造出來，作為功能用戶故事簡寫為：用戶可以將需要購買的貨物加入購物車。

故事描述

驗收測試用來驗證實現的用戶故事是否符合客戶團隊的期望，有點類似于之前的需求描述，它的作用就好比檢查蛋糕是否蒸熟了的牙簽。故盡可能把所有滿足此用戶故事的情況考慮在內。

驗收測試

作為一個功能用戶故事要盡可能的小，大小是一天的開發工作量。

問：為什么是一天的開發工作量

答：為了更好的項目管理，每天開站立會議可以及時發現問題改正錯誤。工作量足夠小，也就更容易解決問題。

注意：在一張紙上，正面寫故事描述，背面寫驗收測試。

上面的用戶故事對應聚美優品如下圖藍色方框圈出的功能：

常見問題點

用戶故事編寫注意以下六個特征INVEST：

• 獨立的（Independent）
• 可討論的（Negotiable）
• 對用戶或者客戶有價值的（Valuable ?to? Purchasers ?or Users）
• 可估計的 (Estimatable)
• 小的(Small)
• 可測試的(Testable)

獨立的

我們要盡量避免故事間相互依賴。

發現有用戶故事發生依賴可以采用如下方法解決：

• 將相互依賴的用戶故事合并成一個大的獨立的故事
• 用一個不同的方式去分隔故事

問：我作為產品，怎么知道用戶故事間是否依賴。

答：和開發人員一起討論每個用戶故事，是否有依賴。說多了都是海水，你做兩個項目就知道了。

經驗鑒賞：芝士做第一個項目時，功能用戶故事都是芝士寫的（芝士大學本科是計算機），沒有和開發人員討論，導致功能故事很多地方發生冗余，芝士在第四個項目學聰明了，和開發人員一起來細分模塊，防止功能用戶故事冗余。

可討論的

故事是可以討論的，它不是簽署的合約或軟件必須實現的需求，細節處可以和開發人員以及客戶團隊討論。

問：為什么可以討論？

答：如果按照以前需求文檔，大家感覺得到任務不管是對是錯就開始開發，最后各種不滿意，各種加班重構。

對用戶或客戶有價值的

“每個用戶故事必須對用戶有價值”，這句話聽起來很吸引人，可那是不對的。

比如“所有數據庫連接要通過一個連接池”，這只是對開發人員有價值，并不是對用戶有價值，用戶只關心實現后的結果，比如“我可以修改個人信息”。

可估計的

一般有一下三個方面導致故事不可估計

• 開發人員缺少知識領域
• 開發人員缺少技術知識
• 故事太大

芝士不想講概念，直接說經驗。

可以根據開發人員以往開發過的功能進行大概估計，或者把故事再拆分小一點。

小的

合適的故事大小由團隊，它的容量及所使用的技術決定。滿足每個人一天的工作量就好。

可測試的

“用戶決不需要花很長時間等待窗口出現”，這就是不可測試的功能性故事。

我們做一些修改：

“在95%的情況下，新窗口會在2秒內打開”，這就可測試。甚至更好的是寫一個自動化測試來驗證它。

我現在放一下聚美的購物車的用戶故事，聚美在購物車處做的不是很好，通過用戶故事可以明顯感覺到用戶購買東西操作步驟太多，不能立即購買，必須進入購物車。

如果喜歡芝士的文章就分享點贊吧！

作者：芝士 ?微信號：ly2315544 ?微信訂閱號：知世說 ?歡迎分享交流。

本文由 @芝士 原創發布于人人都是產品經理。未經許可，禁止轉載。