| 编辑推荐: |
本文来自于冰块IT观察，什么是用户故事地图？本文结合这一次实战工作坊的实际案例，给大家条分缕析。 |
|
我们下面从有关需求的常见问题出发，来看一看我们经常会遇到什么样的问题。
一、大家的期待
开始之前，我们对每位参加的学员做了简单调查，大家的期待还算比较集中。
还有之前一次workshop，大家的几点期待：
1.如何管理Product Backlog和Sprint Plan。
2.How to organize a good story。
3.了解不同粒度故事(Epic、Theme、User Story)之间的关系，如何方便地利用递增和迭代的方式去确定发布计划以及发布目标。
4.理解User Story的拆分原则。
5.希望通过这个workshop，能够学习实践以下内容：
6.如何在敏捷开发流程中使用用户故事。
7.如何更好地划分用户故事粒度。
8.如何合理的规划迭代的周期。
9.如何保证用户故事覆盖了所用的需求。
10.How to apply User Story Mapping
in real project。
11.更好理解用户故事， 熟练使用用户故事划分开发活动。
12.希望通过本课程掌握撰写可以同时帮助开发与测试有效地理解任务目标的user
story的方法论。
13.获得怎么分析用户地图，学习经验。
14.深入了解Agile。
二、软件开发中常见的需求问题
Workshop开始之后，大家首先讨论了产品开发中所做的事情和经常遇到的一些问题。
1.用户故事聚焦于构建小特性，很容易“只见树木不见森林”。
2.在开发大型产品的时候，逐个开发小特性会让人们不知道整个产品何时能够完成开发和发布。团队中的工程师也会有同样的困惑。
3.用户故事强调沟通，于是不写任何文档。这会导致大家忘记在沟通中讨论的内容和达成的共识。
4.好的用户故事要有验收条件，以至于只专注于写验收条件，却对要做什么缺乏一致的理解。
5.好的用户故事是从用户角度来描述的，然而系统中有大量不与用户产生直接交互的部分，团队成员认为产品没有用户，用户故事并不适用。
6.很难了解不同粒度故事(史诗故事、主题故事以及故事)之间的关系
7.面对一大堆用户故事，很难去划分优先级
8.如何方便地了解系统提供的功能的完整性
9.如何方便地了解系统提供的工作流以及价值流
10.如何方便地利用递增和迭代的方式去确定发布计划以及发布目标。
总结起来，就是如下的两个问题：
1.如何开发？
2.如何交付？
针对这些问题，我们来看看使用用户故事地图的工具如何破解。
三、早晨出门的故事
开始正式讲解用户故事地图之前，我们先来做个简单的练习，亲身感受一下。这个练习呢，很简单，就是用便利贴，写下你早晨从起床到出门，这个过程中所做的所有事情。简单吧！
练习一：悠闲的早晨。假如你早上6点就醒了，而你通常要8点才会出门，路上要半个小时。于是，从起床到出门的这两个小时里，你应该有很多事情可做。写下来吧，然后以时间顺序从左到右排个顺序。下面是工作坊的一组同学们即兴发挥的杰作。
看来确实有很多事情要做的。大家写的也比较丰富。
在之前的工作坊中，有的团队选择自己团队中的一员作为参考者，而有的团队则给想象中的人建立了用户画像（Persona），然后针对自己团队建立起来的Persona，写出想象中的Persona的全部活动。这都是可取的建立完整活动的办法。
练习二：匆忙的早晨。天哪，一睁眼就8点了，要赶快了，否则，今天早上9点的会议可真要迟到了，而这个会议必须不能迟到的。所以，理想情况下，你只有半个小时的时间收拾收拾了。这种情况下，你会怎么做呢？？？
那只能忍痛割爱，把必须要做的事情做了，收拾好东西赶紧出门吧。有的同学甚至脸都不洗了，漱一下口就算了。有个女同学说，妆不化了，粉也不抹了，洗个脸就行了。哈，看来大家的“刚需”差别很大。
下面是一组同学最后选择的必做之事。“上厕所”这件事看来真的不可少。
大家最后剩下的，都是必须要做的事情，少一件都不行。所以，这可以算作今天“早晨出门”这件事情的一个MVP了。
练习3：会议取消了。啊？？？临出门的一刻，小伙伴儿用微信发来消息说，早上的会取消了。哦，那就不用太赶了，过会儿再走也行。错峰上下班，8点半钟路上可正堵着呢。你又有了半个小时的时间，那就再做点儿什么吧。比如，再把脸好好洗洗，抹个粉啊啥的。
下面是另一组同学的一组选择。
至此，我们分别尝试了三个不同类型的早晨活动。
在我们做的过程中，从左到右依次按时间顺序，排列出了各个活动的顺序。从上到下，依次排列出了各个活动的重要程度，从必须一定要做的活动，到可以不做的活动，再到最不必要做的事情。
一个完整的“早晨出门”的故事地图就完成了。
四、用户故事地图
那什么是用户故事地图呢？把之前我们的练习中的各个活动（事情）替换成软件开发中的用户故事，把“早晨出门”这件事替换成我们开发的软件，一个完整的软件产品的用户故事地图就完成了。
用户故事地图的主要结构如下图所示：
最上面，是主要活动（Activities）。用于串联起来，从左至右放置主要活动 （叙事流），讲述一个故事，回答“用户会如何使用这个系统？”这样的问题。
往下，是具体任务（Tasks），极其细化之后的子任务（sub-tasks）。用于细化每个活动，从左至右阐述工作流，添加子任务。
如果一个活动涉及多项子任务，则从上到下按讲故事的顺序添加。
从上往下，按照重要性或者优先级排序。最后得到一个排好了顺序的完成的产品用户故事地图。
然后，按照团队开发的速率或其他业务要求，划分不同的发布计划。如上图所示。这就是使用用户故事地图进行发布计划管理的生动例子。
形象地看，用户故事地图就是软件产品的一副会行走的骨骼。
五、用户故事地图的重要概念
现在回头看看上面曾经做过的用户故事的练习。我们的用户故事地图涉及了一些重要的概念。
1.任务是描述人们做的事用的，它是动词短语。
2.任务具有不同的目标层级。
3.任务在故事地图中从左向右被组织成为叙述流。
4.故事地图的纵深包含了变化的、可互相替换的任务。
5.任务被处于故事地图顶端的活动组织在一起。
6.活动构成了故事地图的骨干。
7.你可以把故事地图分片，用来识别为了达成某个特定目标而必须的任务。
举例来说，用户故事地图就是如下这样的一副产品交互、逻辑、结构图。
如下例所示。
六、创建用户故事地图的步骤
正如我们在上述练习中所使用的方法，创建一个完整的用户故事地图，需要如下的基本步骤。
更进一步，我们有如下的六步法。
七、使用用户故事地图来验证用户体验的完整性
软件产品的用户体验是否完整，有时候很难仅凭想象就能确定。使用用户故事地图，从用户体验的角度出发，可以验证用户体验的完整性。
假设“如厕”这件事情，其基本的用户体验流程为：
寻找标识 – 进门 – 查看环境 – 使用洁具 – 洗手 – 干手 – 出门
但对于不同的产品，所能提供的用户体验确实相差很大。如下图所示的三个不同的厕所（洗手间），给人的用户体验绝对各不相同。
我们可以从用户体验的角度出发，以用户实际使用我们的产品的体验过程为逻辑顺序，创建一个完整的用户故事地图（体验流程）。或者以现有产品的功能特点出发，创建现有产品的用户故事地图（体验流程），进而检查当前产品的用户体验流程是否完整。并讨论、确定是否需要添加更多的用户功能。
下面的示例，就是在工作坊的过程中，IBMer们改造IBM一款IM通信软件时的脑洞大开之作。
八、为什么要使用用户故事地图
简单来说，一个个用户故事，就是一堆凌乱无序的树叶，而一副完整的用户故事地图，把各个用户故事的逻辑关系串联起来，就是一棵完整、鲜活的树木。
九、用户故事地图的价值
用户故事地图为我们提供了一种实现“用户体验是一个完整的过程”的产品管理方法，一个打通“产品规划”与“开发计划”的工具。它让我们可以：
1.更容易看清backlog的全貌
2.为Product Backlog Grooming 和 Prioritizing
提供更好的工具，帮助做出决策
3.便于使用静默头脑风暴模式和其他协作方式来产生用户故事
4.帮助你更好的进行迭代增量式开发，同时确保早期的发布可以验证整体架构和解决方案
5.为传统的项目计划提供了一个更好的替代工具
6.有助于激发讨论和管理项目范围
7.允许你从多个维度进行项目规划，并确保不同的想法都可以得到考虑和探讨
8.帮助回忆具体细节
9.预防信息蒸发
刨根问底游戏：
1.用户在这一步具体要做什么事情？
2.用户在这一步还有其他选择吗？
3.如何做能让用户感觉更炫酷？
4.当出现问题时如何处理？
用户故事地图是一种工具，它可以用在任何需要结构化展示相关逻辑关系和结构的地方。如下图所示的层次：
十、用户故事地图的实践之路
实践中，用户故事地图使用起来有着诸多问题，尤其是像IBM这样的老牌传统公司，对安全的要求超过了一切，办公室里基本容不得任何目视可见的项目信息。
总体来讲，我们常常会遇到下面的现实问题：
1.会议室不是独占的（空间、秘密）
2.看板离工位远（实时）
3.团队成员懒，没时间（写、粘）
4.记事贴粘不牢固，掉了一个也不知道
5.没和开发计划打通
6.安全检查肯定不过关
一个目前可行的解决之道，就是使用电子用户故事地图工具。一个好用的在线用户故事地图，既能促进协作，也可提高可视化的程度。目前，主流的敏捷项目管理工具基本都支持用户故事地图。我在这里就不举例了，以免有广告的嫌疑。
|
