從用戶故事地圖到Scrum敏捷研發管理

作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有雲PaaS平臺架構設計經驗，長期從事一線項目實踐

今天談下用戶故事地圖和敏捷項目管理方面的內容，由於最近1年我們基於DevOps成熟度模型對我們的研發過程管理進行持續改進，裡面也包括了敏捷研發管理方面的內容，同時也包括了敏捷研發管理和DevOps的集成。

用戶故事和用戶故事地圖

由於最近開始看devops成熟度模型的敏捷開發管理過程域，實際上核心仍然是scrum敏捷管理的內容，因此需要對這方面的內容做下重新回顧。特別是看到的用戶故事地圖，而實際原來在我們實踐scrum敏捷方法論的時候並沒有太用到。

原來我們談的就是用戶故事，product backlog和sprint backlog，先形成產品backlog，同時評估優先級和功能點複雜度，然後將不同的用戶故事分配到具體的sprint backlog裡面形成當前的迭代版本。將用戶故事進一步細化為不同的工作任務項，將工作任務下達到具體的人員執行。在整個過程中基於backlog列表形成從需求到開發到測試的完整端到端跟蹤和驗證。

用戶故事本身就是業務需求的實現，圍繞用戶故事的管理實現完整的業務價值交付。

對於用戶故事地圖建議大家可以參考下網上的這兩篇文章

• https://www.jianshu.com/p/5def007ae399
• http://www.woshipm.com/pd/270289.html

當我們看到這些用戶故事地圖的時候，我們發現這種地圖方式很好的解決原來backlog清單的單維度問題，形成了一種二維的可視化視圖結構。將具體的用戶故事內容很好的呈現在一個二維坐標體系裡面，其中一個坐標是業務活動和任務，一個坐標是具體的迭代版本。

同時我們對用戶故事本身也形成了完整的層次結構，即：

業務活動-》業務任務-》用戶故事點

對於用戶故事點，我們可以看到也叫最小化用戶故事，而這個在我們多年前實施scrum敏捷方法論的時候並沒有這樣去管理，往往用戶故事點還是偏粗，而是在任務安排上對用戶故事點進行了細化。而在新的模式下可以看到用戶故事點更加細化，是一個最小的功能實現點。

最小化用戶故事點也可能不能獨立交付，但是這不影響我們細化到最小化用戶故事點進行管理。這種最小化用戶故事點真正解決了我們原來遇到的兩個問題，即對於同一個用戶故事，用戶故事本身不能再進行細分的，但是用戶故事本身又包括了很多擴展邊界，或者說用戶故事本身包含了擴展業務規則邏輯，而這些在新用戶故事視圖模式下都可以進行可視化呈現，並分配到不同的迭代版本進行管理。

比如對一個簡單的發送郵件用戶故事，我們就會存在很多的小用戶故事點，比如支持發送附件，支持發送圖片都是擴展故事點，而對於發生時候需要校驗郵箱有效性可能就是擴展的業務規則點。這些我們都需要進行管理並跟進優先級安排到不同的迭代版本去實現。

對於用戶故事的形成，在上面一篇文章連結裡面有專門講到構建用戶故事地圖的8個步驟。在用戶故事地圖裡面有一個關鍵行，即一級用戶故事，它們組成了用戶故事地圖上的行走的骨骼（the walking skeleton）部分。而對於一級用戶故事，我們也可以看到，正是我們原來在sprint backlog裡面管理到的用戶故事粒度。

而在一級用戶故事上面，還有一層即user activities用戶業務活動層，而這層實際上也相當關鍵，通過這層我們可以將我們的用戶故事真正和實際的業務場景，業務流程和活動關聯起來。通過這種圖也可以很清晰的看到我們實現的用戶故事究竟體現在哪個業務流程或業務場景中。

而對於這兩層的構建，實際上也是存在兩種方法可以考慮。

