对于软件开发而言，用户故事地图是一个很有价值的工具，但前提是你必须明白它的用途和正确用法。用户故事地图很容易被误解和误用，因此，本书深入解释了如何用它来帮助团队始终聚焦于用户及其需求，而不是热衷并痴迷于单个炫酷的产品特性而迷失方向。

作者Jeff Patton展示了用户故事的种种用法，力求帮助团队在整个开发过程中始终围绕着项目展开更好的互动交流。通过这样的对话，团队最终能对构建怎样的产品及其能够用户带来怎样的价值和体验达成共识。这样的共识是打造一流产品的前提。

俯瞰用户故事地图，通过适当的练习来掌握相关的关键性概念。

领悟故事是如何实际发挥效用的？在敏捷和精益项目中，如何从故事中挖掘真正的需求

探究一个故事的生命周期，从各种可能的机会入手，步步深入，发现有价值的需求。

准备故事，关注其产生过程，从中了解可以转换为特性的需求，打磨出一流的软件产品。

　　用户故事地图作为一种有效的需求工具，越来越广泛地应用于开发实践中。《用户故事地图》以用户故事地图为主题，强调以合作沟通的方式来全面理解用户需求，涉及的主题包括怎么以故事地图的方式来讲用户需求，如何分解和优化需求，如果通过团队协同工作的方式来积极吸取经验教训，从中洞察用户的需求，开发真正有价值的、小而美的产品和服务。
　　《用户故事地图》适合产品经理、用户体验设计师、产品负责人、业务分析师、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的悲剧
边讲边记
创意框架
刻画用户画像
讲用户的故事
探索细节和可选项

第2章 计划，为了更少的开发
故事地图帮助大型组织建立共识
创建故事地图的过程可以帮助发现设计中的坑
要做的总是太多
划分MVP发布计划
划分发布路线图
为成果排列优先级，而非功能
这是魔法吗？没错
为什么要反复讨论MVP
MVP根本就不是产品

第3章 计划，为了更快的学习
从讨论机会开始
验证问题
在设计原型过程中学习
要能够质疑用户所说的内容
在开发过程中学习
迭代直至可行
错误的做事方式
基于验证的学习
真正的最小化试验
重点复述

第4章 计划，为了按时发布
要让团队所有成员都清楚
估算的秘密
制定可逐步达成的开发计划
不要将所有的迭代产出都对外发布
关于估算的另外一些秘密
管理研发预算
迭代与增量
开局、中局和末局策略
……
第5章 如何创建故事地图
第6章 用户故事的故事
第7章 如何把故事讲得更好
第8章 不要把所有内容都写在卡片上
第9章 卡片只是个开始
第10章 做产品好比烤蛋糕
第11章 碎石行动
第12章 谁是碎石负责人
第13章 从机会开始
第14章 通过探索来建立共识
第15章 通过探索来进行验证性学习
第16章 提炼、定义和开发
第17章 故事呢，就好比《行星战机》
第18章 开发完成后怎么学习
结语

　　抱歉让大家久等了。初次接触用户故事地图时，大概是2010年，当时我就职于中兴通讯无线研究院，在部长俞胜兵博士和公司技术部敏捷转型负责人杨静女士的支持下，我和Thoughtworks的咨询师一起工作，帮助中兴做组织级敏捷转型。在一个偶然的机会，得到Jeff Patton写于2009年的胶片文件User Story Mapping，如获珍宝，感慨Jeff居然能够用如此简洁优雅的方式来解决产品设计和需求管理这一软件开发难题。当时国内企业引入敏捷方法的主流模式是Sc ru m+XP，分别解决管理实践和工程实践两方面的问题。故事一般都从产品待办列表（PB，Product Backlog）开始，或者加上一些PB梳理方法来解决PBI （Product Backlog Item）如何产生的问题。作为推动公司敏捷转型的四位成员之一，自然会被问及整个故事如何发端的问题，即产品待办列表是如何产生的，我对梳理方法进行实践和思考，得出的结论总是无法让自己满意。这个问题困扰我很久，直到看到Jeff的这份胶片。用户故事地图方法的起源可以向前追溯到2005年，Jeff在他的文章How You Slice It中介绍了用户故事地图方法的原型．当时还没有对这个方法命名，但是作为一名咨询师，Jeff已经用这种方法帮助客户解决了如何设计出用户需要的产品并制定合理的迭代计划来实现它。2010年左右，我开始关注Mad Mimi，因为Jeff在讲用户故事地图的时候，总要亮出他在Mad Mimi办公室拍的“度假照片”，Gary笑容可掬地半蹲在铺满故事卡的地板上。因为在临近资金消耗殆尽之前，他在Jeff的帮助下通过用户故事地图方法发现了真需求，此后逐步打磨出一款极简、极受客户欢迎并乐于付费的产品，取得了商业上的成功。而此前他花大钱开发出来的功能，竟然没有一个是用户需要的。要知道，Gary火2007年开始创业，直至2014年8月被GoDaddy收购，期间没有拿过VC-分钱，当时承受的压力可想而知。2015年4月Mad Mimi和GoDaddy整合后成功上市，市值超过40亿美金。2012年，我离开中兴通讯加盟百度敏捷教练团队，开始做距离用户更近的产品，也开始尝试在团队中引入用户故事地图方法，并且把这一方法介绍给百度敏捷教练团队的同学。《百度论语》中有一条叫“问题驱动”，即我们的每一步都应该推动问题得到进一步解决，所以百度敏捷转型的历程跟国内其他企业有些不同，一切都以解决业务问题为中心，方法论的声音相对微弱，尽管取得了非常好的成效，但是用户故事地图方法并不为大家所熟知。机缘巧合， 《用户故事地图》英文版刚放出样张，我就检索到并联系上清华大学出版社，表达了翻译的意愿。恰巧此时，出版社也刚刚谈好版权。于是，双方迅速敲定，新的项目开始动工。然而，翻译后期进展比较缓慢。团队分布在北京、上海、深圳三地，出差是我的常态，加之工作上的一些变化，本来可资利用的周末和晚上也变得很稀缺。幸好有京东好青年振东及时出手，担纲后面8章的翻译，到2015年12月，整本书终于收尾。此时距离Jeff那篇文章How You Slice It已经有10年时间，距离我2006年翻译《移动计算原理》也有小10年时间。2016年1月，在各地敏捷之旅社区的邀请下，我在北京、上海、杭州分别做了三场为期半天的“用户故事地图实战工坊”，期待用户故事地图方法可以在更多企业落地并激发出强大的活力与生命力。如果说这本书有适用人群的话，我觉得最适合的莫过于正在采用敏捷开发的团队成员，尤其是深感自己陷于敏捷开发泥潭的产品经理和团队负责人。感谢我的妻子蔺妍，在她的精心操持下，家已经是我在困难时候的精神支柱。