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

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

今天芝士將以聚美優(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)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 不太懂可測試和不可測試

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

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

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

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

      來自四川 回復(fù)