本系列的第一篇【使用者故事驅動的敏捷開發 – 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組織心領神會，更重要的是將以完全不同於以往的視角看待自己的工作環境。

這個樣例應用可以通過以下地址訪問：

這是一個簡單的電子商務網站原型，具備產品列表，購物車，後臺管理，促銷和訂單處理等電子商務網站的基本功能。你可以瀏覽一下這個網站，對其中的功能簡單瞭解一下。

使用者故事列表

以下是我使用影響地圖和使用者故事地圖整理出來的故事列表，每張圖片的左側是影響地圖，列出一個故事；右側是這個故事所分解出來的功能點擺放在使用者故事地圖上的的效果。

上面5個使用者故事所分解出來的功能點我分別使用不同顏色在故事地圖上進行了標註，你可以看到當故事不停增加的時候，這個地圖會慢慢變得非常龐大而繁雜，分辨出使用者故事變得越來越難。

使用Team Foundation Server來管理使用者故事

Team Foundation Server (TFS) 是微軟公司的研發管理平臺，其中提供了從需求管理，專案管理，配置（原始碼）管理，測試管理，程式碼編譯持續整合，自動化測試，自動化釋出及部署環境管理在內的研發運維一體化（DevOps）的完整工具鏈。微軟自己的大多數產品都在使用這個平臺進行研發管理，其中也對敏捷開發提供了很好的支援。

在整理使用者故事的過程中，我們可以先使用Excel來記錄這些使用者故事和功能點，同時記錄每個功能點所屬的功能區域，形成類似以下的文件。

以上表格中，我們用二維表的方式儲存了使用者故事地圖上的所有關鍵資訊，在匯入到TFS的時候需要注意：

• 故事地圖實際上是一個二維表格，頂部的功能區域/模組部分是功能點的分類，這部分內容可以使用TFS所自帶的區域路徑 來進行表達
• 每個故事（左側的WHY-WHO-HOW/WHAT），與右側的功能點之間是一種父子的一對多關係，可以用TFS backlog中的不同級別的工作項所代表，TFS可以維護不同級別工作項之間的父子關係，正好可以跟蹤這部分資訊
• 右側的每個卡片對應到這個二維表頂部的特定的功能區域/模組，我們在匯入的時候只要設定每個工作項的 區域路徑 欄位的值，完成這種對應資訊的跟蹤

首先，在TFS中按照功能區域和模組建立區域路徑，對應到使用者故事地圖頂部的分類資訊

現在我們就可以將我們的使用者故事匯入到TFS中，

形成的backlog如下，你可以看到TFS很好的維護了我們的使用者故事到功能點之間的聯絡，同時也保留了每個功能點所對應的功能區域，這樣就把使用者故事地圖上的關鍵資料進行了很好的維護，便於我們從不同的角度來檢視和跟蹤。

匯入的工作項用不同的欄位保留了使用者故事地圖上的關鍵資訊：

當然，你仍然需要對每個使用者故事工作項和功能點工作項進行進一步完善，將團隊在討論過程中所產出的資訊進行記錄，比如：每個使用者故事需要包括使用者背景，操作流程圖，互動設計原型；每個功能點需要包括資料字典，輸入輸出，資料驗證，介面原型等。這些內容可以直接填寫在工作項的 說明 欄位，或者使用附件的形式上傳到工作項上統一儲存。

在規劃篇中，我強調過使用者故事所注重的是它所驅動的過程，而不是那份文件。但是，我們仍然需要將團隊討論中所產生的關鍵資訊進行詳細的記錄，這樣便於團隊在後續的開發中回憶起討論的細節。這些資訊在看板或者白板這種物理工具上是無法表達和儲存的，所以這個時候引入電子化工具恰到好處。

我們所匯入的故事和功能點將構成後續開發所使用的backlog，便於團隊對這些內容進行優先順序排序，迭代規劃，任務分解，測試計劃的制定，測試用例的分解等等。也就是說，後續的軟體研發過程均會按照我們匯入的backlog作為主線進行。這樣，團隊既可以按照使用者的角度來抽取出相應的功能點，也可以從產品模組的角度檢視功能列表和影響這些模組的使用者需求，保證團隊在滿足使用者需求與架構優化演進之間做出取捨，為團隊建立起完整的需求跟蹤檢視（有很多團隊會稱之為需求跟蹤矩陣）。

見下圖，我們之前所做的其實就是建立的圖中的 架構模型 和 條目化需求 部分的內容，同時在這兩部分內容之間建立的聯絡，這些是建立一個軟體研發管理系統的源頭。

至此，我們就完成了使用者故事到產品backlog的轉化，下一篇中將介紹如何完成開發和測試計劃的制定，並開始引入Kanban來跟蹤開發過程。