1. 自頂向下：從業務場景和流程分解入手，先梳理清楚業務活動，再細分一級用戶故事。
2. 自底向上：先頭腦風暴形成一級用戶故事，然後再向上抽象歸類形成業務活動層。

就這兩種方法來說，自頂向下分析可以確保更加完整無缺漏，而自底向上方法往往則更加快速和敏捷。具體採用哪種方法進行需要根據項目團隊實際情況來綜合考慮。

在形成了業務活動和一級用戶故事後，剩下就是對一級用戶故事進一步拆分為最小化用戶故事，最小化用戶故事是否作為任務直接下達需要看我們研發項目任務管理的粗細度情況，在這裡並沒有明確的標準和要求。如果跟蹤管理的細，持續集成過程也高效快速，那麼就可以到最小化用戶故事，否則就到一級用戶故事。

實際上在一級用戶故事的拆分上，還可以借鑑我們原來用例建模的經驗，將最小化用戶故事分為三類故事場景，即核心用戶故事，擴展故事點，業務規則邏輯故事點並分別進行管理。其中對於核心用戶故事點優先級最高，必須在第一個迭代周期實現，擴展故事和規則故事點也必須要依託核心故事點而存在。

而對於我們的backlog項目，我們實際建議還是管理到最小化的用戶故事點，同時將用戶故事點作為任務項來管理和跟蹤，同時也基於最小化用戶故事點來編寫相應的測試用例點，只有這種方法我們整個跟蹤才能夠達到根據細粒度和敏捷，同時也確保關鍵擴展點和規則不遺漏。

在這種方式下唯一需要注意的就是最小化用戶故事點要確認是否一定是可以獨立交付的最小單位，這個問題我也還在進一步思考中，因為基於不同的業務需求和場景，往往需要多個最小化用戶故事點打包交付往往才真正能夠體現用戶價值。但是最小化用戶故事點本身又是可以獨立進行開發和測試的單位。所以在這裡需要我們在進行迭代版本規劃的時候考慮到故事點的關聯依賴性特徵。

從業務活動到用戶故事的簡單舉例

對於用戶故事一定會涉及到用戶故事地圖的構建，要看到當前用戶故事地圖的構建上可以明確的體現出迭代版本規劃，業務活動和用戶任務等幾個關鍵內容。而實際上迭代裡面的用戶故事已經是拆分到最小粒度的用戶故事點，或者叫用戶可以理解的業務功能點。這個業務功能點可以是我們在需求分析裡面常說的基本流，也可以是擴展流或某條業務規則。

業務流程-》業務活動-》用戶任務-》用戶功能點

以上即構成了整個用戶故事地圖的層級，也更加容易從用戶故事點追溯回具體的業務流程和業務場景。我們可以舉例來詳細看下整個過程：

第一級：業務流程到業務活動

對於出差我們當前是需要首先提交出差申請單，出差申請審批通過後才能夠預定機票和進行報銷。因此對於出差報銷流程可以分為三個業務活動。

• 業務活動1：出差申請流程
• 業務活動2：訂票流程，包括機票，酒店等預定
• 業務活動3：出差報銷流程

從業務流程到業務活動，到用戶任務，故事點的分解

第二級：業務活動到用戶任務

我們這裡拿出差報銷流程舉例說明，業務活動我們可以分解為填單，審批，付款三個關鍵業務活動。在三個業務活動中就有具體的用戶任務，用戶任務即已經到具體的業務功能點。

1. 填單

1.1 新建差旅報銷單

1.2 暫存報銷單

1.3 對暫存報銷單進行修改

1.4 提交審批報銷單

2. 審批

3. 付款

對於新建差旅報銷單你可以理解為一個用戶任務，這個用戶任務裡面實際上本身又可以拆分為很多更加細粒度的用戶故事點。比如對於新建差旅報銷單。

1. 申請單填寫 --》對應業務活動

1.1 新建差旅報銷單 --》對應用戶任務

