敏捷需求管理篇｜如何從0-1寫好一個使用者故事

作者：Iris Xu，雲智慧 企業效能 部。

敏捷需求管理

傳統的需求是一個比較籠統的概念，即產品改進需要的集合。敏捷需求則通過對傳統需求的細化分層，管理不同顆粒度的需求。本文通過對敏捷需求管理概念解析，詳細解讀如何寫好使用者故事，以提高業務人員與開發人員對需求理解的一致性，面向業務價值進行交付。

敏捷需求的分層管理

如下圖所示，敏捷中需求通常被分為史詩、特性、使用者故事三大類別，逐層往下，粒度越來越小。需求直到被分解至使用者故事時，才能放入Scrum迭代。

• 史詩：由多個較小的故事組成的史詩。

• 特性：一組相關的故事，有價值的單方向功能集合。

• 使用者故事：獨立的較小使用者的價值交付單元。有可能不足以單獨釋出。

使用者故事與Bug缺陷、驗收標準以及任務進一步關聯。任務一般由研發團隊拆解，可分為前端、後端、測試任務。除此之外，企業技術團隊還會做一些技術優化或技術債務的償還，這類需求則可以被稱作技術故事。另一方面，當企業需要做管理實踐，如知識分享或員工技能的培訓時，這類需求也可以新增至迭代中。

需求四要素

正常情況下我們在描述一個需求時需根據4W法則，即 Who、When、What、Why。根據上述延伸出來了需求的四要素包含使用者、場景、任務、成果。

使用者故事的重要性

為什麼要寫使用者故事

使用者故事的好處在於可以讓業務人員和開發人員在理解同一件事時可以處在同一緯度。主要有以下三大優點：

1. 提高合作效率：業務人員和開發人員通過面對面的溝通，提高了溝通合作效率。

2. 保證理解一致性：業務人員和開發人員通過對需求面對面直接拆解、討論，更容易對需求理解達成一致，減少認知偏差。

3. 減少 風險 ： 使用者故事通過提高團隊合作效率，保證業務人員與開發人員對需求理解的一致性從而降低了由缺乏溝通導致的技術風險、成本風險等。

如下圖所示，不同的角色會站在自己的層次上，預設別人也應該知道，往往造成需求理解的偏差和遺漏。

使用者故事的價值

使用者故事的價值主要包含以下五方面：

1. 強調口頭溝通而非書面溝通

2. 使用者和開發人員都可以理解

3. 故事大小適合做 計劃

4. 適用於迭代開發

5. 鼓勵推遲細節

如何寫好使用者故事

使用者故事的概念

使用者故事是敏捷軟體開發中的一種輕量級的需求分析方法。（user story）是從使用者的角度來描述使用者渴望得到的功能，是一個對使用者或客戶有價值的功能點的簡單描述。有以下三方面組成：

1. 一份故事的書面描述，用於做計劃和提示

2. 有關故事的對話，有助於充實故事的細節

3. 傳遞和記錄故事細節的測試，用來判定故事是否完成

使用者故事的寫法

寫好一個使用者故事應遵循3C原則，即當把需求主題寫在卡片（Card）後，通過交流（Conversation）澄清需求的細節，並作為確認（Confirmation）資訊記錄下來。使用者故事完成後產品經理應從業務的角度定義故事的驗收標準，確保故事被正確、完整的實現。

1. 三段式

初學者可採用三段式來編寫使用者故事，即每一個Story只針對一個使用者角色來描述，關注使用者的業務目標，可迫使需求分析人員從使用者的角度進行思考，使用使用者的語言來描述需求。熟練掌握Story之後可以採用更簡潔的方式，如使用者可以做什麼操作，使用者希望系統提供什麼功能等。

2. 分析方法

具體可以分為以下步驟：

• 識別使用者角色：應儘可能定義“人”而不是“系統類”角色。 為能影響專案成敗的“使用者”定義角色；

• 分析業務流程 ：業務流程是指使用者跟被實現系統之間的互動流程，不包括系統內部各部件之間的互動流程；

• 提取Story：根據使用者可以感知的層次，從互動步驟中提取出一個個Story；

• 整理Story：Story太大，則需要進一步分割；Story太小，則可以跟其它Story進行合併。

使用者故事INVET原則

• 獨立性（Independent）：要儘可能的讓一個使用者故事獨立於其他的使用者故事。使用者故事之間的依賴使得制定計劃，確定優先順序，工作量估算都變得很困難。通常我們可以通過組合使用者故事和分解使用者故事來減少依賴性。

• 可協商性（Negotiable）： 一個使用者故事的內容要是可以協商的，使用者故事不是合同。一個使用者故事卡片上只是對使用者故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個使用者故事卡帶有了太多的細節，實際上限制了和使用者的溝通。

• 有價值（Valuable）： 每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

• 可估算性（Estimable）：開發團隊需要去估計一個使用者故事以便確定優先順序，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

• 短小（Small）： 一個好的故事在工作量上要儘量短小，最好不要超過10個理想人天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。使用者故事越大，在安排計劃，工作量估算等方面的風險就會越大。

• 可測試性（Testable）：一個使用者故事要是可以測試的，以便於確認它是可以完成的。如果一個使用者故事不能夠測試，那麼你就無法知道它什麼時候可以完成。一個不可測試的使用者故事例子：軟體應該是易於使用的。

如何寫出更好的使用者故事

• 從目標故事開始：思考每個使用者角色，確定與軟體進行互動的目標；

• 縱切蛋糕：每個故事都能提供一定的端到端功能；

• 編寫封閉的故事：隨著故事的實現完成，一個有意義的目標隨之完成；

• 約束卡片：那些必須遵守而不需要直接實現的故事卡；

• 根據實現時間來確定故事規模：寫出不同層級的故事；

• 不要過早涉及使用者介面；

• 需求不止故事：使用者故事並非適用於所有系統；

• 故事中包括使用者角色：通過想象真實的、具象的使用者，開發出滿足使用者需求的軟體；

• 為一個使用者編寫故事：增加使用者故事可讀性；

• 用主動語態；

• 客戶編寫；

• 不用給故事卡片編號；

• 不要忘記目的：故事卡的主要目的是提示人們討論該故事。

開源福利

雲智慧已開源資料視覺化編排平臺 FlyFish 。通過配置資料模型為使用者提供上百種視覺化圖形元件，零編碼即可實現符合自己業務需求的炫酷視覺化大屏。 同時，飛魚也提供了靈活的拓展能力，支援元件開發、自定義函式與全域性事件等配置， 面向複雜需求場景能夠保證高效開發與交付。

點選下方地址連結，歡迎大家給 FlyFish 點贊送 Star。參與元件開發，更有萬元現金等你來拿。

GitHub 地址： http://github.com/CloudWise-OpenSource/FlyFish

Gitee 地址： http://gitee.com/CloudWise/fly-fish

萬元現金活動： http://bbs.aiops.cloudwise.com/t/Activity

微信掃描識別下方二維碼，備註【飛魚】加入AIOps社群飛魚開發者交流群，與 FlyFish 專案 PMC 面對面交流～