用户故事是在敏捷开发中表达需求的主要方式，我们在做敏捷开发的时候都有需求池的概念，在 Scrum 中这个需求池就是产品 backlog，需求池里面是条目化的需求，每一条通常是一个用户故事。按照 Scrum 的定义，产品 backlog 是一个基于价值强制排序的队列，团队按照价值的高低，顺序地交付需求。
在开发的过程中，团队会逐步的细化产品 backlog ，为了保证短平快的交付，高优先级的用户故事会被分解为较小的粒度。但是这样带来了一个问题，对于那些规模稍大一些的产品来讲，故事的数量就会很多，故事拆分后通常会有只见树木不见森林的感觉。用户故事地图是 Jeff Patton 发明的一种组织和管理用户故事的方法，可以很好的解决这个问题。 Jeff Patton 还写了一本书《用户故事地图》来帮助我们更好地学习故事地图，这本书地中译本（百度李涛翻译）今年三月份会在国内上市。
本文将介绍如何使用 Leangoo 看板来实现故事地图，以帮助我们更好的进行需求的管理和可视化。
在介绍故事地图之前，我们先回顾一下用户故事的基本概念。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能。
- 活动：需要完成什么样的功能。
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
用户故事地图是一种对用户故事进行组织和优先级排序的方法。用户故事地图可以带来如下的一些好处：
- 故事地图提供了一个需求的大图景，可以帮助我们通过看板对业务流程或价值链进行可视化。
- 建立了大的故事和拆分后的子故事直接的对应关系。
- 让我们对 backlog 的完成情况一目了然。
- 可以帮助我们从一个整体的视角、用户价值的视角来进行优先级排列和发布规划。
用户故事地图包括两个纬度，横向是业务流，纵向是价值顺序。下图是一个示例：
图－1
在上图中，橙色的卡片代表的是粗粒度的用户故事，可以理解为 Epic －史诗故事，Jeff Patton 称之为用户的活动（User Activity）,这些用户的活动代表了产品的骨架，我们从左到右按照时间线来排列这些活动，排列好之后，系统的主要的业务流程就呈现出来了。需要注意的是，为了找出这些用户活动，第一步要做的是做角色建模，把用户角色先提炼出来。在每个史诗故事下面，我们可以拆分出更细粒度的用户故事。这些用户故事加在一起就构成了产品需要做的主要功能，并且已经按照系统骨架组织好了。
在上图的横向的纬度，我们使用橙色的虚线把这些卡片横切成了3个泳道，每个泳道代表一个发布。所以，从这个故事地图上看，横向代表的是系统的骨架，脉络，纵向代表的是重要性，优先级，发布顺序。
我们需要根据用户的价值来思考在这个业务流程上，哪些是最核心、最重要的，我们可以按照提炼 MVP（最小可行产品）的思路把核心场景找出来，放到前面的发布中，把低优先级的放到后面的发布中。这样做的目的是做价值驱动，让我们从用户的视角产品核心价值，并且持续地、增量地交付。
了解了故事地图的思路之后，我们看看如何使用 Leangoo 工具来实现这样地一个故事地图。用户故事地图是2纬的，Leangoo 看板工具很容易实现，在看板中，我们有列表和泳道的概念，列表代表了纵向的纬度，泳道代表了横向的纬度。在 Leangoo 中，我们通常使用列表代表不同的发布，我们通常建立这么几个列表：业务流，Sprint1，Sprint2，Sprint3-N，已交付的故事。业务流这个列表代表的是橙色的卡片，也就是史诗故事，每个史诗故事一个泳道。Sprint1，Sprint2，Sprint3-N里面是不同史诗故事拆分出来的用故事，并且根据优先级放到了不同的 Sprint 里面，横向的泳道代表的是史诗故事和史诗故事拆分的子故事的对应关系。如下图所示：
图－2
已经交付的故事这个列表放的是完成的故事，这样可以通过 Leangoo 生成发布燃尽图，通过发布燃尽图了解整个产品或项目的研发进展。
Leangoo 实现的购书网站的故事地图示例如下图所示：
图－3
通过 Leangoo 看板，我们可以非常方便的通过故事地图把产品的需求全景图展示出来，产品的规划也一目了然，这对于我们持续地关注产品核心价值，更好地进行产品规划非常有帮助。
网友评论