本系列的第一篇【用戶故事驅動的敏捷開發 – 1. 規划篇】跟大家分享了如何使用用戶故事來幫助團隊創建需求的過程，在這一篇中，我們來看看如何使用這些用戶故事和功能點形成產品backlog。產品backlog是敏捷開發中用來管理需求列表，排定優先級，形成迭代計划，組織開發/測試和交付過程的工具。可以說，產品backlog是一個敏捷團隊管理開發過程的核心，所有的活動和交付物都圍繞backlog來進行。一旦需求明確，我們就必須在開發過程中持續的跟蹤backlog內容的實現和交付過程，確保我們的想法可以按照我們希望的時間和質量交付，及時了解偏差並做出調整。
從這個時間點開始，我們需要引入電子化工具來管理我們的開發過程。其實，每個開發團隊都會或多或少的使用某種電子化工具，用最多的估計是Word/Excel/Project這種辦公軟件，還有就是如Jira, Redmine, Bugzilla 等工具。對於軟件研發來說，我們需要管理內容包括：1）需求/任務/測試用例/Bug/問題等工作事項；2）源代碼；3）各種計划，包括迭代計划，發布計划，測試計划等；4）各種工件（包括：依賴包/在制品/交付物），如：JAR包，WAR包，NuGet包，NPM包，安裝包，交付包等；5）人員/團隊。所以，對於軟件研發管理系統來說，我們至少需要這些功能：1）工作項跟蹤；2）計划制定和跟蹤；3）人員（包括權限）管理；4）源代碼管理；5）自動化引擎。
很多敏捷教練其實對電子化工具持保留態度，覺得電子化的backlog或者kanban等工具會影響團隊的參與感和靈活性。對這一點，我也同意，特別是在進行創造的過程中，我也不贊成使用電子化工具。主要原因是創造的過程需要集思廣益，需要每個團隊成員都有參與感，需要每個人可以隨時對於用戶故事做出改變，這樣的過程如果使用電子化工具會很受限制。
但是，電子化工具仍然有其不可替代的用武之地，特別是我們需要進行持續的跟蹤和數據分析的時候，電子化工具就顯示出它的優勢；同時，如果你的團隊分布在不同的物理地點，那么使用電子化工具就成為一種必然。因為這些場景都是物理板無法發揮作用的時候。另外，考慮到軟件開發過程的復雜性和各個部分只見關聯性很強，如果沒有電子化工具的輔助，是很難支撐一個團隊的開發工作的。
在我帶領團隊使用用戶故事地圖的過程中，隨着用戶故事數量的增加，我發現團隊開始迷失功能點與故事之間關聯性，分解出來的功能點被淹沒在不同的模塊之中了，用戶故事已經開始慢慢消失了。這是個非常不好兆頭，所以我在這個時候開始要求團隊引入電子化工具。
樣例程序和用戶故事列表
為了能夠更好的說明這個過程，在這個系列中我使用【鳳凰項目：一個IT運維的傳奇故事】這本書為背景的ASP.NET 5樣例應用，創建了一些用戶故事
關於【鳳凰項目：一個IT運維的傳奇故事】：本書講述了一位IT經理臨危受命，在未來董事的幫助和自己“三步工作法”理念的支撐下，最終挽救了一家具有悠久歷史的汽車配件制造商的故事。 小說揭示了管理現代IT組織與管理傳統工廠的共通之處，讓讀者不僅能對如何管理IT組織心領神會，更重要的是將以完全不同於以往的視角看待自己的工作環境。
可以通過以下鏈接購買這本書的中文版：http://item.jd.com/10034038960.html
這個樣例應用可以通過以下地址訪問：
http://pucd.chinacloudsites.cn/
這是一個簡單的電子商務網站原型，具備產品列表，購物車，后台管理，促銷和訂單處理等電子商務網站的基本功能。你可以瀏覽一下這個網站，對其中的功能簡單了解一下。
用戶故事列表
以下是我使用影響地圖和用戶故事地圖整理出來的故事列表，每張圖片的左側是影響地圖，列出一個故事；右側是這個故事所分解出來的功能點擺放在用戶故事地圖上的的效果。
上面5個用戶故事所分解出來的功能點我分別使用不同顏色在故事地圖上進行了標注，你可以看到當故事不停增加的時候，這個地圖會慢慢變得非常龐大而繁雜，分辨出用戶故事變得越來越難。
使用Team Foundation Server來管理用戶故事
Team Foundation Server (TFS) 是微軟公司的研發管理平台，其中提供了從需求管理，項目管理，配置（源代碼）管理，測試管理，代碼編譯持續集成，自動化測試，自動化發布及部署環境管理在內的研發運維一體化（DevOps）的完整工具鏈。微軟自己的大多數產品都在使用這個平台進行研發管理，其中也對敏捷開發提供了很好的支持。
在整理用戶故事的過程中，我們可以先使用Excel來記錄這些用戶故事和功能點，同時記錄每個功能點所屬的功能區域，形成類似以下的文檔。
以上表格中，我們用二維表的方式保存了用戶故事地圖上的所有關鍵信息，在導入到TFS的時候需要注意：
- 故事地圖實際上是一個二維表格，頂部的功能區域/模塊部分是功能點的分類，這部分內容可以使用TFS所自帶的區域路徑 來進行表達
- 每個故事（左側的WHY-WHO-HOW/WHAT），與右側的功能點之間是一種父子的一對多關系，可以用TFS backlog中的不同級別的工作項所代表，TFS可以維護不同級別工作項之間的父子關系，正好可以跟蹤這部分信息
- 右側的每個卡片對應到這個二維表頂部的特定的功能區域/模塊，我們在導入的時候只要設置每個工作項的 區域路徑 字段的值，完成這種對應信息的跟蹤
首先，在TFS中按照功能區域和模塊創建區域路徑，對應到用戶故事地圖頂部的分類信息
現在我們就可以將我們的用戶故事導入到TFS中，
關於如何使用Excel批量導入和更新工作項，請參考：https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel
形成的backlog如下，你可以看到TFS很好的維護了我們的用戶故事到功能點之間的聯系，同時也保留了每個功能點所對應的功能區域，這樣就把用戶故事地圖上的關鍵數據進行了很好的維護，便於我們從不同的角度來查看和跟蹤。
導入的工作項用不同的字段保留了用戶故事地圖上的關鍵信息：
當然，你仍然需要對每個用戶故事工作項和功能點工作項進行進一步完善，將團隊在討論過程中所產出的信息進行記錄，比如：每個用戶故事需要包括用戶背景，操作流程圖，交互設計原型；每個功能點需要包括數據字典，輸入輸出，數據驗證，界面原型等。這些內容可以直接填寫在工作項的 說明 字段，或者使用附件的形式上傳到工作項上統一保存。
在規划篇中，我強調過用戶故事所注重的是它所驅動的過程，而不是那份文檔。但是，我們仍然需要將團隊討論中所產生的關鍵信息進行詳細的記錄，這樣便於團隊在后續的開發中回憶起討論的細節。這些信息在看板或者白板這種物理工具上是無法表達和保存的，所以這個時候引入電子化工具恰到好處。
我們所導入的故事和功能點將構成后續開發所使用的backlog，便於團隊對這些內容進行優先級排序，迭代規划，任務分解，測試計划的制定，測試用例的分解等等。也就是說，后續的軟件研發過程均會按照我們導入的backlog作為主線進行。這樣，團隊既可以按照用戶的角度來抽取出相應的功能點，也可以從產品模塊的角度查看功能列表和影響這些模塊的用戶需求，保證團隊在滿足用戶需求與架構優化演進之間做出取舍，為團隊建立起完整的需求跟蹤視圖（有很多團隊會稱之為需求跟蹤矩陣）。
見下圖，我們之前所做的其實就是建立的圖中的 架構模型 和 條目化需求 部分的內容，同時在這兩部分內容之間建立的聯系，這些是建立一個軟件研發管理系統的源頭。
至此，我們就完成了用戶故事到產品backlog的轉化，下一篇中將介紹如何完成開發和測試計划的制定，並開始引入Kanban來跟蹤開發過程。
注：以上場景是【DevOps敏捷開發動手實驗】的一部分，請點擊以下鏈接訪問這個動手實驗的指導文檔：
http://vsalm-hols.readthedocs.org/
參考資料：
有關用戶故事地圖：
http://devopshub.cn/2016/01/10/user-story-mapping-for-the-first-time/
http://devopshub.cn/2016/01/11/how-to-create-user-story-mapping/
有關Team Foundation Server:
http://vsalm-hols.readthedocs.org/zh_CN/latest/concepts/about-vsalm.html