您的位置 : 首页 >> 科技电子书

用户故事地图User Story Mapping: Discover the Whole Story, Build the Right Product (English Edition)

下载方式

☞温馨提示:想直接推送电子书到手上的kindle吗~ 点击此处购买本书正版即可☜ 限时折扣,先到先得
用户故事地图User Story Mapping: Discover the Whole Story, Build the Right Product (English Edition)
本书作者: Jeff Patton

本书读后感· · · · · ·

本书都是在介绍用户故事地图方法,以这一设计开发产品的方法为主线贯穿到产品开发周期的各个环节。前半部分在介绍用户地图的概念和使用方法,后半部分对开发各环节中方法的应用进行详细补充,略显啰嗦。地图最大特点:能使各个团队成员参与到产品的宏观、微观中来,明确节奏和目标,对产品需求达成共识,这比仅是文字叙述的文档要高效很多;对产品目标并进行科学拆分,不断以迭代思想完成细分下来的初级目标最后补充、整合逐渐完成大愿景。虽然之前也接触过便签-白板讨论,但从没见过谁总结出书中这样系统的使用方法、思考方式。14年出版,16年国内发行,方法并不过时。最近准备尝试将该做事方法应用到实际工作中进行检验分析。最后引用书中结语:Great art is never finished, only abandoned.

我的学习笔记

在前面讲到的用户故事3C原则中,Card(卡片)是3C原则中的第一个C。
用户故事地图User Story Mapping: Discover the Whole Story, Build the Right Product (English Edition) 科技电子书 第1张我在本书的开头讲过,我不觉得自己有义务在开篇引用整个敏捷宣言,但接下来我会引用其中的一小部分。宣言中的其中一句是“可以工作的软件胜过面面俱到的文档”,我想借用这句话来表达我的意思“可以工作的软件胜过面面俱到的讨论”,两句话说的是同一个道理。所有这些口头讨论和书面文档,都是为目标服务的,最终要开发出可以工作的软件。

在头脑中构建清晰的图像

在讨论(Conversation)之后,记下讨论中涉及的细节可以帮助我们回忆讨论时的场景,并写下确认的结论(Confirmation),终于可以开始做事情了:
·开发人员可以开始着手开发软件
·测试人员创建测试计划和开始测试
·UI设计师做细节设计,并做成电子版·文档工程师开始撰写或者更新帮助文件
最重要的一点是,所有人头脑中有着同样的图像,这个图像正是在讨论过程中大家达成的共识。
为了保证读者的阅读效果,我决定在这里暂停一下。后面我会放慢节奏,读者也可以相应放慢阅读的节奏。

用户故事地图User Story Mapping: Discover the Whole Story, Build the Right Product (English Edition) 科技电子书 第2张检视产出
如果在团队之中,你和所有工作的人对要开发什么功能及为什么要开发这些功能有一致的理解,但随着工作的进行,还是不断有讨论发生,因为你不可能每时每刻都记得所有的细节。当软件开发完成时,大家聚在一起演示和讨论。
这是一个很好的庆祝工作完成的时机,看到实实在在的进展总是让人觉得高兴。在传统软件开发流程中,产品演示的频率低很多,很少像一个团队一样分享每一步进展。在典型的敏捷流程,比如Scrum中,每两周迭代就会有一次产品演示会。如果团队非常健康,成员就会对所有刚完成的功能做演示。我们需要在演示和讨论的基础上更进一步,在庆祝之后,拿出一些时间严肃审视一下产出的质量。

你又不是用户
抱歉,后面还有更多坏消息。
实际上,写卡片和开发卡片功能的人,并不是软件的最终用户。产品经理和团队常常有一种错觉,认为自己已经锁定用户需求,并且开发出来的就是可以解决用户问题的最佳方案。
拜托,不要自欺欺人了,好吗?!
一个聪明的团队,会在功能开发出来之后把软件拿给最终用户试用。这里所说的试用,并不是演示和讲解。而是观察用户使用产品来解决问题的过程。

开发过程就是学习的过程
如果你已经认识到使用用户故事可以避免团队开发出糟糕的产品,至此,事情才做对了一半。实际上,聚焦于解决问题的讨论,距离做出一款很棒的产品还有很长一段路要走。软件产品开发和流水线生产并不一样,现在开发的组件和上一个开发的组件不会是一模一样的,每一个故事对应的开发工作都是创新活动。
Alistair Cockburn作为敏捷开发社区的名人(敏捷宣言的17位签署人之一),也是前文提到的我的一位老朋友,曾经跟我说过一句话:“对于每一个用户故事,在待办列表中应该有三张卡片与之对应。”
我问为什么,他回答:“你这样做就好了。”
“另外两张卡上我写啥啊?”我问。
“写什么很重要吗?”
“你这是什么意思?我总要在上面写点什么东西吧。”我又问。
“好吧,如果你非要在上面写点东西,那么在第一张卡写上用户故事,然后第二张卡上写“修正第一张卡”,第三张卡上写“修正第二张卡”。如果没有对一个故事进行三次锤炼,那么这个过程就不能称之为一个学习过程。”

我女儿过生日,需要一个生日蛋糕。但是我们并不想自己动手做蛋糕。Sydnie是一位烘焙师,她烤的蛋糕美味极了。我们不知道Sydnie到底有怎样的厨房魔法,总之只要问孩子生日想要什么样的蛋糕,他们都会说“Sydnie的蛋糕。”所以这次我们请Sydnie为我女儿做生日蛋糕。
我先给Sydnie打了个电话,她在电话中询问是为谁订蛋糕,要在什么场合吃。我告诉她是Grace的12岁生日蛋糕。她又问:“最近Grace有什么特别的兴趣和爱好?”然后我们聊了Grace最近的兴趣和想法。还聊了Sydnie的烤盘形状,蛋糕如何设计才方便她烤好蛋糕。最后,确定做一个小鸟形状的蛋糕。
这就是讲故事的正确“姿势”。Sydnie问了许多3W问题,这些问题都是关于who、what、why的。她询问了上下文,包括在何时何地吃蛋糕,有多少人参加。交谈中,我们考虑了几种不同的选项。并且,我们交谈的时间足以达成一致的理解。由于我们之前从Sydnie那里订过很多次蛋糕,所以对蛋糕的形状和口味多少有一些了解。如果从来没有订过,还需要看图片或者亲自尝一下,仅仅电话沟通是不够的。