用户故事地图是将用户想要做的事通过二维可视化的方式表示出来。（在软件开发中使用故事地图的想法和名称都来自 Jeff Patton。）故事地图是创建对产品的共同理解、可视化用户需求以及在故事编写工作坊中激发用户故事创意的一种方法。我倾向于使用便签和纸张在一面大墙上绘制故事地图，如果我们不在同一个地方，也可以在虚拟白板上绘制。
从重要的目标开始
我建议将故事地图聚焦在一个重要的目标或 MVP（最小可行产品）上。MVP 或目标应由产品负责人与干系人协商选定。
一个好的重要目标应当可以在三个月左右实现。这个时间长度足以让团队在大的想法上取得进展，但又足够短，让人感觉到进展不是遥不可及的。Scrum 团队通常可以将他们的产品目标作为重要目标，前提是这个目标可以在三个月左右完成。
在某些情况下，团队可能会有一个较小的重要目标，并希望在一个季度内实现多个目标。这样也可以，但在着手第二个目标之前，要先为第一个目标创建一个故事地图。
由谁参与故事地图绘制？
我建议在绘制故事地图时，整个Scrum团队都要在场，包括产品负责人（回答问题并根据重要目标或 MVP 列出地图的重点）和 Scrum Master（协助引导）。
一般来说，还希望包括干系人、客户、用户以及其他能够对用户需求发表权威意见的人。
维度一：横向
故事地图的第一个维度，是在地图上水平展开的一系列用户任务。产品负责人引导参与者讨论用户为实现重要目标或其中的一部分，需要采取的步骤或行动。
在地图上添加一个物理或虚拟的便签或索引卡，代表序列中的每个步骤。如果需要，会议主持人可以写下所有的卡片，但我认为让大家各自在卡片上写下新步骤，并在把它添加到地图上时宣读出来和大家达成一致，这样效果会更好。
由于故事地图的水平维度代表了一个顺序，因此可以通过在卡片之间插入 “然后”一词来进行阅读。因此，图1中的地图可以理解为“用户执行第一步，然后执行第二步，接着执行第三步”。假如你所在的团队被要求开发一款软件，公司员工可以通过它提交费用报告并获得报销。要提交费用报告，员工首先需要登录系统，这就成为地图上的第一张卡片。接下来，员工要创建一个新的空白费用报告，这就成为地图上的第二张卡片 — 放在登录卡片的右侧，表示这两件事是按顺序发生的。这可以从图 2 中看出来，同时还能看到员工接下来要输入费用，最后提交费用报告。
图2 提交费用报告的初始故事地图
为了节省故事地图绘制过程中的时间，地图中的卡片很少写成完整的用户故事或工作故事。在绘制时，最好写上字数较少的短语：你希望故事地图能够快速创建并快速阅读。会议结束后，产品负责人或分析师通常会将卡片移动到团队的产品Backlog 管理软件中，并使用用户故事模板创建用户故事，例如“作为一个……，我……以便….”或“当……时，我希望……以便….”。
维度二：纵向
记得我之前说过，故事地图是二维的。那么第二维是什么呢？就是替代方案。还是以费用报告为例，假设参会者意识到，有的用户可以通过复制旧的费用报告来创建新费用报告。我经常这么做。我不会新建空白的费用报告，而是复制一份最近的报告，然后编辑副本。
如图3所示，“复制现有的费用报告”可以添加到地图中的“创建空白费用报告”卡片下。
图3 除了创建空白费用报告外，用户还可以选择复制现有费用报告
由于同一列中的卡片是不同的可选方案，因此在向下读取一列时，可以通过插入“or（或者）”一词来阅读地图。
现在从我们的地图中读到的信息是这样的：用户登录后，创建一份空白的费用报告，或复制一份现有的报告，然后输入支出费用，最后提交费用报告。
包含备选方案的卡片应该按照优先级从高到低的顺序添加到地图中 —— 最重要的在最上面，最不重要的在最下面。在绘制故事地图的过程中确定的优先级并不是严格不变的，产品负责人可以进行调整。但是，在一列备选方案中对大致的优先级进行简短的讨论是非常有用的。
华丽一些：添加标题行
有些故事地图可能会非常宽。遇到这种情况时，在地图上添加一行标题会很有帮助。比如一个简单的文字处理器允许用户格式化、打印和保存文档。这些操作类别可以作为标题添加到地图中，如图4中的蓝色卡片所示。
图4 添加了蓝色标题卡片，用于指示地图各部分的起始位置
在阅读这些标题卡时，同样可以在每个标题卡之间加上“then（然后）”：用户可以先格式化文档，然后打印文档，最后保存文档。
标题卡本身并不是由团队直接实施的故事，而是史诗、主题或团队用来表示一组相关故事的任何术语。
再华丽一些：使用子地图
我发现即使有标题行，宽大的地图也很难理解。更好的做法是通过使用子地图来保持地图的简洁。要做到这一点，可以把地图中的每张卡片想象成你可以双击并扩展成子地图。
回到支持格式化、打印和保存文档的简单文字处理器，我们可以创建一个极其简单的地图，仅包含这三个行为的卡片，如图5所示。
图5 一个高维度的故事地图，展现了极简文字处理器的三个顶层行为然后想象一下，每张高维度卡片中都包含一个子地图。如果我们在脑海里双击顶层三张卡片中的任意一张，就可以看到这张卡片中所包含的二维故事地图。如图 6 所示。
图6 地图中的每张卡片都可以包含一个子地图
使用子地图而不是创建单个巨大的地图有很多优点，包括：
- 子地图更具有可读性
- 子地图为地图增加了实际上的第三维和第四维度
- 子地图就像编程语言中的函数或方法一样，可以在父地图的多个位置引用
- 子地图中的卡片也同样可以包含自己的子地图
故事地图有助于发现缺失的功能
故事地图可以帮助团队发现他们可能忽略的用户活动或功能。所以需要从用户体验的角度浏览故事地图，看看是否有遗漏。
在模拟的过程中，在每个步骤中提出几个问题会很有帮助，例如：
- 用户接下来最有可能想要做什么？
- 用户在这里可能会犯什么错误？
- 用户此时可能会为什么感到困惑？
- 用户可能还需要哪些信息？
如果您的产品有多种类型的用户，请针对每种类型的用户都问一下这些问题。
当我站在用户的角度去看我们关于费用报告的示例故事地图时，我意识到用户经常需要为一些费用附上收据。因此，我需要增加一个新的步骤。也许团队成员会建议产品需要允许用户通过两种方式来实现这一点。首先，如果系统能够激活设备的摄像头并直接扫描收据就更好了。其次，用户需要能够将现有的PDF或图片附加到收据上。把每种方案都添加在故事地图 的“附加收据”卡片下方。
使用故事地图可视化发布
由于故事地图是按优先级顺序垂直排列的，因此产品负责人可以使用故事地图来传达产品路线图，展示一个或多个即将发布的版本中功能的预期顺序。要绘制路线图，请在地图上添加一条水平线，然后将必须包含在下一次发布或下一个产品版本中的所有内容拖动到该线上方。回到之前使用的费用报告系统，一个可发布的产品必须让用户能够登录并制作新的费用报告。因此这些卡片被放置在图 7 中的横线上方。
图7 可以在故事地图中添加横线来展示发布计划让我们假设一开始使用一个新的空白报告就足够好了。团队可以在稍后添加复制现有支出报告的功能，因此该功能被置于第一条横线下方，表示它不在第一个版本中。用户需要附加收据，但在MVP版本中只支持拖放上传现有的图片文件，如地图顶部左侧的标签所示。激活移动设备的摄像头以拍摄收据照片的功能计划在第二版中添加，这张卡片被放在横线的下方。
你使用过故事地图吗？
故事地图是我最喜欢的工具，它可以帮助产品负责人、干系人和开发人员理解用户需求以及这些需求之间的相互联系。尤其是在集思广益地收集实现产品目标所需的产品待办项上，用户故事地图非常有效。
你使用故事地图吗？觉得它们有用吗？你在使用故事地图时遇到过哪些挑战？欢迎在评论区中分享你的想法和经验。
作者：Mike Cohn