1.1.1 新建基本差旅報銷單

1.1.2 支持報銷到具體項目

1.1.3 支持預定酒店，機票費用自動導入

1.1.4 支持項目預算校驗

1.1.5 支持部門間的費用分攤

1.1.6 支持借款核銷

1.1.7 支持報銷申請時候附件上傳

1.1.8 支持發票自動識別和導入

那麼以上就是一個完整的用戶任務下的細分故事點。那麼這些故事點就需要我們安排到不同的迭代版本。迭代版本的安排重點是根據需求的優先級進行，其次需要考慮需求之間本身相互的依賴性。

基於以上思考，我們可以將以上功能安排到三個迭代版本去完成。

• 迭代1： 完成基本功能，報銷到項目，項目預算校驗，接口核銷
• 迭代2： 完成機票酒店預定自動導入，部門間的費用分配
• 迭代3： 完成附件上傳功能，發票自動識別

以上即完成了一個完整的用戶故事地圖從業務流程到業務活動，用戶任務，用戶故事點到迭代版本任務安排的分解。通過這種方式將所有的業務活動點都進行分解即形成了一個完整的用戶故事地圖。這個用戶故事地圖可以看到就是我們整個迭代產品版本規劃，後續的敏捷項目管理需求和任務的錄入完全可以基於該用戶故事地圖分解的需求和故事點進行全流程管理和端到端跟蹤。

對於業務活動往往會對應到我們實際業務系統中的菜單功能，而對應用戶任務可能是菜單功能粒度，也可以是菜單功能中按鈕級的粒度，這個需要根據實際情況來確定。

敏捷項目管理

在前面講用戶故事地圖和用戶故事的時候，我們可以看到如何形成詳細的用戶故事點，並將用戶故事點規劃到不同的迭代版本的一個初步方法。對於用戶故事點，我們需要注意以下兩點：

• 其一：每個獨立的用戶故事點必須要做到完全可獨立驗證
• 其二：故事點能夠追溯回具體的業務功能和業務場景和業務流程

在用戶故事地圖這個關鍵的步驟做完後，我們實際上得到了一個關鍵的內容，即：

條目化需求-》對應到獨立故事點

我們可以看到整個條目化需求也是我們後續進行敏捷項目管理的要給核心內容，整個需求的端到端跟蹤和管理，敏捷項目管理，計劃和任務的跟蹤全部都需要根據條目化需求展開。

這個條目化需求如何呈現？

即我們經常談到的Scrum裡面提到比較多的兩個內容，即Product Backlog和Spring Backlog

對應產品清單和迭代清單可以分開，即產品清單重點是列出所有的用戶故事點，整理清楚前面我們談到的用戶故事地圖的核心內容。將具體的用戶故事點規劃到具體的迭代清單中。

在產品清單中我們可以只對用戶故事點，給出一個故事功能和場景，優先級的描述即可。對應其它熟悉項往往並不需要在Product Backlog裡面詳細展開。

當我們規劃清楚迭代版本後，我們就需要對迭代版本建立詳細的Spring Backlog迭代清單。

在原來的整個Scrum敏捷項目計劃和任務管理裡面，我們看到需要對於用戶故事進一步在迭代清單中進行任務拆分，一個用戶故事點又拆分為多個任務，可能是開發也拆分為多個任務，也可能是拆分為開發，測試等多個任務。而實際上我們看到：

當前用戶故事點的粒度足夠細的時候，我們的迭代版本清單中不用再進行到任務的拆分，而是通過一行到底的全流程跟蹤方式。這樣往往更加清晰和可視化。這種一行到底的全流程跟蹤，再配合我們實際的Scrum看板基本就能夠很好的完成相關跟蹤工作。

而對於用戶需求點，在迭代版本清單中我們就需要進一步做細化了，包括

1. 用戶故事詳細描述
2. 工作量
3. 開發人員
4. 測試人員
5. 關鍵實現點
6. 關鍵測試點
7. 前置依賴
8. 當前狀態

