如何對一個產品編寫完整的用戶故事？

01-15

主要是如何設定一棵用戶樹的大小，例如：針對是購物搜索網站，「搜索」是否應該單獨作為一個故事來描述。

敏捷 1.0 Scrum+XP 中常用的用戶故事（User Story）通常是寫在一張故事卡片上的：

（網源圖片）

設想要把一個完整的用戶故事寫下來，尤其那些描述複雜產品需求的用戶故事，一張卡片怎麼夠？可能卡片背面也不夠。

那那麼多需求細節寫不下怎麼辦？可能很多敏捷 1.0 的粉不知道，用戶故事的正宗、經典用法是：

口述需求！

正因為在 XP 的起源項目 C3（克萊斯勒薪資項目）中有 Onsite Customer（另一個關鍵的 XP 實踐），產品經理天天就在開發現場，所以 PM 可以隨時隨地地向開發口述、闡釋需求的各種細節，而故事卡片只是起到了一個 placeholder 或 reminder（提示器）的作用，需求有什麼不懂、不清楚的地方讓開發拿著這張卡片去問 PM 就是了。大家一邊討論需求，一邊寫測試、寫代碼，甚至，PM 還能親自動手幫你寫產品測試、做測試，保證產品符合用戶需求，這真的是一個很理想的場景啊。

所以，XP 項目有用戶故事卡片加測試就夠了，不需要詳細的 PRD 和需求模型。

用例故事

你非要把一個完整的用戶故事，不用口述而用文字編寫下來么？

那麼我告訴你一個 Agile 2 的最佳實踐（之一）：

1）為這張用戶故事卡片取一個合適的名稱（通常是動詞片語）；

2）把這個用戶故事名稱所對應的用例故事|使用故事（use case，or use story）寫下來，這就是你想要的完整的用戶故事。

針對是購物搜索網站，「搜索」是否應該單獨作為一個故事來描述。

Search anything 作為一個單獨的用戶故事，可能過大了是一個 theme 或 epic story（實現估計超過 2 周），可以分解為粒度更合適的用戶故事，例如 Search goods, Search sellers 等等。如果還是太大，繼續分解。

若是從敏捷開發的角度來看，用戶故事本身一定不會完整。

它的作用應該是引起交互設計師，產品經理，客戶，還有開發團隊進行談論的一個點。

完整故事，會通過故事的澄清不斷完善，敏捷所倡導的不是這樣么。

有次跨部門分享中，有位同事說到幾點，覺著還不錯，當時也記下來了，貼出來

1、用戶故事；

為什麼要有一條用戶故事？一定是說明問題，提出解決方案，明確解決效果。

要用簡潔的語言，說對有用有價值的需求，是外在的行為。

2、用戶故事的模版；

角色定義（我是誰）+期待（我要什麼？）+原有/目的（我為什麼會這樣）

3、開發工程師的疑問

咬文嚼字，對故事一定要在語言上進行提煉

要對開發工程師宣導用戶故事中創造的價值

4、檢驗用戶故事的標準（教材中也有提到的五點）

獨立的

可協商的

有價值的

小的，可在一輪迭代中完成的

可測試的

5、關於用戶故事的幾句有用的話

可測試的用戶故事，是否明確了有極限值和邊際成本

驗收條件中是否包含了新的用戶故事

描述是否從用戶的角度中進行

1. 用戶故事是一種通用于敏捷開發中的需求方法。顧名思義，每一條用戶故事都需要有明確的用戶角色和與這個角色有關的故事。

2. 對於購物搜索網站，「搜索」是一個比較大的範疇，首先你需要識別的網站的目標客戶群體有哪些，然後用戶畫像，定義你的用戶。

3. 「搜索」更應該是你網站的主要功能，這個功能可能可以拆分出「列表搜索」、「一鍵搜索」等若干更具體的搜索功能點。

4. 針對更具體的功能點，結合你的用戶角色，可以考慮用用戶故事的方法來描述你的需求。

5. 對於用戶故事的使用，需要符合INVEST原則。

6. 更多關於用戶故事的內容，請參看我的知乎專欄《精益敏捷與項目管理踐行路》，謝謝。

故事點這個概念大家應該很了解了，實際上就是對在sprint裡面要開發的user story進行一個粗量級的估算，以便於團隊能夠知道這個user story的複雜度（工作量），但是這裡有個容易引起混淆的地方，就是傳統意義上的敏捷，是用來度量規模和複雜度。

使用『規模』和『複雜度』這兩個詞，是要表達『用完成任務所需時間來表示難度』。

從上面可以看出，由於故事點是對於規模和複雜度的估算，所以，第一它是一個不精確的值，第二，它應該是一個相對的值。由此來看，故事點是一個粗略的相對估算而不是精確估算。

