摘要
本書講述了使用敏捷技術執行從想法到實施的開發過程的演算法。 該過程按步驟進行佈置，並且在每個步驟中都指示了該過程步驟的方法。 作者指出，大多數方法都不是原創的，也沒有聲稱是原創的。 但良好的寫作風格和完整的過程使這本書非常有用。
使用者故事映射的一項關鍵技術是隨著使用者在流程中的移動來建立想法和表現。
同時，可以用不同的方式來描述該過程。 您可以在實現關鍵值時制定步驟，或者您可以簡單地想像並想像用戶使用系統的工作日。 作者重點關注這樣一個事實：流程需要以流程圖上的使用者故事的形式進行概述，這就是使用者故事圖名稱的由來。
誰需要它
適用於 IT 分析師和專案經理。 必讀。 該書中等大小，讀起來輕鬆愉快。
召回
最簡單的形式就是這樣運作的。
訪客來到咖啡館，選擇菜餚、下訂單、收食物、用餐並付款。
我們可以在每個階段編寫我們想要從系統中獲得什麼的需求。
系統應顯示菜餚列表，每道菜都有成分、重量和價格，並且能夠添加到購物車。 為什麼我們對這些要求充滿信心？ 這在需求的「標準」描述中沒有描述，這會產生風險。
不理解為什麼這是必要的表演者通常會做錯誤的事情。 不參與創造想法過程的表演者也不參與結果。 敏捷說，讓我們主要關注的不是系統，而是人、消費者、他們的任務和目標。
我們創造角色，為他們提供同理心的細節，並開始從角色的角度講述故事。
辦公室員工扎克哈去吃午餐了，想吃點快餐。 他需要什麼？ 這個想法是他可能想要一頓商務午餐。 另一個想法是，他希望系統記住他的偏好，因為他正在節食。 另一個想法。 他希望立即為他送咖啡，因為他習慣在午餐前喝咖啡。
還有一個業務（組織角色是代表組織利益的角色）。 企業希望增加平均支票，增加購買頻率，增加利潤。 我們的想法是——讓我們提供一些不尋常的菜餚。 另一個想法——讓我們介紹一下早餐。
想法可以而且應該以使用者故事的形式具體化、轉化和呈現。 作為 Zakhar 商務中心的員工，我希望系統能夠識別我，以便我可以收到基於我的喜好的選單。 作為一名服務員，我希望系統能夠通知我何時接近餐桌，以便客戶對快速服務感到滿意。 等等。
幾十個故事。 接下來是優先順序和待辦事項？ 傑夫指出了出現的問題：陷入小細節並失去概念理解，再加上優先考慮功能會因與目標不一致而造成一幅參差不齊的畫面。
作者的路徑：我們優先考慮的不是功能，而是結果=使用者最終得到什麼。
一個明顯不明顯的點：優先排序會議不是由整個團隊進行的，因為它效率低下，而是由三個人進行。 第一個負責業務，第二個負責使用者體驗，第三個負責執行。
讓我們選擇解決一個使用者問題的最小值（最小可行解決方案）。
我們透過告訴團隊並與團隊討論人們和利害關係人在流程的每個步驟中需要什麼，在使用者故事地圖上使用使用者故事、設計草圖、約束和業務規則來詳細說明首要的想法。 我們將剩餘的想法留在積壓的機會中，未經審查。
流程從左到右寫在卡片上，流程步驟下方的卡片上寫有想法。 必須與團隊成員一起討論整個故事的發展路徑，以確保相互理解。
以這種方式進行的細化創造了符合流程的完整性。
收到的想法需要測試。 非團隊成員戴上這個人的帽子，在腦海中過著這個人的一天，解決他的問題。 有可能他沒有看到進展，再次創建卡片，團隊為自己尋找替代方案。
然後是評估細節。 這事三個人就夠了。 負責使用者體驗、開發人員、測試人員最喜歡的問題是：「如果…會怎樣」。
在每個階段，討論都遵循使用者歷史的流程圖，這允許牢記使用者的任務以形成連貫的理解。
作者認為文檔是否必要？ 是的，我需要它。 但作為註釋可以讓您記住您同意的內容。 再次讓局外人參與進來，需要討論。
作者並沒有深入探討文檔充分性的議題，而是專注於討論的必要性。 （是的，文件是需要的，無論那些對敏捷沒有深入了解的人如何聲稱它）。 此外，僅詳細闡述部分功能可能會導致需要對整個系統進行徹底的返工。 作者指出了當想法錯誤時過度闡述的風險。
為了消除風險，需要快速接收正在創建的產品的回饋，以最大程度地減少創建「錯誤」產品的損害。 我們繪製了這個想法的草圖 - 與用戶驗證它，繪製了介面原型 - 與用戶驗證它，等等。 （另外，還有一些關於如何驗證程式原型的資訊）。 創建軟體的目標，特別是在初始階段，是透過接收快速回饋來學習；因此，創建的第一個產品是能夠證明或反駁假設的草圖。 （作者參考了 Eric Ries 的著作“Startup using Lean method”）。
當跨多個團隊進行實施時，故事地圖有助於改善溝通。 地圖上應該有什麼？ 您需要什麼才能讓對話繼續下去。 不只是使用者故事（誰、什麼、為什麼），還有想法、事實、介面草圖等等…
透過將歷史地圖上的卡片劃分為幾條水平線，您可以將工作劃分為多個版本 - 突出顯示最低限度的內容，一層不斷增加的功能和鞠躬。
我們在流程圖上講故事。
一名員工來吃午餐。
他想要什麼？ 服務速度。 這樣他的午餐就已經在桌上或至少在托盤上等著他了。 哎呀 - 錯過了一步：員工想吃東西。 他登入並選擇了商務午餐選項。 他看到卡路里含量和營養成分可以幫助他節食而不增加體重。 他看了這道菜的照片決定是否要去那個地方吃。
接下來，他會去吃午餐和晚餐嗎？ 或者也許午餐會送到他的辦公室？ 然後該過程的步驟是選擇吃飯的地方。 他想看看什麼時候能送到他手上，要花多少錢，這樣他就可以選擇把時間和精力花在哪裡——下樓還是去上班。 他想看看咖啡館有多忙，以免排隊。
隨後，這名員工來到了咖啡館。 他想看看他的托盤，這樣他就可以拿著它直接去吃晚餐。 咖啡館想收錢，透過服務賺錢。 員工希望在與咖啡館的結算上損失最少的時間，以免無用地浪費寶貴的時間。 怎麼做？ 遠端服務後提前付款或反之亦然。 或使用自助服務終端當場付款。 這其中最重要的是什麼？ 有多少人願意用銀行卡支付午餐費用？ 有多少人會相信這家食堂會儲存他們的卡號以便重複付款？ 如果沒有實地研究，還不清楚，需要進行測試。
在這個過程的每一步，你都需要以某種方式提供功能；為此你需要以某個人為基礎並選擇對他來說更重要的東西（同樣的三個選擇器）。 將故事進行到底=提出了可行的解決方案。
接下來是細節處理。 顧客想看看咖啡館有多忙，以免排長隊。 他到底想要什麼？
看看他到的時候15分鐘後會有多少人的預測
提前半小時查看咖啡館平均服務時間及動態
查看情況和餐桌佔用動態
如果預測系統給的結果不明確或停止運作怎麼辦？
透過影片觀看咖啡館裡的隊列以及桌子的佔用情況。 嗯，為什麼不先這樣做呢？
作者指出了一個可以練習的小練習：試著想像一下早上起床後你做了什麼。 一張卡=一個行動。 放大卡片（不是磨咖啡，而是喝提神飲料）以消除個別細節，重點不在於實施方法，而在於目標。
本書的讀者對像是：IT 分析師和專案經理。 必讀。
應用程序
3 至 5 人小組的討論和決策是有效的。
在第一張卡片上寫下需要改進的內容，在第二張卡片上寫下您在第一張卡片上所做的事情，在第三張卡片上寫下您在第一張卡片和第二張卡片上所做的事情。
準備故事就像準備蛋糕一樣——不是寫出食譜，而是找出蛋糕適合誰、適合什麼場合以及有多少人。 如果我們細分銷售，那麼它就不是蛋糕、奶油等的生產，而是小成品蛋糕的生產。
軟體開發類似拍電影，在拍攝前需要仔細開發和打磨劇本、組織場景、演員等。
資源永遠都會短缺。
20% 的努力會產生切實的結果，60% 會產生難以理解的結果，20% 的努力是有害的 - 這就是為什麼專注於學習而不是在出現負面結果時絕望的原因很重要。
直接與用戶溝通，設身處地為用戶著想。 重點關註一些問題。
詳細和發展故事進行評估是scrum中最沉悶的部分，讓討論以水族箱模式站立起來（3-4人在董事會討論，如果有人想參加，他就替換某人）。
來源： www.habr.com