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

概要

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

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

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

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

英文：

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

中文：

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

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

作為一個“火箭訂票網(wǎng)站”

我想要“統(tǒng)計每天有多少外星人訪問了我的網(wǎng)站”

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

在這寥寥三句話，它和傳統(tǒng)需求描述有什么區(qū)別呢？

一、敏捷故事和傳統(tǒng)需求之間的區(qū)別

出發(fā)點：客戶vs需求

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

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

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

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

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

側(cè)重點：問題vs方案

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

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

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

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

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

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

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

傳統(tǒng)方式當(dāng)然也有溝通，但是需要什么菜基本上是一次性遞給開發(fā)人員。

關(guān)于用戶故事，Ron Jeffries用3個C來描述它：

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

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

作為一個“火箭訂票網(wǎng)站”，

我想要“統(tǒng)計每天有多少外星人訪問了我的網(wǎng)站”，

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

AC：

統(tǒng)計數(shù)據(jù)包括：

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

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

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

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

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

（圖片來源：Gartner）

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

設(shè)計思維主要有5個階段：

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

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

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

有了設(shè)計思維，用戶故事的產(chǎn)生是有故事地圖Story mapping開始的，這個開發(fā)框架主要由三大類：

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

第一步：故事地圖Story mapping

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

第二步：用戶故事優(yōu)先級

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

用戶需求的優(yōu)先級會被討論出來，并結(jié)合團隊開發(fā)能力，確定每個發(fā)布的主要內(nèi)容；

(圖片來源：一條翅膀)

后續(xù)：優(yōu)化backlog中的故事

這些故事放在backlog中，你會發(fā)現(xiàn)，優(yōu)先級高的故事，在開發(fā)前都已經(jīng)經(jīng)過了PO和開發(fā)人員的充分溝通，非常準(zhǔn)確了。而優(yōu)先級低的故事，可以是因為不緊急不重要，也可以是因為變化多端的外部環(huán)境導(dǎo)致不能很快確定需求，不需要在一開始就準(zhǔn)備好。

四、BDD: 故事編好了，測試還會遠(yuǎn)么

故事必須是可測試的。成功通過測試可以證明開發(fā)人員正確地實現(xiàn)了故事。

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

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

1. Given
2. When
3. Then

例子：

Given用戶在根據(jù)星球搜索頁面

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

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

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

一條翅膀的其他敏捷相關(guān)文章：

老板提議我同時擔(dān)任Scrum Master和產(chǎn)品負(fù)責(zé)人，有錯嗎？

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

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

本文由@一條翅膀 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議