作者簡介:

沃因:PMI敏捷實踐指南翻譯評論，scrum大師；PMI-ACP、Scrum Master、DevOps Professional、NPDP等課程講師；持有高端商業(yè)認證和敏捷證書，如CBAP、PMI-PBA、德沃普斯碩士和CSP。

房地

用戶故事是描述需求的一種方式，在各種敏捷方法中都很常見。

它徹底改變了需求的編寫方式。過去，需求的編制大多來自于需求方通過各種手段(包括但不限于用戶訪談、問卷調(diào)查、數(shù)據(jù)分析等)獲取需求后準備的不同形式的文檔。).

需求文檔是需求者已經(jīng)分析整理過的需求，具有一定的時效性和局限性。隨著市場環(huán)境的變化，需求文檔能否滿足用戶的需求就被打上了問號。

用戶故事從用戶的角度描述了用戶的“最終目標”，但沒有描述“如何實現(xiàn)目標”，這就為R&D團隊預留了一些緩沖，讓R&D團隊在開發(fā)過程中可以根據(jù)現(xiàn)狀分析現(xiàn)狀，滿足用戶的“最終目標”。

在這個過程中，可以充分發(fā)揮團隊的智慧，讓團隊分析“用戶的最終目標”，給出不同的方式，用集體的智慧去完成需求。

什么是用戶故事

用戶故事是對用戶有價值的功能的描述。通常，用戶故事的格式如下:

作為:，我需要:，這樣:

在上面的格式中，有三個因素:誰，什么，為什么。

Who 描述了最終使用該功能并獲得價值的角色，它幫助我們明確了功能使用人的邊界，從而將當前用戶故事集中在一個固定的范圍內(nèi)容；What 描述了需要達到的效果。注意此時是效果，而不是解決方案。換言之，關注點是你最終的目的，而不是解決方案（途徑）。最簡單的區(qū)別就是 “快速找到你需要的商品”是目的，而“使用搜索”是解決方案；Why 描述了What的合理性，著眼點是價值，即What 背后的商業(yè)邏輯?；蛘邠Q一個更加粗暴的說法，就是“給Who 所帶來的收益”。

用戶故事還有一個叫3C的原則，具體來說就是:

卡片，其中包含故事的文字描述

對話，包括需求細節(jié)

確認后，記錄上述內(nèi)容

從以上對用戶故事的描述來看，目前我們至少知道用戶故事至少具有以下特征:

有價值，對用戶故事中Who 來說，這個用戶故事必須有價值，用戶將會因此有所收益。用戶故事所帶來的價值，用戶必須可感知——這點極度重要，這近似將所有的技術細節(jié)從用戶故事中剔除，讓我們可以更關注需求本身。

史詩般的用戶故事是什么

Epic在一些書籍或論壇中被視為用戶故事類型。

但是我不同意用戶故事里有特定類型的Epic。

Epic不是一個類型，只是一個標簽。

用戶故事就是用戶故事，但是有些用戶故事比較大。如果這個用戶故事完成了，它會給用戶一些容量，所以我們認為這個用戶故事的標簽是史詩，僅此而已。

而且這種認知直接讓我對用戶故事的一個INVEST原則有了一些其他的看法(我們下次再說)。

用戶故事的細節(jié)在哪里

如果用戶故事寫在廣告牌上，內(nèi)容有限，討論后肯定寫不出各種細節(jié)(微雕師說我不服)，那么細節(jié)應該在哪里？

我的答案是:它需要存在于其他系統(tǒng)中。一般我們會存儲在吉拉或者Trello，存儲的內(nèi)容一般是討論的最終結果(團隊和PO共同約定)。

最終結果由兩部分組成:

討論的細節(jié)，包括該用戶故事涉及的流程、順序、以及界面（UI）與交互（UX）等結果；驗收標準?？隙〞腥烁嬖V你，我們將驗收測試寫在用戶故事卡片背后，但實際上由于用戶故事的粒度問題，是不能保證100%都能寫下的。而且有些驗收標準也比較復雜，用戶驗收測試包含內(nèi)容太多，這都不適合寫在卡片背后。

什么是驗收測試

驗收測試是用來驗證實現(xiàn)的用戶故事是否滿足客戶需求的測試用例。

在迭代開始的時候，當開發(fā)人員開始編碼的時候，客戶或者PO就準備接受產(chǎn)品了。幫助他們完成這個過程的工具是驗收測試。

驗收測試應盡快完成。這樣做最大的好處是開發(fā)團隊和客戶可以盡早對功能開發(fā)做出相同的認知，避免開發(fā)人員對客戶需求的誤解，導致開發(fā)偏差，浪費工作量。

以下是為用戶登錄編寫的驗收測試:

用戶可以使用正確的用戶名、密碼登錄用戶可使用手機驗證碼進行登錄登錄失敗時，給用戶錯誤提示

在這個過程中，如果你仔細一點，你可能會發(fā)現(xiàn)在驗收測試中，我并沒有描述“用戶名和密碼錯誤”、“驗證碼輸入錯誤”、“微信掃碼后沒有授權”等場景。為什么？

在實際的驗證過程中，驗證的實施者是客戶或PO，他們更關心的是“正確的路徑”，即所謂的快樂路徑，而他們無法窮盡其他錯誤信息，所以工作在一定程度上由R&D團隊進行補充，使客戶和PO能夠?qū)Ｗ⒂谟袃r值的部分(非快樂路徑一般不產(chǎn)生價值)。

寫在最后

用戶故事是敏捷開發(fā)中常見的形式，如何使用好它將直接影響敏捷實施的成功。所以在接下來的文章中，我們會從INVEST、用戶角色建模、故事接受、故事收集、故事拆分等方面詳細講解與用戶故事相關的內(nèi)容，敬請期待。