可能還有一些關鍵屬性項，我們可以根據項目實際情況來增加屬性列。比如我們開發採用的是前後端分離的開發方式，那麼我們的開發人員就拆分為前端開發，後端開發。

這個Backlog整理好後，我們就可以將我們的用戶故事點放到看板上進行跟蹤管理，當然不用看板也可以，之間在Spring清單裡面進行進度跟蹤和反饋。那麼就增加相關的狀態列即可。

通過Scrum敏捷看板進行進度跟蹤

敏捷看板也是Scrum敏捷項目管理方法論裡面比較重要的要給最佳實踐。比如我們用的最簡單的看板就是待辦，正在做，已完成三個狀態的看板。

但是實際上具體看板哪些列我們可以靈活定製，比如更好的一種方式為：

1. 待開發
2. 開發中
3. 測試中
4. 已完成

這樣我們就能夠清楚的看到每一個用戶故事點當前的進度和狀態，也比較容易根據這個來進行燃盡圖的繪製。對于敏捷看板或我們傳統的pms任務管理，更加重要的實際上是如何跟我們的任務跟蹤和持續集成協同起來。這個是需要考慮的一個重點問題。比如：

• 對於一個需求故事點，自動拆分為多個開發或測試任務項。
• 對於任務的完成，自動對看板的狀態進行更新和轉移。
• 對於開發任務的完成，自動觸發相應的持續集成並通知測試進行測試。

這些協同又可以進一步的提升我們整體的敏捷項目管理和開發集成效率。對於這個在我們後續的DevOps支撐平臺敏捷研發過程管理子系統中會進一步去考慮如何自動化集成和協同。

研發管理的關鍵對象分析

對於研發過程管理，可以看到關鍵對象包括產品，項目，項目集，迭代版本，需求，任務，測試用例，缺陷，項目團隊，這也是敏捷項目管理的核心業務對象。

產品一般指我們標準化的產品研發，產品本身也會有版本，但是產品版本如何升級，同樣是需要規劃的研發項目，在研發完成後進行了產品版本升級。因此項目既包括了對內的研發項目，也包括了對外客戶的項目。基於一個標準產品我們會接很大對外項目，很可能都涉及到定製。

比如我們接到中國移動的項目，基於我們標準產品進行定製，那麼這個時候首先要建立中國移動這個項目，項目和產品之間建立關聯。項目本身最好還有大版本和小版本的概念，項目的小版本對應到具體的迭代版本。錄入具體的需求，在需求錄入完成後開始規劃迭代版本，將具體的需求規劃到迭代版本中。同時迭代版本本身屬於一個項目或項目大版本。

對應需求可以拆分為多個任務，當然任務是獨立的獨立，可以關聯到具體的需求，也可以獨立存在不關聯到需求。在任務創建完成後需要確定任務的開始完成時間，工作量評估，然後進入到具體的任務跟蹤。

整個scrum是需求和用戶故事驅動，因此需求錄入完成後，需要基於需求進行測試用例的編寫，一個需求可以對應多個測試用例，然後在開發完成後基於測試用例進行測試發現缺陷，那麼缺陷自然關聯到測試用例，同時也關聯到具體的需求。

一個客戶項目往往可能涉及到我們多個產品，因此一個客戶項目最好規劃為一個項目集，即將多個項目版本納入到一個項目集中進行管理。這樣後續分析的時候可以從項目集維度進行統一的分析和度量。

所有上面的對應後面都會方面我們進行研發過程度量分析使用。

關鍵功能和差異分析

首先項目和項目版本的概念分離，即項目版本即對應到迭代版本或迭代這個對象上面。

一個產品可以對應多個項目，項目可以是內部研發項目，客戶是我們自己，也可以是外部項目對應具體的客戶。當是內部研發項目的時候，研發完成後往往升級產品版本。

