用户故事地图
批量上传，套装书可能不全，下单前咨询在线客服！有特殊要求，下单前请咨询客服！
￥ 31.2 4.5折 ￥ 69.8 全新
库存133件
江西南昌
认证卖家担保交易快速发货售后保障
作者Feff，Patton著，李涛 著
出版社清华大学出版社
ISBN9787302429944
出版时间2016-04
装帧平装
开本16开
定价69.8元
货号29486354
上书时间2024-11-03
![“机械基础件、基础制造工艺和基础材料”系列丛书：机械基础件标准汇编[ 法兰]](https://www0.kfzimg.com/sw/kfz-cos/kfzimg/bafdfaae/ae1f3c2894506102_s.jpg)
商品详情
- 品相描述：全新
- 商品描述
-
导语摘要
作者简介
作者介绍
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展示了用户故事的种种用法，力求帮助团队在整个开发过程中始终围绕着项目展开更好的互动交流。通过这样的对话，团队最终能对构建怎样的产品及其能够用户带来怎样的价值和体验达成共识。这样的共识是打造品质产品的前提。
俯瞰用户故事地图，通过适当的练习来掌握相关的关键性概念。
领悟故事是如何实际发挥效用的？在敏捷和精益项目中，如何从故事中挖掘真正的需求
探究一个故事的生命周期，从各种可能的机会入手，步步深入，发现有价值的需求。
准备故事，关注其产生过程，从中了解可以转换为特性的需求，打磨出品质的软件产品。
精彩内容
Martin Fowler序
敏捷软件开发运动的兴起为软件行业带来了诸多积极的变化，大型需求要进行拆分，这
个意识的建立便是其中之一。切分后的需求称为“故事”（story） ，故事的使用使得软
件开发项目的过程进一步可视化。通过故事方式来组织开发的产品，每一个故事实现都
和整个软件接近集成，每个人都可以看到产品在不断成长。用户也可以理解故事，开发
者通过决定下一个迭代开发哪个故事来管理软件开发项目。可视化程度的大幅提升，使
得用户可以深入参与到项目中来，而不是像以前那样需要等上一年甚至更久时间才能拿
到开发完成的新特性。
需求拆分本身也有很多负面影响，容易丢失软件系统全景图（whole picture）便是其中
之一。开发工作进展到后期，你可能得到的是一堆无法拼接在一起的碎片。也可能由于
过度陷入细节而丢掉用户诉求的本质，最终构建出用户不需要的产品。
故事地图是一门在需求拆分过程中保持全景图的技术。
如果要用一句话来诠释本书的话，非上面这句话莫属了，这句话本身就很有价值。全景
图可以帮助团队和用户有效的沟通，帮助参与其中的人避免开发非必要的特性，也为一
致的用户体验提供了基准。当我询问ThoughtWorks（思特沃克）的同事如何开发用户故
事时，他们最常提到的核心技术就是用户故事地图。这些ThoughtWorks同事也是在Jeff
（杰夫）的工作坊学到这门技术的，因为Jeff开发了故事地图，也只有他能把故事地图
讲到如此淋漓尽致的程度。Jeff写这本书正是为了帮助读者直接从源头学习这门技术。
但是，这本书并非单是为那些名片印着产品经理、业务分析师头衔或者在线简历中写着
产品经理头衔的人而写的。在采用功能敏捷开发方法的十年中，最让我失望的一点是，
程序员把故事当作和产品经理之间进行沟通的单行道。在最开始的时候，故事的目的是
激发沟通中的火花。要想开发出能有效支撑用户活动的软件，就需要求助于开发软件中
最关键的角色，因为只有程序员最清楚软件可以做什么。程序员需要理解用户想要达成
的目标，需要在前期捕获用户需求的阶段就参与进来，一起开发故事。懂得故事地图技
术的程序员能更好地理解用户上下文，在软件成形期间更好地参与进来，从而取得更好
的工作成果。
Kent Beck（肯特?贝克，最早提出用户故事概念的人）发展了自己在软件开发方面的
理念，他呼吁团队把沟通作为高效团队的核心价值。故事，是程序员和其他角色沟通中
的推荐要素，故事地图对这些要素组织为结构化，以此来强化软件开发中最关键的部
分——沟通。
——Martin Fowler（马丁?福勒）
2014年6月18日
Alan Cooper序
在Mary Shelley（玛丽?雪莱）的有名科幻小说《科学怪人》中，疯狂的弗兰肯斯坦博
士用尸体碎片创造了一个生命，那时候电力还被视作一项新技术，弗兰肯斯坦博士用电
力给生物注入生命。当然，这只是小说中的情节，在现实世界中使用尸体碎片创造生命
实际上根本就不可能。
然而在软件开发中，我们一直在试图这样做。在软件中堆砌一个又一个新功能，然后陷
入“为什么没有多少用户喜欢这个产品”的困惑中。这个谜题的核心在于开发人员将工
程方法作为了设计工具，实际上两者不是一回事儿。
程序员逐个开发特性是接近合情合理的，并且经过数年验证是一个行之有效的策略。同
样经过数年验证的是，设计软件产品的行为和范围时，也遵循逐个进行的方式，这就有
点像科学怪人的做事方式了。
尽管有相通之处，设计软件行为和开发软件的实践之间其实有明显的不同，主要原因在
于这两件事是由不同技能特长的人来承担的。像交互设计师那样花好几个小时的时间观
察用户行为和提取行为模式，这样的工作会让程序员抓狂。而像程序员那样花好几个小
时研究算法，对大多数设计师而言也同样难以忍受。
但是，当设计和开发两类工作产生协同的时候，就会像弗兰肯斯坦所使用的电力一样，
能够创造出有生命的产品。团队协作为产品注入生命力，并让用户也爱上它。
虽然协作本身并不是什么新概念，但要做到高效协作实际上确实十分困难。程序员工作
的节奏、语言和交互设计师之间有很好大的差别。
程序员和设计师在各自的领域中都很好专业、精干，都有自己的工作规范，同时他们又
有着共同的弱点。设计问题是很难用开发术语来描述的，同样，开发难题也难以使用设
计术语来说明白。这对姊妹学科之间缺乏共同的语言，而连接两者恰恰是Jeff Patton（杰
夫?帕顿）所擅长的。
Jeff的用户故事地图方法能够为程序员所理解，同样也可以为设计师所理解。用户故事
地图就像数字时代的罗塞塔石碑（Rosetta Stone）。
撇开业界对敏捷的成见，敏捷软件开发方法本身也不见得是一种良好的产品设计方法。
敏捷开发是一种很好的思维方式，可以使设计方案更顺利地交付，却无法产出能让用户
喜爱的产品。换句话说，我们看到过不少很好的设计，文档完成后交给开发人员，不管
是敏捷开发还是非敏捷开发，设计的核心理念在实现过程中都会被抹杀掉。
Jeff Patton的用户故事地图方法是连接开发和设计的桥梁。交互设计的核心是发现用户行
为并像讲故事一样把它们描述出来。软件开发则是将这些描述拆分、实现并集成到产品
中。在这个复杂的过程中，设计的核心理念很好容易丢失。是的，就像是手术失败，所
有的规定操作都做完，病人最后却死在手术台上。
通过用户故事地图的方式来处理用户故事，设计仍然保持其叙事结构，开发工作也可以
得到很好的分解从而得以高效实现。设计师的方案以规范化的用户故事形式描述，在开
发过程中流动并保持其完整性。
在传统公司中已经证实，以两三百人规模的团队，要开发出能让用户喜爱的产品几乎是
不可能的。而创业社区则证实，四五个人组成的创业团队可以开发出能让人们喜爱的小
产品，即使这些小产品也会最终随着规模变大而失去光芒。我们面对的挑战是如何创造
出用户喜爱的大型软件产品。大型软件产品用户群广，并且用户从事的是复杂的商业活
动。想把这样的软件做得有趣并且简单易学，是很好困难的。
要想避免将大型软件产品开发成“科学怪人”，专享的方法是学习如何充分协调好产品
设计和软件开发。在这方面，没有人比Je ff Patton做得更好。
——Alan Cooper（艾伦?库珀）
2014年6月17日
Marty Cagan序
我的职业生涯很好幸运，因为我一直有机会和世界很好的许多产品技术团队合作。他们
创造出用户很好喜爱，并且每天都在使用的产品。这些团队正在改变世界。
我也曾经受命前往帮助一些做得不那么好的公司。创业团队努力在钱烧完之前找到新的
投资。大公司则挣扎于复制早期的成功。团队无法持续为业务贡献价值。主管则为新想
法何时才能上线操碎了心。工程师对产品经理满腹怨言。
在这个过程中，我认识到很好产品公司在软件设计开发上和普通公司之间存在巨大的差
别。从主管行为到团队授权级别；到团队协作的方式；到组织在投资、招聘和产品开发
方面的思考；到文化；再到产品、设计、开发如何协作共同发现对客户行之有效的解决
方案。
这本书的题目是用户故事地图，但仔细阅读之后，你会发现这本书的内容并不局限于故
事地图这一强有力却看似很简单的技术上。这本书更多讲述团队如何沟通、协作并最终
交付好的产品。
大部分人是没有机会近距离观察一个强大的产品团队是如何运作的。读者能够了解的更
多是自己公司以及前东家是如何运作的。所以接下来我会帮助大家来识别很好产品团队
和普通团队之间的差别。
我很好赞同Ben Horowitz（本?霍罗威茨）的文章“好的产品经理和差的产品经理”中的
观点，下面借用其形式，初步探讨一下好的产品团队和差的产品团队之间的主要不同。
好的团队，有引人入胜的产品愿景，怀着传教士般的热忱在工作。差的团队，像是
由雇佣兵组成的，当一天和尚撞一天钟，靠混的。
好的团队，从关键业务指标得到启发，通过观察用户的痛点和分析用户使用过程中
产生的数据，不断尝试新技术解决现实问题。差的团队，从销售人员和用户那里收
集需求。
好的团队，理解谁是主要干系人，干系人所受的约束，承诺引入解决方案，方案对
用户和客户有用，同时也满足业务上的约束条件。差的团队，只知道从干系人那里
收集需求。
好的团队，掌握大量的技术手段，这些技术手段可以快速验证哪些产品创意是值得
开发的。差的团队，召集会议来制定路标和排列优先级。
好的团队，喜欢和公司内有想法的主管展开头脑风暴和讨论产品。差的团队，在团
队之外的人胆敢提议他们做任何事的时候，会觉得自己受到了冒犯。
好的团队，产品经理、交互设计师和开发工程师坐在一起，对功能、用户体验、技
术可行性达成一致见解。差的团队，各自坐在小格子间里，没有文档和会议安排，
就不会主动响应其他人的请求。
好的团队，持续尝试新想法以求创新，过程中会注意保护公司利益和品牌。差的团
队，仍然坐着等待开始尝试的指令。
好的团队，对于创造出成功产品所需的技能很有信心，比如强大的交互设计能力。
差的团队，甚至压根儿就不知道交互设计为何物。
好的团队，保证开发工程师每天有时间参与产品原型的讨论，为做好产品献计献
策。差的团队，在迭代计划会上展示原型，一心只为了估出工作量。
好的团队，每周直接和用户交流，以更好地理解用户诉求，并试探用户对近期新的产
品创意的反馈。差的团队，以为他们自己就能代表用户。
好的团队，清楚地知道尽管他们很喜欢自己在产品上的创意，但这些创意中的很大
一部分用户并不见得会接受，即使有一些被用户接受了，也需要经过多个迭代的打
磨才能达到预期的效果。差的团队，只开发路标上规划的内容，能按时交付，只求
不出重大质量问题就阿弥陀佛。
好的团队，理解速度和快速迭代对于产品创新的价值，更知道速度来自于正确的方
法，而非强制加班。差的团队，抱怨同事工作不够努力，速度太慢。
好的团队，在评估方案，确认可行并对用户和业务有实际价值后，共同做出承诺。
差的团队，抱怨自己公司是一个受销售驱动的公司。
好的团队，使用工具，以便快速了解用户是如何使用产品的，并基于数据做出判
断。差的团队，认为统计分析是可有可无的。
好的团队，持续集成和发布产品，因为他们知道持续的小发布能为用户提供了稳定
可靠的解决方案。差的团队，在经过痛苦的集成联调之后，手工测试，一次性发布
所有功能。
好的团队，专注于用户。差的团队，专注于竞品。
好的团队，在关键业务目标重大影响达成后庆祝。差的团队，在终于发布产品之后
庆祝。
我已经意识到读者会困惑，上面所提到的这些东西和用户故事地图有什么关系呢？我知
道你会感到惊讶。这恰恰就是我成为故事地图铁杆儿粉丝的原因。
在我接触过的敏捷专家中，真正有能力帮助产品团队提升产品研发能力水平的并不多，
Jeff Patton便是其中之一。我观察了Jeff在产品发现（Product Discovery）阶段亲自动手
和团队一起工作的场景。我也把他介绍给公司，因为他做事很好高效。团队也很喜欢
他，因为他不但知识丰富，人也很好幽默。
产品经理都聚到一起写需求文档，交互设计师忙于为产品进行涂脂抹粉般的设计，工程
师躲在地下室写代码，这样的日子在很好团队中早已经销声匿迹。现在，是时候把这些
现象清出你的团队了。
——Marty Cagan（马蒂?卡根）
2014年6月18日
前言
Live in it, laugh in it, love in it/Removes embarrassing,
stains from contour sheets,that's right/And it entertains visiting,
relatives, it turns a sandwich into a banquet
——Tom Waits, “Step Right Up”
这本书本来是想做成一本小……小……小册子的，真的。
我打算写一个简单的实践，我称之为“用户故事地图”。除我本人之外，还有许多人使
用类似方法，通过构造简单的故事地图来使产品使用过程中的用户体验图形化和可视
化，从而提升团队的协同效率。
故事地图可以使我们专注于用户和用户体验，
产生更好的沟通效果，最终做出更好的产品。
做故事地图这件事真的简单得要命。和其他人一起工作，一个人来讲产品的用户故事，
一边讲一边把故事中用户经过的重要步骤记录在便签上，并按照从左到右的顺序水平排
user_列。然后，回过头来讨论每个步骤的细节，在便签上记下讨论的细节，在每个步骤下面垂直排列。结果得到一个简单的网格结构，从左到右讲述故事，自顶向下拆分细节。这
样做快速而有趣。这些细节故事为敏捷开发项目提供了更好的待办列表内容。
既然这样简单，为何要劳神费力整一本书出来呢？
即便是如此简单的事情，有时候也会让人很困惑。光是写写想要构建故事地图的原因，
在构建过程中会发生的事情以及故事地图的好多种不同使用方法，就会占去不少的篇
幅。这本书中需要写的与这个简单实践相关的内容，比我起初预想的多得多。
如果你正在使用敏捷开发过程，想必也是使用用户故事来填充待办列表的。过去我只是
假设用户故事是一个普通的实践，认为在书里阐述用户故事是浪费墨水的事情。但是，
我错了。自Kent Beck抢先发售提出用户故事以来，已经有十五个年头，用户故事比以前更流
行，也更普遍被错误理解和错误使用。这让我很沮丧，更重要的问题是，这也抹杀了我
们能从用户故事地图中获得的收益。
所以，在这本书中我会尽优选努力来纠正在敏捷和精益软件开发中关于用户故事的错误
理念。这就是我写这本书的初衷。就像Tom Waits在歌词中写的那样，就这样把三明治办
成了一场宴会（it turns a sandwich into a baquet）。
为什么是我
我喜欢折腾，乐于看到用户使用我开发的软件并从中获益。这种乐趣一直激励着我。成
为一个方法论专家并非我的本意。但学习流程和实践如何结合发挥作用以产生更好的结
果，进而传授给别人，确实是我在软件开发行业学习了二十多年才做到的。我也知道教
的东西一直在变化。我对故事地图的理解每个礼拜都在变，对这种理解的很好阐述，也
和我的理解一样变得快。如此种种，让我好几年都没法子静下心写书。
但是，现在时机到了。
用户故事和故事地图都是很好棒的主意，许多人从中受益，他们的生活更好，产品也更
受欢迎。尽管有人受益于生活变好，然而更多的人还挣扎在用户故事之中，我总不能坐
视不管吧。
我所能做的，就是写这本书。如果这本书能够改善他们的工作和生活，哪怕一点点，我
都会感到很欣慰。
谨以此书献给那些还在用户故事中挣扎的人
越来越多的组织采用敏捷和精益开发流程，同时也采用用户故事，所以可能会因为对用
户故事的曲解而落入如下陷阱之中。
?用户故事聚焦于构建小特性，很容易“只见树木不见森林”。开发出来的产品由彼
此不匹配的部分拼凑而成，在用户看来，这样的产品就像是疯狂博士的作品“科学
怪人”。
?在开发大型产品的时候，逐个开发小特性会让人们不知道整个产品何时能够完成开
发和发布。团队中的工程师也会有同样的困惑。
?用户故事强调沟通，于是不写任何文档。这会导致大家忘记在沟通中讨论的内容和
达成的共识。
?好的用户故事要有验收条件，以至于只专注于写验收条件，却对要做什么缺乏一致
的理解。结果，团队无法在计划的时间点完成交付。
?好的用户故事是从用户角度来描述的，然而系统中有大量不与用户产生直接交互的
部分，团队成员认为产品没有用户，用户故事并不适用。
?如果你曾经落入上述任何一个陷阱，那么接下来对误解的澄清就会对你有所帮助。你也
可以从中学习如何从全局开始思考，如何在项目中进行估算，如何就用户目标组织进行
高效的沟通，如何开发一个能解决用户问题的好的（产品）特性。
谁需要读这本书
你当然需要！特别是你刚刚买了这本书，我认为购买这本书是一个明智的投资决定。如
果你是从别人那里借的这本书，现在是时候买一本，等新书到手之后赶紧把借的书还回
人家。
不同的角色阅读这本书都可以获得独特的收益。
?对于产品经理和用户体验设计师，阅读这本书可以帮助他们弥补完整的产品用户体
验和项目计划之间的鸿沟。如果你正纠结于产品愿景和开发细节，或正在努力帮助
其他人理解用户和体验，或正在苦苦寻求用户体验和产品设计方法，在工作中尝试
精益创业方法，用户故事地图都可以帮到你。
?产品负责人、业务分析师和IT项目经理应该读这本书，帮助他们消除内部用户、干
系人和工程师之间的鸿沟。如果你苦于如何说服干系人，希望他们可以对产品达成
一致的理解，或者你正努力帮助工程师理解全景图，故事地图都可以帮到你。
?帮助团队和个人提升能力的敏捷教练和精益教练应该读一读这本书。如果你已经开
始读了，回忆一下公司成员对用户故事的错误理解吧。遵循本书内容，使用用户故
事做简单的练习，这本书介绍的实践可以帮助你的团队提升能力。
?其他任何角色。在使用敏捷过程的时候，会有产品负责人或者业务分析师这样的角
色，这些角色在需求管理上要投入大量的精力，能否高效使用用户故事取决于大家
?是否都具备基础的背景知识。如果大家不了解基础的背景，就会质疑用户故事没写
好或者认为需求粒度过粗，细节不清晰。读完这本书之后，你会发现用户故事并不
只是一种更好的需求撰写方式，而是一种组织更有效的沟通方式。这本书可以帮你
理解什么样的沟通才能帮助你及时获得需要的信息。
希望你能从我所描述的众多读者群体中找到自己的影子。找不到的话，请把书送给其他
能够从中找到自己的人吧。
找到自己了，对吗？接下来我们就正式开始吧。
这本书是如何组织的
不久以前，我买了一台新的彩色激光打印机。打开包装盒，在打印机顶上有一个红色的
大信封，里面装着一本标题为《使用前推荐阅读》的小册子。我当时还奇怪：“真的有必要
先读一下吗？”我之前都是不会读的，觉得没什么用处。很幸运，这次我读了，因为打
印机内部的不同地方有很多塑料支撑件，这是为了保证打印机在运输过程中不被损坏而
加入的，如果我不清理，让它们直接开始打印，这台打印机就废了。
这个故事看起来有点跑题？其实一点儿都不跑题。
这本书也有一章叫“使用前推荐阅读”，阐述了两个关键概念，以及本书使用的词汇表。在
开始读这本书之前，我希望你能将这些概念熟记于心。如果没有理解这两个概念就开始
毛手毛脚使用用户故事地图，后果自负。
一万英尺高空俯瞰用户故事地图
本书的~4章从整体视角介绍用户故事地图。如果用过用户故事并且也玩过用户故事
地图，阅读这几章就足够你掌握使用故事地图的正确“姿势”。
第5章是一个精彩的练习，帮助你学习创建故事地图的核心理念。和同事一起做一下这
个练习，每个参与者都可以从中学习这些理念。我相信，在此之后他们为产品做的用户
故事地图会比之前好很多。
深入理解用户故事
第6~12章介绍用户故事背后的故事，用户故事的工作原理，如何在敏捷和精益项目中更
好地使用用户故事。故事地图中有许多小的用户故事，足以驱动每天的开发进程。即使
是敏捷老兵，我相信也会学到此前并不知道的内容。如果刚开始使用用户故事，你在本
章学到的知识足以使那些自称了解敏捷的同事感到惊讶。
更好的待办列表
第13
相关推荐
— 没有更多了 —
以下为对购买帮助不大的评价