編輯推薦

　　對於軟件開發而言，用戶故事地圖是一個很有價值的工具，但前提是你必須明白它的用途和正確用法。用戶故事地圖很容易被誤解和誤用，因此，本書深入解釋瞭如何用它來幫助團隊始終聚焦於用戶及其需求，而不是熱衷並癡迷於單個炫酷的産品特性而迷失方嚮。
　　作者JeffPatton展示瞭用戶故事的種種用法，力求幫助團隊在整個開發過程中始終圍繞著項目展開更好的互動交流。通過這樣的對話，團隊最終能對構建怎樣的産品及其能夠用戶帶來怎樣的價值和體驗達成共識。這樣的共識是打造一流産品的前提。
　　俯瞰用戶故事地圖，通過適當的練習來掌握相關的關鍵性概念。
　　領悟故事是如何實際發揮效用的？在敏捷和精益項目中，如何從故事中挖掘真正的需求
　　探究一個故事的生命周期，從各種可能的機會入手，步步深入，發現有價值的需求。
　　準備故事，關注其産生過程，從中瞭解可以轉換為特性的需求，打磨齣一流的軟件産品。

內容簡介

　　用戶故事地圖作為一種有效的需求工具，越來越廣泛地應用於開發實踐中。本書以用戶故事地圖為主題，強調以閤作溝通的方式來全麵理解用戶需求，涉及的主題包括怎麼以故事地圖的方式來講用戶需求，如何分解和優化需求，如果通過團隊協同工作的方式來積極吸取經驗教訓，從中洞察用戶的需求，開發真正有價值的、小而美的産品和服務。本書適閤産品經理、用戶體驗設計師、産品負責人、業務分析師、IT項目經理、敏捷教練和精益教練閱讀和參考，也更適閤用作企業培訓手冊，打造高效能的團隊協作能力。

作者簡介

　　Jeff Patton，在過去二十多年的經曆中，Jeff Patton得到一個教訓：雖然設計和構建軟件的正確方式並不隻有一種，但錯誤的更是多得數不勝數。Jeff有十五年豐富的産品經驗，做過網上飛機零件預定和電子病曆卡等，主要是幫助客戶組織改進工作方式。在很多開發流程都隻著眼於交付速度和效率時，Jeff早已經在此基礎上同時兼顧交付具有非凡價值並且能獲得市場成功的軟件産品。早在2000年，Jeff加入一個早期的極限編程團隊以來，就一直專注於敏捷方法，尤其專長於把有效用戶體驗設計和産品管理實踐融入紮實的工程實踐當中。目前，Jeff的身份是獨立顧問、敏捷過程教練、産品設計過程教練和導師。他針對敏捷産品管理各個主題所發錶過的文章、隨筆和PPT都可以從agileproductdesign.com和Alistair Cockburn的Crystal Clear找到。Jeff是敏捷-使用性雅虎討論小組的創辦人和協調人，StickyMinds.com和IEEE Software的專欄作者，CST（Certified Scrum Trainer），敏捷聯盟2007 Gordon Pask奬的獲得者。

　　李濤，花名“大桃”（微信號：whoistony），百度資深敏捷教練、高級架構師，現為百度用戶産品體係內部顧問團隊負責人。2012年加入百度，一直工作在移動互聯網、LBS、O2O産品敏捷轉型的第一綫，積纍瞭業務與敏捷結閤的豐富經驗。帶領團隊輔導百度地圖、百度團購、百度導航、百度旅遊等産品的敏捷轉型工作，取得顯著成效。2014年負責百度糯米的産品研發融閤和敏捷轉型工作。

　　嚮振東，花名“阿東”（微信號：jedheong），北京師範大學心理學碩士，目前就職於京東，專門從事用戶研究和數據分析相關工作。對用戶體驗研究和項目管理領域的翻譯與交流很感興趣，目前也是UXRen翻譯組管理員。

精彩書評

　　“在我接觸過的人當中，幫助正規軟件開發團隊真正深入洞察其需求和價值迴報的敏捷專傢當中，隻有少數幾個人稱得上實至名歸。Jeff Patton算一個。”
　　——Marty Cagan，Silicon Valley Product Group閤夥人

目錄

