上兩篇我們說到Agile框架中的角色(Role)和會議（Ceremonies），這篇我們深度聊一聊敏捷產物（Artefacts）的核心: 用戶故事User Story！

概要

• 敏捷故事和需求和傳統需求之間有什么區別？
• Design thinking: 什么時候可以開始講故事？
• Theme, Epic, Story: 大故事，小故事，還有一些小小故事
• BDD: 故事編好了，測試還會遠么？

用戶故事一般由三句話組成，描述了一個用戶渴望得到的功能。一個好的用戶故事包括三個要素：

1. ?角色：誰要使用這個功能。
2. 活動：需要完成什么樣的功能。
3. 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。

用戶故事通常按照如下的格式來表達：

英文：

As a <Role>,
I want to <Activity>,
so that <Business Value>.

中文：

作為一個<角色>,
我想要<活動>,
以便于<商業價值>

我們以一個可供外星人和地球人訂火箭訂票網站舉例：

作為一個“火箭訂票網站”

我想要“統計每天有多少外星人訪問了我的網站”

以便于“我的贊助商了解我的網站會給他們帶來什么收益?！?/p>

在這寥寥三句話，它和傳統需求描述有什么區別呢？

一、敏捷故事和傳統需求之間的區別

出發點：客戶vs需求

有價值（Valuable），是故事的核心要求。

每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們，而且需要讓客戶意識到這是一個用戶故事并不是一個契約而且可以進行協商。

用戶故事的每個故事，都會非常清晰的寫明為什么目標客戶做，幫助開發人員更好的站在客戶的角度看問題。

傳統需求會直接寫明需要什么，對于開發人員來說，更像是知其然，未必知其所以然。

比如：以上火箭訂票網站的故事，開發人員會清晰了解到是贊助商的需求，價值清晰可見，而非只是告訴客戶一個簡單的訪問數字，假想哪些客戶可以用到。

側重點：問題vs方案

可協商性（Negotiable），是用戶故事的另一個特質。用戶故事不是合同，而是可以協商討論。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不會有太多的細節。為什么這么做呢？

用戶故事側重提出問題，但不一定要在一開始設置的時候提出解決方案。

比如說我們一開始看到統計多少外星人訪問網站，目的是為了給贊助商提供信息，那么開發人員在數據分析過程中，很可能會發現，外星人星球的分布情況也可以輕松提供，為贊助商提供更準確信息?；蛘哒哂匈澲滔Ｍ揽蛻裟挲g，那么在統計數據前期，是不是可以調用其他地方的數據。等等。

所以，一個用戶故事卡不會帶有了太多的細節，來限制和用戶的溝通。也就是說，用戶故事的解決方案是需求方和開發人員不斷溝通思維碰撞逐步產生的。

這與傳統的方法往往由BA作為中間人來消化需求，喂給開發人員，有所不同。

溝通方式：逐步溝通 vs 一次到位

用戶故事不是不會一步到位，會有一個雛形，然后慢慢形成方案和Acceptance Criteria。

傳統方式當然也有溝通，但是需要什么菜基本上是一次性遞給開發人員。

關于用戶故事，Ron Jeffries用3個C來描述它：

1. 卡片（Card） ：用戶故事一般寫在小的記事卡片上?？ㄆ峡赡軙懮瞎适碌暮喍堂枋?，工作量估算等。
2. 交談（Conversation）：用戶故事背后的細節來源于和客戶或者產品負責人的交流溝通。
3. 確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。

經過交流一個好的故事加上AC很可能是這樣的：

作為一個“火箭訂票網站”，

我想要“統計每天有多少外星人訪問了我的網站”，

以便于“我的贊助商了解我的網站會給他們帶來什么收益?！?/p>

AC：

統計數據包括：

• 每日、每周、每月流量。
• 贊助商鏈接轉化率。
• 購買贊助商產品的用戶年齡、性別、星球所在地分布。

