敏捷实践系列之三——用户故事地图

敏捷实践系列之三——用户故事地图

User Story Mapping

2016年7月28日,颇受欢迎的《用户故事地图实战》工作坊(第二波)在IBM 环宇办公室的大会议室拉开帷幕。25位辛勤好学的IBMer小伙伴儿,一起度过了一个愉快、欢乐而又充实的下午。在张荷芳老师的带领下,大家通过动手实践,学习和体验了一个强大而又简单易用的软件研发新工具——用户故事地图(User Story Mapping)

什么是用户故事地图?下面,就让我们结合这一次实战工作坊的实际案例,慢慢给大家条分缕析。

开始之前,先来认识一下这次工作坊(workshop)的主讲师,来自IBM Analytics Platform的美女张荷芳。

HeFang03

好了,书归正传,我们下面从有关需求的常见问题出发,来看一看我们经常会遇到什么样的问题。

一、大家的期待

开始之前,我们对每位参加的学员做了简单调查,大家的期待还算比较集中。

workshop01

还有之前一次workshop,大家的几点期待:

  • 如何管理Product Backlog和Sprint Plan。
  • How to organize a good story。
  • 了解不同粒度故事(Epic、Theme、User Story)之间的关系,如何方便地利用递增和迭代的方式去确定发布计划以及发布目标。
  • 理解User Story的拆分原则。
  • 希望通过这个workshop,能够学习实践以下内容:
    1. 如何在敏捷开发流程中使用用户故事。
    2. 如何更好地划分用户故事粒度。
    3. 如何合理的规划迭代的周期。
    4. 如何保证用户故事覆盖了所用的需求。
  • How to apply User Story Mapping in real project。
  • 更好理解用户故事, 熟练使用用户故事划分开发活动。
  • 希望通过本课程掌握撰写可以同时帮助开发与测试有效地理解任务目标的user story的方法论。
  • 获得怎么分析用户地图,学习经验。
  • 深入了解Agile。

二、软件开发中常见的需求问题

Workshop开始之后,大家首先讨论了产品开发中所做的事情和经常遇到的一些问题。

  • 用户故事聚焦于构建小特性,很容易“只见树木不见森林”。
  • 在开发大型产品的时候,逐个开发小特性会让人们不知道整个产品何时能够完成开发和发布。团队中的工程师也会有同样的困惑。
  • 用户故事强调沟通,于是不写任何文档。这会导致大家忘记在沟通中讨论的内容和达成的共识
  • 好的用户故事要有验收条件,以至于只专注于写验收条件,却对要做什么缺乏一致的理解
  • 好的用户故事是从用户角度来描述的,然而系统中有大量不与用户产生直接交互的部分,团队成员认为产品没有用户,用户故事并不适用
  • 很难了解不同粒度故事(史诗故事、主题故事以及故事)之间的关系
  • 面对一大堆用户故事,很难去划分优先级
  • 如何方便地了解系统提供的功能的完整性
  • 如何方便地了解系统提供的工作流以及价值流
  • 如何方便地利用递增和迭代的方式去确定发布计划以及发布目标

总结起来,就是如下的两个问题:

  1. 如何开发?
  2. 如何交付?

Slide10

Slide11

针对这些问题,我们来看看使用用户故事地图的工具如何破解。

三、早晨出门的故事

开始正式讲解用户故事地图之前,我们先来做个简单的练习,亲身感受一下。这个练习呢,很简单,就是用便利贴,写下你早晨从起床到出门,这个过程中所做的所有事情。简单吧!

StoriesinMorning01

练习一:悠闲的早晨。假如你早上6点就醒了,而你通常要8点才会出门,路上要半个小时。于是,从起床到出门的这两个小时里,你应该有很多事情可做。写下来吧,然后以时间顺序从左到右排个顺序。下面是工作坊的一组同学们即兴发挥的杰作。

dav

看来确实有很多事情要做的。大家写的也比较丰富。