Martin Fowler序
Alan Cooper序
Marty Cagan序
前言
緻謝 .
使用前必讀
第1章 産品全景圖
讓我們從頭開始
故事是講齣來的，不是寫齣來的
講故事，要完整
Gary的悲劇
邊講邊記
創意框架
刻畫用戶畫像
講用戶的故事
探索細節和可選項
user_story_mapping-table.indd 5 16-3-15 下午3:43
vi ｜ 目錄
第2章 計劃，為瞭更少的開發
故事地圖幫助大型組織建立共識
創建故事地圖的過程可以幫助發現設計中的坑
要做的總是太多
劃分MVP發布計劃
劃分發布路綫圖
為成果排列優先級，而非功能
這是魔法嗎？沒錯
為什麼要反復討論MVP
MVP根本就不是産品
第3章 計劃，為瞭更快的學習
從討論機會開始
驗證問題
在設計原型過程中學習
要能夠質疑用戶所說的內容
在開發過程中學習
迭代直至可行
錯誤的做事方式
基於驗證的學習
真正的最小化試驗
重點復述
第4章 計劃，為瞭按時發布
要讓團隊所有成員都清楚 .
估算的秘密
製定可逐步達成的開發計劃
不要將所有的迭代産齣都對外發布
關於估算的另外一些秘密
管理研發預算
迭代與增量
開局、中局和末局策略
user_story_mapping-table.indd 6 16-3-15 下午3:43
目錄 | vii
根據開發策略切分故事地圖
都是關於風險
“劇透”第5章主題
第5章 如何創建故事地圖
1. 分步驟寫齣你的故事
2. 組織情節
3. 探索替代故事
4. 提取故事地圖的主乾
5. 切分齣能幫你達成特定目標的任務
就是這樣簡單！你已經學會瞭所有重要概念
請在傢裏或者辦公室裏練習
這張地圖是現在的，不是將來的
實操案例
練習容易，落地難
故事地圖僅僅隻是個開始
第6章 用戶故事的故事
Kent Beck的創意
簡單的事情並不一定容易做到
Ron Jeffries的3C原則
文字和照片
小結
第7章 如何把故事講得更好
Connextra公司的用戶故事模闆
模闆僵屍和萬能犁
提升討論效果的檢查單
創建度假照片
需要操心的事情還多著呢
第8章 不要把所有內容都寫在卡片上
不同角色，各有所需
user_story_mapping-table.indd 7 16-3-15 下午3:43
viii ｜ 目錄
我們需要一張更大的故事卡
信息輻射器和信息冰箱
錯誤的工具和錯誤使用工具
第9章 卡片隻是個開始
在頭腦中構建清晰的圖像
養成口述用戶故事的習慣
檢視産齣
你又不是用戶
開發過程就是學習的過程
不僅僅是軟件
為學習做計劃，學習如何做計劃
第10章 做産品好比烤蛋糕
食譜
切分大蛋糕
第11章 碎石行動
故事的大小很重要
把故事比喻為石頭
史詩故事是大石頭，有時可以用來攻擊他人
用主題來組織故事
忘掉這些術語，專注於講故事
從機會開始
探索最小可行方案
在交付階段深入每個故事的細節
在開發過程中保持日常對話
評估每一份産齣
與用戶和客戶一起評估
與業務乾係人一起評估
發布和持續評估
user_story_mapping-table.indd 8 16-3-15 下午3:43
目錄 | ix
第12章 誰是碎石負責人
有價值的-可用的-可行的
一個成功的探索團隊需要更多的人參與
神勇三蛟龍
産品負責人好比音樂製作人
這項工作並不簡單
第13章 從機會開始
針對機會展開對話
深入挖掘機會，丟棄機會或思考機會
機會不應該是一種委婉的說法
故事地圖和機會
挑剔
第14章 通過探索來建立共識
探索不是開發軟件
探索的4個核心步驟
探索活動、討論和工件
探索的目的是建立共識
第15章 通過探索來進行驗證性學習
大多數時候，我們其實都是錯的
糟糕的往事
同理，聚焦，形成想法，製作原型，測試
如何把好事弄糟
短期驗證學習循環
精益創業思想改變産品設計
故事和故事地圖呢
第16章 提煉、定義和開發
卡片，對話，更多卡片，更多對話……
細分和提煉
故事工作坊
user_story_mapping-table.indd 9 16-3-15 下午3:43
x ｜ 目錄
在衝刺或迭代計劃階段開展故事對話
人人參與並非明智之舉
分解和瘦身
如何在交付階段使用故事地圖
如何使用故事地圖來可視化進展
在故事工作坊中使用簡易地圖
第17章 故事呢，就好比《行星戰機》
把碎石子兒重新聚集起來
地圖繪製要適度
韆萬不要小題大作
第18章 開發完成後怎麼學習
團隊迴顧
和團隊外的角色一起迴顧
夠用
嚮用戶學習
從發布中學習
預定計劃中的結果
使用故事地圖來評估發布是否準備就緒
結語

前言/序言

還沒看 又囤書瞭……應該不錯吧

書本內容很有啓發，語言通俗易懂

書還沒看，質量不錯，活動價格給力

??敏捷軟件開發（原則模式與實踐）[特例商品不參加每滿100減50促銷] ??敏捷軟件開發（原則模式與實踐）[特例商品不參加每滿100減50促銷]

本來提示是18號到，結果17號晚上就送到瞭，這麼快的速度還有啥說的。

正品，快遞很快，質量非常好，價格實惠。

哦哦哦哦哦哦哦哦哦哦哦哦哦哦

非常好，非常好，非常好，非常好，非常好

哦，還可以 哦，還可以 哦，還可以 哦，還可以