本文從「用戶故事」的概念、準則、創建用戶故事地圖到建立用戶故事卡的方法無一不包，幫你完整掌握「用戶故事」這個知識點。

概念

1. 什麼是用戶故事？

• 迭代開發的一種工具；
• 代表了可開發的一個工作單元；
• 幫助我們跟蹤一個功能的生命周期。

2. 什麼是用戶故事地圖？

• 一個有風向的圖表；
• 橫軸為時間線，放置延時間線的用戶故事；
• 縱軸為優先級，自上而下；
• 覆蓋所有用戶故事，表達需求全景。

3. 為什麼使用用戶故事？

從設計賦能角度來講，用戶故事地圖可以幫助設計師從產品計劃層面，提升產品用戶體驗，避免沉入細節之中；找到一種落地產品思維的方法，即平衡用戶價值、產品價值、開發成本三者的關係；關注項目和產品，設計出落地、有效的產品方案，避免理想化。

從項目管理角度，用戶故事地圖可以解決以下問題：

• 只見樹木不見森林，重要內容埋沒在細節中，難以排列優先級；
• 無法看到版本貢獻功能的完整價值流；
• 無法方便的使用迭代方法跟蹤、優化內容，確定版本計劃和目標。

從團隊協作角度，用戶故事可以降低溝通與達成共識的成本，將關注力更多集中在產品上。

4. 用戶故事簡述

• 作為一個（角色）：誰要使用這個功能。
• 為想要（功能）：需要完成什麼樣的功能。
• 以便於（價值）：為什麼需要這個功能，帶來什麼樣的價值（用戶價值和組織價值）。

準則

構建用戶故事地圖需要：時間線、用戶活動、用戶任務、用戶故事、故事地圖結構。用於實現目標的用戶功能 > 活動 > 任務 > 史詩 > 故事。

• 將用戶要素從左向右拖動到地圖的頂行。地圖頂行中的每個功能都是呼叫用戶活動。
• 創建完成活動所需的許多步驟，稱為用戶任務。
• 這些用戶任務中的每一個都可以分解為多個史詩。
• 在史詩下，可以定義用戶故事列表，其大小適合放入 sprint。

1. 用戶故事的3C原則

3C 原則是由 Ron Jeffries 提出的，它包括三個部分：

• Card 卡片，用來簡要描述軟件特性或改進點；
• 描述的內容簡潔、詞彙含義統一，項目成員不會對同一內容有差異性理解；
• 這些卡片用於後續的溝通、對需求內容的組織和排列優先級。

Conversation 交談 ，與 Product Owner（或客戶）交談來明確細節。

• 卡片的內容是由團隊在溝通中獲得，而非由同一個人輸出或更新的，不然它與傳統的需求分析方法無異；
• 項目成員需要一起就卡片內容進行討論。在複雜邏輯中，梳理出清晰的需求脈絡，並在這一過程中，達到共識和理解的統一。

Confirmation 確認，每個故事應具有驗收標準（驗收條件），能夠確認被正確完成。

• 以始為終，先行確認以怎樣的結果，來判斷開發任務的完成；
• 它保證每個故事都是獨立的、完整的邏輯，可以單獨交付；
• 它為驅動測試驅動開發、行為驅動開發和持續集成提供可能。

2. 用戶故事原則

• I 獨立的（Idependent）：獨立且完整，不依賴於其他任何用戶故事；
• N 可談判的（Negotiable）：引導團隊跟干係人之間對話和談判的介質。在任何時候，用戶故事都可以被改寫甚至丟棄。一個用戶故事不會像石頭一樣固定不變，直到它將要在接下來的 Sprint 里被實現；
• V 有價值的（Valuable）：需要將價值給干係人，不論是最終用戶還是採購者；
• E 可估算的（Estimable）：團隊需要能夠粗略地估算出完成用戶故事所需工作量規模；
• S 小規模的（Small）：以一個大的「佔位符」開始其生命周期。隨着時間的推移，當人們對用戶故事所表達的願望的複雜度更加了解時，這個較大的「佔位符」就將被拆分成小的用戶故事。當最重要的那些用戶故事將進入 Sprint 被實現並交付時，它們需要變得足夠小，這樣才能在一個 Sprint 里被完成。
• T 可測試的（Testable)）：一個用戶故事必須提供必要的信息，清楚地界定了故事的驗收標準，這樣才能在它完成時判斷是否驗收。

創建用戶故事地圖