1故事點的估算目的是什麼呢？

作為PO來講，他在梳理ＰＢＩ和ＳＢ的時候，可能是想知道團隊多久能交付產品，每個迭代能夠交付多少用戶故事，所以故事點可以解決ＰＯ的這個困惑。我們可以通過估算故事點，然後統計多個迭代團隊交付的故事點數，以此相對的得到一個團隊的交付能力，比如說每個迭代交付２０個點的用戶故事，那麼如果PO有一個由100點用戶故事組成的產品，那麼可以得知5個迭代完成這個任務。

也可以得到團隊的交付速率和交付能力的歷史數據，用來進行團隊回顧的數據依據。

在估算的過程中，因為所有團隊成員都要參與，大家對於故事的理解不一樣會造成估算的不同，這樣就需要PO和團隊成員之間進行需求的澄清，也是一個分析用戶故事需求和澄清的過程，能夠讓大家更好的理解用戶故事。

2故事點的估算的到底是工作量還是複雜度？

在實際開發環境中，大家往往會有一個理解上的難點，到底故事點估計的是工作量還是複雜度呢？

從PO角度來講，肯定需要得到的是工作量，這樣也能第一時間知道產品開發的進度還有風險，但是如果估計的是工作量的話，和實際開發的人是有關係的，因為同樣一個特性，對於熟練工和新手的工作量是完全不同的。

如果只是作為複雜度來估計的話，那麼產生的問題是：產品開發的複雜度在不同團隊和不同人員之間也是不一樣的，而且在現實開發環境中，對於複雜度的操作很難進行，有的時候大家會覺得費時費力。

從我個人來講，在敏捷不斷演進的過程中，現在故事點實際上是一個綜合的對於用戶故事的複雜度，規模，甚至還要加上承諾時間的一個度量了。

也就是說團隊可以不必過度糾結在用戶故事的度量上，而是重點放在當前迭代里能否按照該用戶故事的接收條件和團隊定義的ＤｏＤ來完成這個用戶故事，如果不能完成，給出理由，由ＰＯ來決定是否拆分或者重新設計用戶故事。

這樣帶來的一個問題可能是ＰＯ在梳理ＰＢＩ的時候無法得知整個產品的全部完成時間，因為團隊的歷史交付數據可能不是一個穩定的速率（每個ｓｐｒｉｎｔ交付的點數差別會比較大，因為更注重用戶故事本身和交付承諾）

3怎樣在計劃會議中更好地運用故事點估計？

如果是一個新的團隊，那麼建議針對用戶故事進行估點，這樣能夠使得團隊儘快熟悉起來，澄清需求，建立很好的溝通機制。
如果是一個很成熟的團隊，對於產品比較熟悉，那麼這個時候故事點估計就不是十分必要了，因為大家都很熟悉產品特性，所以對於所需的工作量也是相對準確的，這個時候可能就需要團隊給出工作量的估計，讓ＰＯ對於產品的開發更好地進行進度和風險控制。
如果可能的話，針對不同的用戶故事類型設計不同的基準故事點，比如說開發的故事基準和測試的故事基準，實際上的工作量和複雜度是完全不一樣的。

我回答個跑題的答案。

我覺得怎麼編寫用戶故事還是人員配合的問題，就是怎麼把需求澄清、如何進行產品設計。

1.用戶故事卡片可以作為討論議題，把誰、幹什麼、為什麼寫上就好，討論清楚後產品經理把討論結果加以補充記錄，以備後續查看。

2.用例也可以作為討論議題，區別在於其中增加了很多產品設計細節，一方面幫助技術同事理解需求，另一方面也限制了技術人員需求實現方案的設計，這就要看（1）技術人員與產品人員分工，產品人員只負責收集用戶需求還是同時也需要完成一定的產品設計（2）技術人員的能力和對業務邏輯的理解程度。

搜索不是一個故事，但是很多人會在用搜索的時候發生很多故事，把他們捕捉，抽象，放大，你的故事就有了。

N年前雅虎搜索不是請三位國師拍過三段廣告嗎？翻出來瞧瞧吧，自行搜索：雅虎搜索廣告大片

我覺得一個產品在做交互設計的時候，會有設定的角色、場景和目標，可以在此基礎上進行加工潤色以形成一個靠譜的用戶故事。完整的用戶故事我覺得會是用戶使用過產品之後的UGC，但這樣優質的UGC需要採取一定的激勵手段讓用戶願意花時間講出來，而不是使用過後的寥寥數語。再不濟將產品團隊孵出這個產品的辛酸史和背景添油加醋的講一講。。