在之前的工作坊中,有的团队选择自己团队中的一员作为参考者,而有的团队则给想象中的人建立了用户画像(Persona),然后针对自己团队建立起来的Persona,写出想象中的Persona的全部活动。这都是可取的建立完整活动的办法。

练习二:匆忙的早晨。天哪,一睁眼就8点了,要赶快了,否则,今天早上9点的会议可真要迟到了,而这个会议必须不能迟到的。所以,理想情况下,你只有半个小时的时间收拾收拾了。这种情况下,你会怎么做呢???

那只能忍痛割爱,把必须要做的事情做了,收拾好东西赶紧出门吧。有的同学甚至脸都不洗了,漱一下口就算了。有个女同学说,妆不化了,粉也不抹了,洗个脸就行了。哈,看来大家的“刚需”差别很大。

下面是一组同学最后选择的必做之事。“上厕所”这件事看来真的不可少。

dav

大家最后剩下的,都是必须要做的事情,少一件都不行。所以,这可以算作今天“早晨出门”这件事情的一个MVP了。

练习3:会议取消了。啊???临出门的一刻,小伙伴儿用微信发来消息说,早上的会取消了。哦,那就不用太赶了,过会儿再走也行。错峰上下班,8点半钟路上可正堵着呢。你又有了半个小时的时间,那就再做点儿什么吧。比如,再把脸好好洗洗,抹个粉啊啥的。

下面是另一组同学的一组选择。

dav

至此,我们分别尝试了三个不同类型的早晨活动。

在我们做的过程中,从左到右依次按时间顺序,排列出了各个活动的顺序。从上到下,依次排列出了各个活动的重要程度,从必须一定要做的活动,到可以不做的活动,再到最不必要做的事情。

一个完整的“早晨出门”的故事地图就完成了。

四、用户故事地图

那什么是用户故事地图呢?把之前我们的练习中的各个活动(事情)替换成软件开发中的用户故事,把“早晨出门”这件事替换成我们开发的软件,一个完整的软件产品的用户故事地图就完成了。

用户故事地图的主要结构如下图所示:

StoryMapping033

最上面,是主要活动(Activities)。用于串联起来,从左至右放置主要活动 (叙事流),讲述一个故事,回答“用户会如何使用这个系统?”这样的问题。

Time01

往下,是具体任务(Tasks),极其细化之后的子任务(sub-tasks)。用于细化每个活动,从左至右阐述工作流,添加子任务。

Time02

如果一个活动涉及多项子任务,则从上到下按讲故事的顺序添加。

Time03

从上往下,按照重要性或者优先级排序。最后得到一个排好了顺序的完成的产品用户故事地图。

StoryMapping01

然后,按照团队开发的速率或其他业务要求,划分不同的发布计划。如上图所示。这就是使用用户故事地图进行发布计划管理的生动例子。

形象地看,用户故事地图就是软件产品的一副会行走的骨骼。

StoryMapping02五、用户故事地图的重要概念

现在回头看看上面曾经做过的用户故事的练习。我们的用户故事地图涉及了一些重要的概念。

  • 任务描述人们做的事用的,它是动词短语。
  • 任务具有不同的目标层级
  • 任务在故事地图中从左向右被组织成为叙述流
  • 故事地图的纵深包含了变化的、可互相替换的任务
  • 任务被处于故事地图顶端的活动组织在一起
  • 活动构成了故事地图的骨干
  • 你可以把故事地图分片,用来识别为了达成某个特定目标而必须的任务。

举例来说,用户故事地图就是如下这样的一副产品交互、逻辑、结构图。

StoryMapping08

如下例所示。

StoryMapping09

六、创建用户故事地图的步骤

正如我们在上述练习中所使用的方法,创建一个完整的用户故事地图,需要如下的基本步骤。

Slide31

更进一步,我们有如下的六步法

Slide32

七、使用用户故事地图来验证用户体验的完整性

软件产品的用户体验是否完整,有时候很难仅凭想象就能确定。使用用户故事地图,从用户体验的角度出发,可以验证用户体验的完整性。

假设“如厕”这件事情,其基本的用户体验流程为:

寻找标识 – 进门 – 查看环境 – 使用洁具 – 洗手 – 干手 – 出门