用戶故事地圖是一個用於需求收集的 4 級層次結構。故事地圖從不同來源（即積壓）收集的用戶特徵集合開始，這些用戶特徵將通過執行某些任務作為活動來實現。這些任務可以轉換為史詩后，轉換為軟件開發的用戶故事。

1. 產品定義

一般是在故事編寫工作坊準備階段，首先由 PD 主導產出，主要有幾點內容：

• 產品的目標用戶
• 解決了哪些問題
• 用戶目標
• 產品目標

2. 梳理骨幹故事

寫出不同顆粒度的故事，需要設計師把控故事的大小，這段故事可以再往下梳理一層顆粒度更小一點的故事。這樣骨幹故事就有兩層，一級故事和二級故事，故事的發生從左至右是一個敘事流。

3. 拆分故事

在剛剛梳理的每一個二級故事下面做停留，去拆分二級故事獲取更多細節內容。項目組會圍繞這個故事寫出很多細節來。按照以下幾個維度對細節進行歸類，分別是：故事細節、想法、痛點、機會、情緒。其中情緒可以通過固定的問題獲得，也可以通過用戶想法、用戶的痛點結合主觀判斷。

4. 溝通確認

這裏我們的故事已經變得很豐滿，甚至變得臃腫，所以溝通確認變得極為重要。我們在這步需要花費相對多的時間，大家對內容進行對標、充足討論，把公認的留下來，無用的剔除掉。同時可以區分要做的故事細節的優先級。

建立用戶故事卡

卡與迭代的關係：

• 卡是迭代開發的一個工具；
• 卡代表了一個可以的工作單位；
• 幫助我們跟蹤一個功能的生命周期。

管理卡片：

• 估計工時
• 分配工作
• 追蹤進度

如何使用？

• 書寫故事卡；
• 將卡放在牆內（物理牆/数字牆）；
• 領卡需要與 QA/BA 澄清需求（一人不能有兩張正在做的卡）；
• 故事卡完成后需要做 Desck Check（block里的卡片要儘快消滅）。

產品迭代

IPM：Iteration Plan Meeting，迭代計劃會議主要是跟客戶保持溝通與信息更新的會議。

• 下一個迭代的 Story；
• 對下一個迭代的期望；
• 團隊的人員可用性；
• 風險的評估總結。

敏捷宣言裏面有一條：客戶協作優於合同談判。在 Scrum 團隊中有一個角色叫做產品負責人，他的核心職責是確保業務需求的清晰和透明，保證開發團隊對業務有足夠的了解，並將這些待完成的業務需求（Story）按照優先級排列出來，按照任務卡的方式來驅動團隊的開發。

IPM 的主要產出是下一個迭代中完成的 Story，這些 Story 即為下一個 Story 要完成的目標，通過敏捷看板工具來管理它們。

Sprint：業務流，Sprint1，Sprint2，Sprint3-N，已交付的故事。業務流就是史詩故事，每個史詩故事一個泳道。Sprint1，Sprint2，Sprint3-N 裏面是不同史詩故事拆分出來的用戶故事，並且根據優先級放到了不同的 Sprint 裏面，橫向的泳道代表的是史詩故事和史詩故事拆分的子故事的對應關係。

burn down chart：燃盡圖，一個sprint 內，人/時是一個比較固定的值。在這個時間框架充分安排開發任務，每天進行時間結算，繪製時間燃盡圖。項目成員通過燃盡圖獲知時間進展，若項目燃盡所用時間與預期時間契合，則需求時間預估和安排合理，若不契合則需要在下一個 sprint 進行調整。

Retro（回顧）：即 retrospective 的簡寫，團隊針對目前狀態總結，目的為保持好的方面及加強，做的欠佳的方面一起討論改進措施，並儘力落實。在實踐中摸索出適合團隊的最佳實踐，引導團隊和個人不斷自我完善，追求卓越。

• 確認構建安全的環境；
• 建立幾項總結指標（well，less well，suggestion，action）前三項列出看法，第四項針對前三總結；
• 一個點寫在一張便利貼，分欄貼上牆；
• 將同一類的問題歸納起來，總結出相應的解決措施；
• Iteration 欄中的 sticker 指派並落實。

歡迎關注作者微信公眾號：「Design Thinker」

未经-摩登3注册-摩登3测速官网-允许不得转载：摩登3注册-摩登3测速官网 » 無極平台網站_如何梳理用戶需求？試試這個超好用的「用戶故事地圖」