為什麼扁平的使用者故事待辦列表效果不好？如何構建一個更好的使用者故事待辦列表，用來更有效的描述你的系統，進行優先順序排序和制定釋出計劃。
這是Gary。
Gary和我用了一整天的時間製作了一副使用者故事地圖——一個更好的產品待辦列表。構建使用者故事地圖幫助我們聚焦在產品的全貌上而不是關注每一個使用者故事。
當進行優先順序排序時，Gary基於整個系統的上下文進行排序。Gary的目標是構建一個叫做Mimi (Music Industry Marketing Interface 一個面向音樂行業的系統) 的產品。然而，當對“樂隊成員宣傳音樂會”這個故事進行排序時，發現這個故事太大了，事實上這應該是一個“史詩故事”，後來它佔據了地圖上的很大面積去考慮所有的細節，比如：設計一個宣傳海報，構建一個郵件列表，郵遞宣傳海報，跟蹤市場反應。在製作使用者故事地圖的最後環節，發現要完成Mimi產品中所有音樂相關的事情是不可能的，然而，製作一個更快更容易地傳送宣傳海報的軟體看起來是個好主意。後來的事實證明這確實是個好主意。
Mimi在Gary的努力下最終釋出了，Mimi目前每月傳送上百萬條資訊。卓越的使用者體驗讓Mimi好像是一個藝術品。同時，我們當時構建的使用者故事待辦列表仍然可以從最高的視角觀察整個系統。
扁平的使用者故事待辦列表是無效的
對我而言，敏捷實踐中其中一項最麻煩的事情就是關於扁平的使用者故事待辦列表，它看起來是個很笨的主意。如果我希望小規模增量開發軟體，我需要知道從哪裡開始。待辦列表把使用者故事進行排序（從高價值到低價值），這對專案經理是一個不錯的主意，但是我不是專案經理。
我正在從客戶現場返回的飛機上寫這篇blog。我和客戶都覺得這兩天進行的使用者故事整理和釋出計劃制定過程進行得非常順利。我很高興的看到客戶對他們在做的這項實踐非常投入，我把這個實踐叫做使用者故事地圖。我第一次描述這個實踐的文章“How You Slice It”釋出於2005年1月。其實在寫那篇文章之前，我已經使用這種實踐很多年了。
幾年以後，我越來越熱愛這個實踐，以至於把這個實踐視作“銀彈”-這對我來說是一個警告訊號。然而，我看到越來越多的人正在採用類似的實踐，至少這說明我並不是特別瘋狂。
讓我描述一下錯誤的使用者故事編寫是怎樣的，什麼是使用者故事地圖，為什麼它可以解決問題。
扁平的待辦列表很難解釋系統是用來做什麼的
當干係人或使用者問你：“你們正在開發的系統是做什麼的？”，大家一般都會直接把使用者故事待辦列表發給他看。然而我覺得，把使用者故事按照優先順序順序排列並不能幫我向其他人解釋系統是做什麼的。
對我而言，試圖理解整個系統是軟體開發中最困難的部分。我從敏捷團隊聽到的一個最普遍的抱怨就是他們丟失了系統的全景圖——即使他們在開始階段曾經很清晰這個全景圖是怎樣的。
我一般會這樣解釋扁平化使用者故事待辦別表存在的問題，就好像：
“我們花了大量時間與客戶一起工作。我們努力理解他們的目標，他們的使用者，還有我們要構建的系統的主要功能。最後我們進入細節-我們要構建的系統功能模組。在我的腦海裡，我看到一棵樹，樹幹代表著系統的目標或者理想收益；大的樹枝代表使用者；小的樹枝和嫩枝代表使用者需要的能力；最終樹葉代表使用者故事，這些使用者故事足夠小到被放入迭代。“
“所有的工作完成後，當所有人有了統一的理解之後，我感覺我們摘下了所有的葉子並把葉子放入了一個袋子，然後砍掉了樹。“
“這就是我對扁平化待辦列表的理解，一袋子沒有上下文背景的樹葉。”
上下文才是真正可以幫我將一個系統描述清楚的重要資訊。
對於一個新的系統，扁平化待辦列表無法幫助我確認是否已經識別出全部故事
拿著一堆索引卡，或者一份填滿使用者故事的表格，我可以花幾個小時盯著它們，然後又花上幾個小時對它們進行討論…但我總有一種不安的感覺：似乎漏掉了什麼東西。當然我知道我不可能毫無遺漏——我只是希望能夠感覺更踏實一點。
想一想，當你梳理軟體需求範圍時，有多少次你曾經忽略掉重要的功能模組？
使用扁平化待辦列表是很難制定釋出計劃的
對我參與過的典型專案而言，使用者故事少則幾十，多則上百。在開始階段，我一般會盡量幫助使用者讓使用者故事都處在比較high level的狀態，即便是這樣待辦列表中包含120個左右的使用者故事也是很正常的結果。詳細分析每一個使用者故事並且做出是否採納的決定是非常乏味的。優先順序排序會議在我生命中從來都是一種痛苦的回憶。
構建使用者故事地圖
讓我們把使用者故事展示成一個有幫助的形狀——一副對我工作很有幫助的，地圖。
這確實是一個很簡單的想法。一個小的使用者故事地圖看起來就像這樣：
地圖的頂層是“大故事”。我稱他們為使用者活動。活動是由人執行的一個比較大的動作，它包含大量的步驟，雖然並不總是有一個精確地工作流。舉個栗子，如果我正在構建一個郵件系統，我會有這樣一些活動：“管理郵件”，“配置郵件伺服器”，“設定不在辦公室自動回覆”。
一個關於“活動”的使用者故事應該這樣讀：作為一個顧問，我希望能夠管理我的郵件，使我可以與客戶，同事和朋友保持聯絡。
但是活動太大了，很難放入迭代或衝刺中。
這個活動可以被分解成一些使用者故事，例如“傳送郵件”，“讀郵件”，“刪除郵件”，“標識垃圾郵件”等。我把這些稱為使用者任務。對於許多敏捷開發人員來說，任務就是為了完成使用者故事所做的事情。事實上，任務是用來達成一個目標的一個步驟。一個使用者任務是可以幫助使用者達成一個目標，而開發人員的任務是用以完成使用者故事的。
我把簡單的小的事物（使用者任務）安排在大的事物（使用者活動）下面，形成成一個網狀結構。
我總是想象時間從左往右流動。例如當我在地圖中放置使用者故事時，如果使用者在使用系統時總是按某種順序執行操作，我總是把先執行的放在左邊，後執行的放在右邊。對使用者活動和使用者任務我都是這樣處理。
當我傳授這種方法時，人們總是告訴我“使用者可能按照任何順序進行操作。我應該按什麼順序在地圖上進行擺放呢？”我會問他們“請解釋給我聽系統是用來做什麼的——只需要告訴我使用者活動。”他們會列舉給我。“那就是正確的順序”，我會說。事實上，你描述系統行為的順序就是正確的順序。我們正在構建一副地圖，它讓我們能夠講述一個關於系統的真實故事。用可以讓你講故事的方式來構建使用者故事地圖。
保留你的史詩故事，但不要再使用這個叫法，因為這個術語讓我困惑
真正的大故事可以被稱作“史詩故事”，就像Mike Cohn那樣稱呼他們。他們也是故事——一些大到無法估算和構建的故事。當一個史詩故事進入到你的待辦列表，就需要詳細的討論，我經常看到人們把史詩故事從待辦列表中移除，然後進行分解，把分解出的結果放入待辦列表。回憶一下我上面的故事吧：把樹砍掉，然後把樹葉放入袋子。
大的故事是上下文。它能夠讓我很快想起使用者正在做的完整使用者活動，也能夠讓我很快解釋給其他人系統是用來做什麼的。
然而，我討厭“史詩故事”這個詞，我認為僅僅使用“管理郵件”——一個從使用者視角的基本描述就夠了。至少“使用者活動”和“使用者任務”這樣的術語讓我清晰的知道他們對應的故事型別。也就是說，我也不喜歡“使用者故事”這個詞彙，但是我已經慢慢接受它。我仍然會很難面對C-level管理人員的眼睛，當我解釋給他聽“我們已經把您的系統分解成一系列的史詩故事和使用者故事”。如果我這樣說，我可以想象他會充滿敵意的考慮我的每人天諮詢價格。
遍歷你的地圖進行測試——獲得全景圖
對著一副組合好的使用者故事地圖，我能夠和使用者，開發人員，或者干係人一起遍歷地圖，並且講述一個關於使用者如何使用系統的故事。我可以只遍歷地圖的最上層，high-level的描述一下系統。我也可以深入地圖對細節進行討論。
和使用者或者其他人遍歷地圖可以幫助我找到遺漏的內容。我經常從使用者那裡聽到“你在這漏掉了一些步驟”。
我經常在地圖上標識出痛點或者機會。當我和使用者遍歷地圖時，我通常會聽到“這裡確實是系統目前面臨的問題”。
和使用者一起工作時，他們經常糾正我。昨天我和一個新系統的潛在使用者一起工作——她是一個公司的合規官。她一邊說，我一邊記下流程步驟並且放到地圖上。我用綠色卡片記錄大的活動，黃色卡片記錄小的任務。她迅速糾正我——“不，那個應該使用黃色卡”。在不到一個小時的討論中，她能夠僅僅使用很少的話語就可以提供大量的關於她會如何使用系統的資訊。他知道黃色卡片代表的工作比綠色的要小，並且能夠告訴我她在系統中做的事情並沒有我想象的那麼大。
構建和遍歷使用者故事地圖讓我比以往任何時候都感到舒適，因為我能夠獲取資訊並且不會遺漏大的事物。
你的軟體擁有脊椎和骨架—你的地圖把它們顯示出來了
我發現地圖頂部的卡片看起來有點像脊骨，掛在下面的卡片像肋骨。那些頂部的卡片通常代表系統需要具備的基本能力。我稱它們為軟體的“脊椎”。
現在該給使用者故事排優先順序了，我不需要給脊椎排優先順序，脊椎的優先順序已經排好了。我只給肋骨—那些掛在脊椎下面的故事排優先順序。把脊椎擺在最上面意味著他們不可或缺，擺在下面的意味著重要性降低。當你做這件事的時候，你會發現擺在最上面的故事描述了你可以構建的最小可行性系統，它包含了端到端的功能集。我總是試著首先構建出這副地圖。
使用脊骨進行計劃
現在開始製作釋出計劃，通常對脊骨進行排序並不重要。例如如果你希望為汽車構建一個high-level待辦列表，它看起來像這樣：
- 引擎
- 傳動系統
- 剎車
- 懸架
…
這似乎是愚蠢的，如果你讓干係人對這些進行排序：“哪一個更重要，引擎或者傳動系統？”或者“我們在這個釋出週期沒有足夠時間，我們可否先發布沒有剎車的汽車？”這些內容都是必要的—我們需要所有的內容去交付一個最小可行性產品（MVP）。
當優先順序排序到了更低的層次：4缸引擎或者6缸引擎？是否應該具有防抱死功能？是否要有運動懸掛？這就是我們構建肋骨的過程—對重要的特性進行排序。
當你在使用者故事地圖上進行優先順序排序時，你需要上下移動卡片來表示優先順序的高與低。之後，我會用長膠帶在故事地圖上為每個釋出建立泳道，接下來我會在泳道之間上下移動使用者故事，甚至改變泳道的高度。
保留故事地圖，用以溝通系統的全景
構建使用者故事地圖可以在開始階段理解系統需要的功能。問你自己一個問題：你是否需要持續理解系統需要什麼樣的功能？我知道這不是一個公平的問題，但是我確實發現有些人花費了大量時間整理出類似使用者地圖的東西，然後把分析結果塞入扁平的待辦列表中。如同砍掉了樹，然後把樹葉塞入了袋子。
我發現使用者故事地圖就好像一個資訊雷達一樣，我們總是對著它討論我們正在構建的產品。當專案正在進行時，它會轉化為我們的衝刺板或迭代計劃板。我們可以在地圖上直接標識出下個迭代要完成的使用者故事。在迭代過程中，我們把要完成的使用者故事放置到任務牆上管理它們的開發—但是故事地圖始終提醒我們系統的全景圖是怎樣的，我們現在已經走到了哪裡。
當我們增量構建軟體時，一個故事接著一個故事，我們按照地圖上從左到右的，從上到下的順序。我們慢慢的從左到右的遍歷脊骨，從上到下的遍歷肋骨。我們並不是每次只構建一個特性，而是同時構建所有的主要特性。就好像我們從不會釋出一個沒有剎車的汽車。
為老產品增加特性，構建不同的使用者故事地圖
當為老產品增加特性時，產品已經有了脊骨—足夠多的特性已經被髮布。我發現識別脊骨依然可以讓我有效瞭解上下文—讓我瞭解新的特性應該被放在什麼位置。
對某些專案而言，如果要對一個很大規模的產品增加少量特性時，可能很難和干係人討論並構建故事地圖。這種情況下，我僅僅對新的特性進行優先順序排序，然後針對每個特性構建一個小的使用者故事地圖並對使用者故事進行優先順序排序。每個小故事地圖大約包含10張左右的卡片—但它們仍然按照從左到右，從上到下的方式進行排布，我們應該儘早專注於構建一個小的行走的特性骨架。
這是一種模式—而不是一種發明
雖然我儘量避免，但當有人告訴我這個概念時（一個知名的諮詢顧問正在教授這種方法管理待辦列表），我依然非常憤怒。“他們竊取了我的方法！”是的，我是這麼認為的。但是我不得不提醒自己我也從其他人那裡學習了很多類似的東西。我清楚早期在ThoughtWorks工作時，我就已經碰巧看到Luke Barrett正在構建幾乎同樣的模型。
我總是提醒自己這種方法是一個模式。如果你解釋給其他人一個概念，他們說“好酷的想法！”這不是模式。但是如果他們說“我們也在做類似的事情！”這就是模式。因為我經常看到類似的方法，所以這個方法是一種模式。
當教授這個方法時，我喜歡播放Indi Young的使用者研究構思模型，模型把使用者行為按照從左到右的順序排列，把特性放置在相關的使用者行為的附近。我喜歡Todd Warfel的任務分析網狀圖，它擁有類似使用者故事地圖的脊骨，所有使用者故事按照優先順序排在下面。Todd使用顏色代表優先順序，而不是垂直方向的順序。
本文翻譯自Jeff Partton的部落格，原文地址：http://jpattonassociates.com/the-new-backlog/
翻譯，李強，現任英捷創軟（LEANSOFT）資深DevOps顧問和解決方案專家兼市場總監，曾任微軟Visual Studio產品資深解決方案專家，IBM Rational產品資深解決方案專家，匯豐中國區軟體開發中心CMMI諮詢顧問，具有Scrum Master，SAFe，CMMI，PMP和CSQA等資質。
專案經驗：
- OPPO敏捷開發及工具平臺專案
- 中興通訊敏
- 捷開發專案
- 遠光軟體開發過程改進及工具平臺專案
- 廣發銀行ALM專案
- 廣州農商行ALM專案
- 四川農信ALM專案
- PICC ALM專案
請關注微信公眾號 【devopshub】，獲取更多關於DevOps研發運維一體化的資訊