但对于不同的产品,所能提供的用户体验确实相差很大。如下图所示的三个不同的厕所(洗手间),给人的用户体验绝对各不相同。

Experience01

我们可以从用户体验的角度出发,以用户实际使用我们的产品的体验过程为逻辑顺序,创建一个完整的用户故事地图(体验流程)。或者以现有产品的功能特点出发,创建现有产品的用户故事地图(体验流程),进而检查当前产品的用户体验流程是否完整。并讨论、确定是否需要添加更多的用户功能。

下面的示例,就是在工作坊的过程中,IBMer们改造IBM一款IM通信软件时的脑洞大开之作。

dav

dav

八、为什么要使用用户故事地图

简单来说,一个个用户故事,就是一堆凌乱无序的树叶,而一副完整的用户故事地图,把各个用户故事的逻辑关系串联起来,就是一棵完整、鲜活的树木。

Slide37

九、用户故事地图的价值

用户故事地图为我们提供了一种实现“用户体验是一个完整的过程”的产品管理方法,一个打通“产品规划”与“开发计划”的工具。它让我们可以:

  • 更容易看清backlog的全貌
  • Product Backlog Grooming Prioritizing 提供更好的工具,帮助做出决策
  • 便于使用静默头脑风暴模式和其他协作方式来产生用户故事
  • 帮助你更好的进行迭代增量式开发,同时确保早期的发布可以验证整体架构和解决方案
  • 为传统的项目计划提供了一个更好的替代工具
  • 有助于激发讨论和管理项目范围
  • 允许你从多个维度进行项目规划,并确保不同的想法都可以得到考虑和探讨
  • 帮助回忆具体细节
  • 预防信息蒸发
  • 刨根问底游戏
    1. 用户在这一步具体要做什么事情?
    2. 用户在这一步还有其他选择吗?
    3. 如何做能让用户感觉更炫酷?
    4. 当出现问题时如何处理?

StoryMapping10

用户故事地图是一种工具,它可以用在任何需要结构化展示相关逻辑关系和结构的地方。如下图所示的层次:

yongchu01

十、用户故事地图的实践之路

实践中,用户故事地图使用起来有着诸多问题,尤其是像IBM这样的老牌传统公司,对安全的要求超过了一切,办公室里基本容不得任何目视可见的项目信息。

总体来讲,我们常常会遇到下面的现实问题:

  • 会议室不是独占的(空间、秘密)
  • 看板离工位远(实时)
  • 团队成员懒,没时间(写、粘)
  • 记事贴粘不牢固,掉了一个也不知道
  • 没和开发计划打通
  • 安全检查肯定不过关

一个目前可行的解决之道,就是使用电子用户故事地图工具。一个好用的在线用户故事地图,既能促进协作,也可提高可视化的程度。目前,主流的敏捷项目管理工具基本都支持用户故事地图。我在这里就不举例了,以免有广告的嫌疑。

674602470771049926

最后、《用户故事地图》

本次《用户故事地图工作坊》的主要内容和课程设计灵感,都来自一本叫《用户故事地图》的同名书,作者是江湖人称“姐夫”的Jeff Patton。该书既有英文版,也有中文翻译版。建议大家买来仔细读一读。

书中所讲的用户故事地图及用户故事的知识,要远比这次工作坊所涉及的内容多得多。目前敏捷软件开发领域,《用户故事地图》这本书是从业人员的必读书籍之一。

Slide13


最后的最后、工作坊

最后,展示一下本次工作坊的情景吧。谢谢大家抱着一颗学习的心,参加本次工作坊。希望对大家的工作和生活有所帮助。

dav

dav

All_3

2 Replies to “敏捷实践系列之三——用户故事地图”

  1. 读了博主的此文,对《用户故事地图》的理解更深了,有2点疑问:团队达成共识是要对整个故事树还是各自负责或参与的用户故事部分? 第二个就是关于原书的三层:活动-任务-子任务,是如何转化成您例子中的角色-活动-用户故事的,感觉有点太突然。