用户故事地图是梳理用户故事的方法

说到用户故事地图（User Story Mapping），大家都会联想到用户故事（User Story）。没错，可以认为用户故事地图就是把许多个用户故事罗列在一张地图上的事物。但是，这只是用户故事地图与用户故事的表层关系。当我们在做发布规划、梳理需求的时候，我们往往很难将用户故事直接描述出来。这个时候，我们需要通过用户故事地图展现出清晰的故事脉络，来帮助我们梳理出用户故事。也就是说，用户故事地图其实并非是将描述好的用户故事汇总在地图上。而是通过分析、梳理，将用户故事展现出来，进而汇成了一副用户故事地图。

用户故事地图的诞生

用户故事地图是由一位叫杰夫（Jeff）的敏捷教练首先使用并总结的。杰夫最初使用这个方法的时候非常偶然。当时他的一位好朋友正在创业，准备做一个连接歌手与粉丝的音乐发行平台Mad Mini，因为迟迟不能发布产品，钱也烧得差不多了，于是找杰夫帮忙，希望通过敏捷实现快速交付。

杰夫那天去朋友的办公室时，公司正在搬家，要搬到一个便宜的民居去，屋里便空了。杰夫拉着他的朋友，坐在地板上，让他描述用户使用Mad Mini 的场景和需要做的特定动作。杰夫一边听，一边写用户故事，并按照时间顺序，排在地板上，不时地问些细节问题，写些细化的故事。两个小时，他们在地板上摆了一地的卡片，这就是世界上的第一幅用户故事地图。随后，杰夫又帮他的朋友在地图上直接做了一次发布规划， 划分出若干个交付版本。最后，杰夫带着那个团队按照敏捷的方式开发快速交付、快速探索用户需求。

后来，杰夫就开始把这种整理需求的方式，记录下来，并在博客上分享，很快得到了很多人的认同。为此，他专门写了《用户故事地图》这本书。

此部分内容节选自《敏捷无敌之DevOps时代》作者：王立杰、许舟平、姚冬（清华大学出版社）

如何制作用户故事地图

那么，我们来看看用户故事地图应该怎么制作呢？通过何种分析才能将用户故事梳理出来呢？

• 地图的核心是一条从左到右的时间线。

• 时间线的上部放置最大粒度的内容（可以理解为Epic）。

• 时间线的下部的第一行放置二级粒度内容（可以理解为Backlog Item），并在每个一级粒度下按照从左到右的优先级进行放置。

• 每个二级粒度内容的下面，自上而下放置三级粒度内容（可以理解为Task）。

• 最终绘制出来一个完整的端到端的用户故事。

我们先来看一个“早上起床出门”的用户故事地图：

我们首先划出一条时间线。在线的上部，是我们做的几个主要事务，相当于Epic。接下来就是对主要事务的拆分了。比如“起床”这个Epic下，涉及“离床”、“叠被子”这样的Backlog Item（Feature/Story）。而“叠被子”肯定是要在“离床”之后再做，所以按照时间线的顺序，把“叠被子”放在“离床”的右侧。再对Backlog Item进行细化，“离床”下面细化出了“睁眼”、“停闹钟”这样的粒度更细的事项，相当于Task。

按照这样的结构，我们就制作成了一幅用户故事地图。

这样的用户故事地图构建体验中，很强烈感受的是：大家专注、目标明确，讨论完成的故事非常完整。

而且，笔者认为，用户故事地图最终展现出的成果并不是最重要的。我们最应当关注的是在制作用户故事地图的过程中，我们对于整个结构、流程的梳理。通过这样的讨论，让每一个团队成员都了解用户故事地图的脉络，让大家明白需求从何而来、为何而做，才是用户故事地图的意义。