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

什么是用戶故事？

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

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

用戶故事描述公式如下：

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

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

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

故事描述

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

驗收測試

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

問：為什么是一天的開發(fā)工作量

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

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

上面的用戶故事對應(yīng)聚美優(yōu)品如下圖藍色方框圈出的功能：

常見問題點

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

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

獨立的

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

發(fā)現(xiàn)有用戶故事發(fā)生依賴可以采用如下方法解決：

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

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

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

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

可討論的

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

問：為什么可以討論？

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

對用戶或客戶有價值的

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

比如“所有數(shù)據(jù)庫連接要通過一個連接池”，這只是對開發(fā)人員有價值，并不是對用戶有價值，用戶只關(guān)心實現(xiàn)后的結(jié)果，比如“我可以修改個人信息”。

可估計的

一般有一下三個方面導(dǎo)致故事不可估計

• 開發(fā)人員缺少知識領(lǐng)域
• 開發(fā)人員缺少技術(shù)知識
• 故事太大

芝士不想講概念，直接說經(jīng)驗。

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

小的

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

可測試的

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

我們做一些修改：

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

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

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

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

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