敏捷管理中的史詩與故事

在敏捷軟件開發中，史詩＆故事都是經常使用的術語。對於管理敏捷軟件開發來講，Choerodon豬齒魚是一個很好的工具，爲敏捷術語和功能提供了很是普遍的實踐方法，例如：史詩，故事、任務、子任務和缺陷，這些都是Choerodon中的問題類型。

• 史詩：是一個功能集或是一個大的用戶故事，但由於顆粒度太大而沒法適應衝刺，它能夠分解爲許多較小的故事；
• 故事：是簡短的用戶需求，足夠小以適合衝刺；
• 任務：是完成用戶需求的過程性的工做，表示用戶故事開發任務的完成；
• 子任務：子任務一般是故事或任務的具體拆分，由單人承接，並且一般能在短期內完成；
• 缺陷：主要針對測試中的缺陷或者已發佈版本的缺陷；

本文將詳細爲你們介紹敏捷中史詩和故事以及它們在敏捷中的具體使用規範。

什麼是史詩？

史詩是一個大的故事，當一個功能具備多個場景時，該功能則須要在史詩層面進行多種實現。史詩表明的一般是與特定結果密切相關的原始想法，與該史詩相關聯的用戶故事則表明須要交付的解決方案的各個方面。總的來講，經過史詩能夠跟蹤待辦事項中比較大的用戶需求，史詩中包含多個小的產品功能的用戶故事，這讓用戶需求更加具備層次結構。

如何編寫史詩？

對於史詩的編寫，目前尚未標準格式，一些團隊會使用熟悉的用戶故事格式，也有一些團隊則用簡短的短語表示史詩。

在命名史詩時，請牢記如下兩點：

1.它是開發或需求的核心內容；
2.編寫時使用組織中的每一個人均可以理解的語音文字，以避免產生歧義；

由於史詩是編寫用戶故事時要參考的內容，而且在編寫用戶故事時還要參考全部團隊成員的意見，因此正確的編寫史詩並將詳細信息在史詩中體現很是重要，這有助於避免團隊中的許多衝突和對產品功能的誤解。

用史詩介紹開發的新功能時，須要包括開發此功能的緣由、須要解決的用戶需求以及新功能的度驗收量標準。此外，該功能的任何文檔或早期的思路，能夠向團隊簡單介紹，或者提供清晰的圖片和信息。注意：團隊對功能達成共識和目標是成功交付的關鍵。

Choerodon中的史詩示例：

• 史詩01：向用戶提供排序和優先級選項，以輕鬆管理需求

  • 用戶故事01：做爲發佈經理，我但願將發佈映射到不一樣的sprint，並看到每一個故事的優先級。
  • 用戶故事02：做爲系統管理員，我擁有優先處理產品需求的權限。
  • 用戶故事03：做爲用戶，我能夠標註需求的優先級，並實現簡單的拖放操做從新排序需求。

編寫史詩時須要注意的是：

1. 謹慎思考

在編寫史詩時，能夠先撰寫項目構想的草稿，並須要思考最有必要的內容以及在之後的開發中包含的內容。這些都須要仔細考慮。

1. 邏輯清晰

在編寫後續的史詩時，應該根據先前的主題來建立史詩，先後的史詩須要合乎邏輯且一致。

1. 結合測試

史詩不僅是從大的故事進行思考，它分解的每一個功能還須要在測試中可用。

1. 參考專家人士的意見

在編寫過程當中不該僅依靠我的或團隊成員的眼光和思路，還須要參考專家人士的意見，閱讀專業人士的的博客或他們推薦的書籍。他們的工做經驗和意見能使史詩更加客觀，也能讓團隊成員得到專業的經驗和技能。

史詩是項目計劃過程當中重要的組成部分，有了史詩，團隊成員和利益相關者能夠看到產品真正的目的和用戶需求。正確的史詩是進一步項目開發甚至產品研發的好幫手。

什麼是用戶故事？

