本系列的第一篇【使用者故事驅動的敏捷開發（規劃篇）】跟大家分享了如何使用使用者故事來幫助團隊建立需求的過程，在這一篇中，我們來看看如何使用這些使用者故事和功能點形成產品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 (tfs) 是微軟公司的研發管理平台，其中提供了從需求管理，專案管理，配置（源**）管理，測試管理，**編譯持續整合，自動化測試，自動化發布及部署環境管理在內的研發運維一體化（devops）的完整工具鏈。微軟自己的大多數產品都在使用這個平台進行研發管理，其中也對敏捷開發提供了很好的支援。
在整理使用者故事的過程中，我們可以先使用excel來記錄這些使用者故事和功能點，同時記錄每個功能點所屬的功能區域，形成類似以下的文件。
以上**中，我們用二維表的方式儲存了使用者故事地圖上的所有關鍵資訊，在匯入到tfs的時候需要注意：
1. 故事地圖實際上是乙個二維**，頂部的功能區域/模組部分是功能點的分類，這部分內容可以使用tfs所自帶的區域路徑來進行表達；
2. 每個故事（左側的why-who-how/what），與右側的功能點之間是一種父子的一對多關係，可以用tfs backlog中的不同級別的工作項所代表，tfs可以維護不同級別工作項之間的父子關係，正好可以跟蹤這部分資訊；
3. 右側的每個卡片對應到這個二維表頂部的特定的功能區域/模組，我們在匯入的時候只要設定每個工作項的區域路徑欄位的值，完成這種對應資訊的跟蹤。
首先，在tfs中按照功能區域和模組建立區域路徑，對應到使用者故事地圖頂部的分類資訊
現在我們就可以將我們的使用者故事匯入到tfs中，
關於如何使用excel批量匯入和更新工作項，請參考：匯入的工作項用不同的字段保留了使用者故事地圖上的關鍵資訊：
當然，你仍然需要對每個使用者故事工作項和功能點工作項進行進一步完善，將團隊在討論過程中所產出的資訊進行記錄，比如：每個使用者故事需要包括使用者背景，操作流程圖，互動設計原型；每個功能點需要包括資料字典，輸入輸出，資料驗證，介面原型等。這些內容可以直接填寫在工作項的說明字段，或者使用附件的形式上傳到工作項上統一儲存。
在規劃篇中，我強調過使用者故事所注重的是它所驅動的過程，而不是那份文件。但是，我們仍然需要將團隊討論中所產生的關鍵資訊進行詳細的記錄，這樣便於團隊在後續的開發中回憶起討論的細節。這些資訊在看板或者白板這種物理工具上是無法表達和儲存的，所以這個時候引入電子化工具恰到好處。
我們所匯入的故事和功能點將構成後續開發所使用的backlog，便於團隊對這些內容進行優先順序排序，迭代規劃，任務分解，測試計畫的制定，測試用例的分解等等。也就是說，後續的軟體研發過程均會按照我們匯入的backlog作為主線進行。這樣，團隊既可以按照使用者的角度來抽取出相應的功能點，也可以從產品模組的角度檢視功能列表和影響這些模組的使用者需求，保證團隊在滿足使用者需求與架構優化演進之間做出取捨，為團隊建立起完整的需求跟蹤檢視（有很多團隊會稱之為需求跟蹤矩陣）。
見下圖，我們之前所做的其實就是建立的圖中的架構模型和條目化需求部分的內容，同時在這兩部分內容之間建立的聯絡，這些是建立乙個軟體研發管理系統的源頭。
使用者故事驅動的敏捷開發（規劃篇）
本系列的第二篇 使用者故事驅動的敏捷開發 建立backlog 敏捷開發現在已經不是新鮮事物了，我們都從各種渠道聽到過不同的團隊實施敏捷的勝果，聽的時候覺得很美，回到家就發現那都是別人家的團隊，結合自己的情況一看就發現問題一大堆。就算是最終打算一試，也經常會不知如何開始。這就是我希望編寫這份文件的原因...
敏捷開發的使用者故事怎麼寫？
以下是近期對敏捷開發中由以往 調研 文件 討論 文件 開發 文件 向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。如何編寫使用者故事？1 使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。2 格式 ...
敏捷開發使用者故事系列之五 使用者故事的分類
這是敏捷開發使用者故事系列的第五篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 在之一 之二 之三中，我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...