二、Design thinking: 什么時候可以開始講故事

在敏捷的實踐的時候，很多需求方都有一個困擾——拋棄了傳統需求檔案，我們還是需要做前期調研，那么我們什么時候可以開始寫故事？

有一個非常有意思的方式——結合敏捷和設計思維。著名咨詢公司Gartner把這個結合分成三個階段：

1. Design Thinking 設計思維：分析客戶的問題， 由具象到抽象
2. Lean StartUP 精益創業：提供客戶問題解決方案，嘗試開發模型
3. Agile 敏捷：迭代

（圖片來源：Gartner）

敏捷是一種優化解決問題的方法，而設計思維是一種發現問題并找出解決方案的方法。它需要對最終用戶的高度同情和理解，以及開發新想法，挑戰假設和重新定義問題的迭代過程，目標是確定可能不一定明顯的替代解決方案。

設計思維主要有5個階段：

• 移情：了解人，他們的行為和動機。由于人們通常不明確地知道或無法清楚地表達這些事物，因此通過在上下文中查看用戶及其行為來識別模式，提出問題和挑戰假設，從而產生理解。
• 定義：根據組織，目標和最終用戶的觀點，創建可操作的問題陳述，以定義要解決的正確挑戰，以及滿足需求的一組需求。
• 構思：利用諸如頭腦風暴，思維導圖，素描或創建紙質原型等技術來退后一步，進行廣泛應對，并提出最初未設想的更具創新性或影響力的解決方案。
• 原型：通過展示而不是說出來將想法變為現實;快速創建工作原型，將某些東西放入用戶手中，并開始收集真實世界的反饋。
• 測試：從用戶體驗中學習，迭代并根據需要重復該過程，直到達到最小可行產品（MVP）。

在這個過程中，我們會慢慢形成解決問題的框架，繼而幫助開發階段拆分故事。

三、Theme, Epic, Story: 大故事，小故事，還有一些小小故事

有了設計思維，用戶故事的產生是有故事地圖Story mapping開始的，這個開發框架主要由三大類：

1. Themes：大故事.
2. Epics：可以細分到用戶故事故事
3. Stories：用戶故事

第一步：故事地圖Story mapping

往往是團隊和開發人員召集在一起的一個workshop. Epics可以按照client journey中每個階段分類，然后團隊一起在有哪些用戶故事。

第二步：用戶故事優先級

那么，如何確定每個階段開發什么呢？

用戶需求的優先級會被討論出來，并結合團隊開發能力，確定每個發布的主要內容；

(圖片來源：一條翅膀)

后續：優化backlog中的故事

這些故事放在backlog中，你會發現，優先級高的故事，在開發前都已經經過了PO和開發人員的充分溝通，非常準確了。而優先級低的故事，可以是因為不緊急不重要，也可以是因為變化多端的外部環境導致不能很快確定需求，不需要在一開始就準備好。

四、BDD: 故事編好了，測試還會遠么

故事必須是可測試的。成功通過測試可以證明開發人員正確地實現了故事。

因為如果一個用戶故事不能夠測試，你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：用戶覺得軟件很好用……

測試方法千千萬，BDD已經成為了一個非常經典的測試方法。和用戶故事的三句話相似，BDD也是三句話構成：

1. Given
2. When
3. Then

例子：

Given用戶在根據星球搜索頁面

When用戶在出發星球填寫飛地球之外的其他星球時，

Then返回星球自動填寫為地球。

BDD具體怎么操作我們分一篇再聊。但是，用戶故事只有理解以上這些來龍去脈前因后果，執行起來才有意義。

一條翅膀的其他敏捷相關文章：

老板提議我同時擔任Scrum Master和產品負責人，有錯嗎？

自從用了敏捷，天天在開會？ 4大Scrum會議如何才能有意義？

從老板到項目成員，如何從燃盡圖中洞悉團隊工作？

本文由@一條翅膀 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議