作者简介
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翻译组管理员。
目录
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章 开发完成后怎么学习
结语
内容摘要
我经常听到有人跟我讲:“我喜欢敏捷开发!因为每隔几周就能看到可以工作的软件。但是,敏捷开发让我觉得只见树木不见森林,看不到产品的垒景图。”这些话是不是听着很耳熟呢?是不是自己也曾经有过这样的感慨?其实,使用敏捷方法和用户故事,并不意味着要牺牲对产品全貌的理解。敏捷团队可以做到在每几周一次发布的同时对产品垒貌保持健康的理解和讨论。想必你已经耐着性子读完了“使用前必读”,接下来我就直奔主题,讲一下用户故事地图是如何帮助敏捷团队解决最令人头疼的问题的。如果你已经对在敏捷项目中如何写用户故事有所了解,这一章会是一个不错的开始。让我们从头开始大多数读者都知道,敏捷开发会用到用户故事,而用户故事地图是一种处理用户故事的方法。现在,每出一本敏捷开发相关的书,都会在开篇印上“敏捷宣言”。“敏捷宣言”是2001年由17位对当时软件开发方法失望透顶的人共同签署的,这是件令人高兴的事情。时至今日,宣言已经影响了非常多的人。我不打算在这本书上也印上“敏捷宣言”,然后花大量篇幅来讨论它的重要性。本书默认读者已经理解敏捷宣言,如果你还没有读过敏捷宣言,建议你先读一下再回来。在本章原本应该放“敏捷宣言”的地方,我放的是一张喵星人(萌猫)的图片。为什么我要这么做呢?因为,有事实屡屡证明在网上人们对喵星人的关注远远超出对任何宣言的关注。搞不懂了吧,萌猫和敏捷有什么关系呢?其实,什么关系都木有……但是,敏捷和这本书,敏捷和用户故事,敏捷和用户故事地图的演化,都有关系。<来一段能勾人回忆的音乐……>2000年的时候,我在旧金山的一个创业公司工作,公司请Kent Beck(极限编程创始人,第一个提出用户故事这个慨念的人)担任软件研发顾问。用户故事作为一个方法已经提出很长时间了,十多年前就已经有人开始使用Kent提出的用户故事。之所以提出这一方法,是因为Kent和其他极限编程的先驱意识到过去处理需求的方法并没有很好的效果。KentfftJ想法也非常简单,团队在一起讲述用户故事,通过讲故事的方式,大家获得对产品愿景的一致理解,然后共同创建更好的产品解决方案。故事是讲出来的,不是写出来的首次听到“用户故事”这个词的时候,我曾经感到很困扰。(当然,后来我逐渐接受了这个词。)但是,把重要的用户需求拆分成琐碎的用户故事,这种做法看起来并不合理。在讨论对产品愿景的一致理解之前.必须声明,我是一个学东西比较慢的人。我花了挺大工夫才弄明白下面这个道理:用户故事之所以叫故事,因为它是要讲而不是要写的。即使不明白这个道理,我依然可以使用卡片或便签写一大堆用户故事(一句话或者一个简短的标题),根据故事的重要性,移动卡片来调整优先级,当我发现有一个故事比其他故事更重要时,我们会就此展开讨论。这样做很酷,不是吗?为什么我之前没有这样做呢?......
主编推荐
对于软件开发而言,用户故事地图是一个很有价值的工具,但前提是你必须明白它的用途和正确用法。用户故事地图很容易被误解和误用,因此,本书深入解释了如何用它来帮助团队始终聚焦于用户及其需求,而不是热衷并痴迷于单个炫酷的产品特性而迷失方向。
作者Jeff Patton展示了用户故事的种种用法,力求帮助团队在整个开发过程中始终围绕着项目展开更好的互动交流。通过这样的对话,团队能对构建怎样的产品及其能够用户带来怎样的价值和体验达成共识。这样的共识是打造产品的前提。
俯瞰用户故事地图,通过适当的练习来掌握相关的关键性概念。
领悟故事是如何实际发挥效用的?在敏捷和精益项目中,如何从故事中挖掘真正的需求
探究一个故事的生命周期,从各种可能的机会入手,步步深入,发现有价值的需求。
准备故事,关注其产生过程,从中了解可以转换为特性的需求,打磨出的软件产品。
精彩内容
用户故事地图作为一种有效的需求工具,越来越广泛地应用于开发实践中。《用户故事地图》以用户故事地图为主题,强调以合作沟通的方式来全面理解用户需求,涉及的主题包括怎么以故事地图的方式来讲用户需求,如何分解和优化需求,如果通过团队协同工作的方式来积极吸取经验教训,从中洞察用户的需求,开发真正有价值的、小而美的产品和服务。
《用户故事地图》适合产品经理、用户体验设计师、产品负责人、业务分析师、IT项目经理、敏捷教练和精益教练阅读和参考,也更适合用作企业培训手册,打造高效能的团队协作能力。
媒体评论
对于软件开发而言,用户故事地图是一个很有价值的工具,但前提是你必须明白它的用途和正确用法。用户故事地图很容易被误解和误用,因此,本书深入解释了如何用它来帮助团队始终聚焦于用户及其需求,而不是热衷并痴迷于单个炫酷的产品特性而迷失方向。
作者Jeff Patton展示了用户故事的种种用法,力求帮助团队在整个开发过程中始终围绕着项目展开更好的互动交流。通过这样的对话,团队最终能对构建怎样的产品及其能够用户带来怎样的价值和体验达成共识。这样的共识是打造一流产品的前提。
俯瞰用户故事地图,通过适当的练习来掌握相关的关键性概念。
领悟故事是如何实际发挥效用的?在敏捷和精益项目中,如何从故事中挖掘真正的需求
探究一个故事的生命周期,从各种可能的机会入手,步步深入,发现有价值的需求。
准备故事,关注其产生过程,从中了解可以转换为特性的需求,打磨出一流的软件产品。
“在我接触过的人当中,帮助正规软件开发团队真正深入洞察其需求和价值回报的敏捷专家当中,只有少数几个人称得上实至名归。Jeff Patton算一个。”
——Marty Cagan,Silicon Valley Product Group合伙人
以下为对购买帮助不大的评价