用戶故事是基於史詩進行分解的，反映的是用戶需求和用戶能夠獲得的價值。它們從用戶的角度描述功能的各個部分。在敏捷開發過程當中，當咱們開始站在用戶的角度上思考時，即便這個功能不是當前解決方案的範疇，咱們仍須要創建用戶能夠操做的行爲場景。例如，咱們正在針對共享照片和視頻的特定問題制定解決方案，根據經驗咱們按照預期的方式執行全部操做，可是用戶第一次使用而且不瞭解產品，可能查找不到特定角色對應的照片。爲了不這種狀況，在用戶故事中從用戶角度清楚地說明所需的功能很是關鍵。

如何編寫用戶故事

在敏捷方法論中，團隊構建的全部內容都應圍繞用戶，這裏的團隊指的是產品經理、客戶、利益相關者還有產品的最終用戶。爲了深度瞭解用戶的需求和痛點，在開始編寫用戶故事以前，須要肯定好產品的角色。如下是編寫用戶故事時普遍使用的模板：

「 做爲一名 <角色或角色>，我能夠 <目標/須要> 這樣說 <爲何>」
或者，在另外一種狀況下：
「做爲 <特定的用戶類別>，我但願 <可以執行/執行某項操做>， 以便 <得到某種形式的價值或收益>」

上面的描述爲產品用戶制定了業務價值。除此以外，用戶故事的魅力在於，它不只制定了業務價值，並且還制定了開發和測試的要求。經過簡單的描述，添加產品功能的驗收標準等描述，以總結須要完成的全部任務。

如下Choerodon中某個項目的用戶故事的簡短形式：

做爲夜晚駕駛的駕駛員，我想迅速找到最近的優質加油站，以補充高品質的汽油。

• 驗收標準：

  • 做爲開燈的司機，我能夠看到全部即將到來的加油站。
  • 點擊「Ctrl+T」，我能夠選擇適合個人加油站品牌的加油站。
  • 到達加油站，我能夠看到即將到來的選定品牌的加油清單。
  • 點擊「M」鍵，我能夠看到最近在地圖上選擇的加油站。

用戶故事的重點是從用戶的角度清楚地說明所需的功能，須要正確的理解用戶需求並詳細的表達出來。編寫用戶故事時須要注意：

1. 用戶故事≠任務

用戶故事不是任務。在實際開發中，一個故事可能須要數百個任務才能成功交付，任務與執行有關，而用戶故事是根據用戶需求定義的。在編寫故事時，應着重於提供有關產品功能的信息。

1. 故事簡明扼要

故事必須簡單而準確。只需使用簡單準確的語言便可，有助於團隊成員和利益相關者深刻了解用戶需求，避免花時間澄清用戶故事中不清楚的地方，好比術語和首字母縮寫詞等。

1. 瞭解用戶

在開始編寫用戶故事以前，都須要收集一組關鍵用戶（理想狀況下是產品的角色用戶），瞭解他們的我的資料、觀點、對產品的指望以及相關的「痛點」，以幫助更好地瞭解用戶及其需求。

1. 大膽思考

當將產品描述爲用戶故事放到待辦事項中時，「沒有預算，時間週期不容許，可行性低或成本高等」會限制產品的思惟。正確的作法是大膽思考 ，將用戶故事維護到待辦事項列表，從產品的清晰度、用戶願景方面得到的價值。

用戶故事提供了一種快速而準確地描述軟件產品或系統功能的好方法，在產品規劃會、產品迭代會中具備主導和輸出做用。在這些會議過程當中，用戶故事須要以緊湊、結構化的方式闡明思想的提要。

故事地圖

根據敏捷的定義，在Choerodon中咱們使用故事地圖的形式來體現史詩和用戶故事的價值。

故事地圖的優點：

1. 將史詩用做業務價值的容器；
2. 根據產品版本獲得橫向流程；
3. 快速制定出產品的藍圖，獲得mvp版本的製做週期；（關於MVP的介紹能夠參考《MVP：平衡「可行性」和「最小化」》）；
4. 以故事爲中心，使開發人員的精力所有集中到重點功能上；
5. 使用增量來按期檢查並調整項目進度；

總結

敏捷開發關注於快速且持續地交付給用戶高價值、高質量、可用的產品功能。經過史詩和用戶故事梳理用戶需求、識別用戶角色、梳理用戶故事逐步完善更多細節，使執行的故事足夠短小、簡單，能在單個迭代期內完成，達到快速交付的目的。

本篇文章出自 Choerodon豬齒魚社區付新圓&柴曉燕。