項目創建的時候重點是給出項目的執行周期，項目對應的客戶，項目對應的產品，項目中的團隊成員等關鍵信息。在項目規劃完成後，規划具體的項目版本，比如南方電網ESB項目V0.1版本，南方電網ESB項目V0.2版本，

具體的需求注意不掛接在項目下面，而是必須掛接到項目版本下面。

對於版本啟用大版本和小版本，注意大版本是可以直接發到客戶的版本，小版本為內部版本，當然小版本還可以規劃為小版本和迭代版本兩個版本段。

我們來看下具體的場景，當前已經有了標準的ESB V1.0產品版本，當我們接到南方電網ESB項目後，我們首先要錄入南網ESB項目，同時錄入一個V0.1項目版本。然後我們將需求先錄入到產品下面，錄入到產品下面的意思就是一個需求可以規劃到該產品下面不同的項目版本中。

我們來分析下，如果錄入了20個需求點，其中5個是標準化產品需求，15個為定製需求，同時15個定製需求我們準備分三個迭代版本來進行實現。基於上面這個場景，具體操作應該是：

1. 選擇ESB產品，在產品中錄入具體的15個已經拆分後的需求功能點
2. 新創建研發項目V0.1版本，新創建南網項目V0.1, 0.2和0.3版本
3. 分別將上面的20個需求納入到具體的四個項目版本中
4. 南網項目單獨拉一個分支，同時注意對於項目版本的修改需要merge到南網項目分支上

這個梳理清楚後，我們再來看關鍵的需求到任務的關係。

我們舉個簡單的例子來看：

服務實例查詢是一個獨立的需求功能點，那麼針對這個功能點就需要拆分任務，在這裡我們建議增加一個批量添加任務的功能，即針對一個需求功能點，往往存在需求，設計，編碼，測試設計，測試執行，或者開發會進一步分為前端開發，後端開發。我們只需要選擇存在哪些步驟，然後基於這些步驟來自動創建相應的任務名稱。同時任務和人員有匹配，如果任務類型在該項目下只有一個該類型人員，則可以直接將任務默認安排到該人員。即實際可能拆分完成後為：

• 服務實例查詢-需求開發 -- 張三
• 服務實例查詢-編碼 -- 李四
• 服務實例查詢-測試用例編寫 -- 王五
• 服務實例查詢-測試執行 -- 王五

我們再來看下scrum裡面的敏捷看板管理，一種最簡單的方法就是userstory，todo, doing, done幾個關鍵狀態進行管理，而實際上我們可以進行更細化的開發過程狀態跟蹤。即需求故事，待開發（任務清單），開發中，測試中，完成幾個關鍵狀態。

即我們可以設計為在編碼任務，團隊人員領取任務後即進入中開發中狀態，在開發人員反饋任務完成的時候直接進入到測試中狀態，在測試人員反饋測試執行任務完成後進入到已完成狀態。跨泳道流轉的主體為userStory。

測試人員具體具體的用戶故事點進行測試，測試發現的缺陷錄入到缺陷管理模塊中，缺陷自然掛接到具體的需求，同時能夠關聯到具體的項目和項目版本。方便我們後面進行質量分析和項目度量。

敏捷項目管理工具應該具備的核心功能

最後談下敏捷項目管理軟體和工具裡面的以下關鍵業務對象和關鍵功能。

需求-產品-項目-任務-用戶故事-測試用例

這個可以說是整個敏捷開發過程管理的一個關鍵業務對象鏈條。

我們再來對這個關鍵對象鏈條做下說明。

定義一個產品，產品是一個總的概念，一個產品下會有諸多的產品需求，或者說需求提交上來後應該屬於某一個產品。產品本身會涉及到產品版本規劃，產品版本往往是產品通用性的功能迭代。

一個產品下面有很多需求，對於需求的實現我們需要安排到具體的項目裡面。

