在敏捷項目管理中,用戶故事是怎樣寫的?

5 評論 45744 瀏覽 91 收藏 6 分鐘

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

什么是用戶故事?

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

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

用戶故事描述公式如下:

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

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

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

故事描述

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

驗收測試

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

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

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

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

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

常見問題點

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

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

獨立的

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

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

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

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

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

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

可討論的

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

問:為什么可以討論?

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

對用戶或客戶有價值的

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

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

可估計的

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

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

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

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

小的

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

可測試的

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

我們做一些修改:

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

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

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

 

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

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 不太懂可測試和不可測試

    來自廣東 回復
  2. Thanks?(?ω?)?

    來自廣東 回復
  3. 對啊,感覺收尾說收就收了,如果有改進的方案,通過用戶故事來展開說明一下,會對用戶故事的編寫有更清晰的理解

    來自上海 回復
  4. 寫的比較有條理,對新人還是很有幫助的,相信很多人做產品都不知道有這樣的方法論。美中不足的就是收尾太倉促了,其實還可以稍微深入一點。加油!期待更多好作品。

    來自廣東 回復
    1. 收尾涉及整個項目的用戶故事迭代了,又是一大篇。。。

      來自四川 回復