項目本身也有項目版本，一個項目版本本身可以關聯多個產品需求。將多個產品需求規劃到一個項目迭代版本裡面，後續的重點就是項目的計劃，任務和跟蹤。

產品需求需要細分為用戶故事，往往產品需求並不一定到用戶故事的粒度，因此建議是產品需求本身有一層細分能力，即將產品需求拆分為粒度更小的用戶故事。後續的驅動和跟蹤完全以用戶故事進行。即設計，開發，測試等完全圍繞用戶故事而進行。

項目版本規劃好後，涉及到任務安排，任務仍然是基於用戶故事為粒度，但是任務本身分了不同的類型，不如一個最小化的用戶故事點，往往也涉及到前端開發，後端開發，資料庫設計，測試用例編寫，測試執行等細分的任務，但是這些任務本身完全是基於用戶故事展開和跟蹤。

即我們基於用戶故事進行工作量估算，任務拆分，進行測試用例編寫等動作，形成細粒度的任務跟蹤和監控工作。

項目和項目版本本身又是兩個概念。即我們首先要有項目的概念，再有項目版本的概念，比如我們同樣的ESB產品，可能會涉及到移動和聯通兩個客戶，那麼就是兩個獨立的項目。但是兩個客戶都會存在定製開發，因此在移動項目下會規劃V1, V2等不同的版本，在聯通項目下也會規劃不同的版本。

如果是通用性的功能開發，實際上就屬於通用項目下規劃版本來展開，表示新功能開發適合所有項目。簡單來說就是先收集需求，然後再將需求規劃到不同的項目版本裡面，再進行任務分解和安排，最後對任務執行跟蹤和監控。同時以用戶故事為最小化跟蹤單位完成全流程的跟蹤和監控。

項目集或項目群

一個項目群可以關聯多個項目，實際上這種關聯是一種弱關聯。起到的作用就是我們可以根據項目集進行相應的項目授權和安全管理，可以根據項目集進行相應的統計分析。可以總體視角來看一個項目集的交付過程。

舉例來說

我們是一個團隊，團隊成員同時兼顧了三個項目，那麼我們建立一個項目集，加入最底層的三個項目，那麼我們就能夠對整個團隊建立可視化的工作進度和績效看板，實時了解整個團隊的情況。或者說，我們面對現場一個客戶，但是該客戶同時採購我們我們SOA，MDM，BPM三個子產品，那麼我們可以將三個子產品對應的項目加入到一個項目集中進行統一管理，這樣我們就能夠很方便的看到整體項目集交付進度。

項目集管理不會複雜到傳統項目組合管理裡面那麼複雜，體現一種弱關聯和數據聚合。

缺陷管理能力

缺陷管理是研發過程管理裡面的一個重點功能。簡單來說就是Bug的提交和跟蹤。

需求會對應到測試用例，而實際的缺陷又基於某個測試用例。通過這種方式建立了用戶故事-》測試用例-》缺陷之間的關聯和映射關係。

缺陷提交後需要進行審核，或處理指派，由開發人員修改完成缺陷後轉到待部署狀態，由部署完成後轉回到測試人員進行驗證和最終關閉。而這個缺陷狀態流轉過程，需要結合DevOps實現一個自動化狀態流轉。

變更管理

需求本身就包括了新增需求和變更需求，實際上對應需求提交和處理分析流程完全統一，同時支持新增需求和變更需求。唯一就是對應變更需求需要增加變更影響分析。在微服務架構下，變更影響分析需要分析到究竟影響到哪些微服務模塊，哪些具體的責任人，然後基於該影響分析進行任務拆分，在任務拆分後再進行任務跟蹤。

那麼如果對於前後端開發分離的情況下，一個變更就需要在前後端配套的修改都全部完成後才能夠進行完整的黑盒功能測試。但是在後端功能完成後我們已經可以進行自動化的接口單元測試。

---

歡迎關注@人月聊IT 分享SOA，微服務，DevOps平臺規劃和建設。