用户故事地图 User Story Map

User Story Mapping 是Jeff Patton倡导的一项技术。它为我们提供了一种将整个产品或服务设想为用户完成的一系列任务的方法。

从纯粹的实际角度来说，它涉及构建一个用户故事网格，这些故事在标题下排列，代表用户在产品中的体验。这可以通过团队成员之间的一系列对话迭代完成。因此，第一次尝试可能看起来像这样，用户故事按其各自的功能分组（有些可能称这些顶级功能'Epics'）。

在这里，我们将产品的高级功能（骨干，如果您愿意）分解为组件用户故事。很容易看出每个用户故事属于哪个功能，因此每个用户故事都在整个产品的上下文中呈现，而不仅仅是列表中的项目。

虽然这种方法有助于组织我们的想法 - 它已经比简单的故事列表更具信息性 - 它实际上还没有构成故事地图，因为它没有考虑用户旅程的流程。

开发故事地图
让我们通过想象一个简单的电子商务网站让我们的例子更加具体，产品愿景板提到了三个特征：

最初的故事地图可能如下所示：

我们有“产品页面”功能，其中包含与下面列出的功能相关的用户故事，同样适用于“产品搜索”和“结帐”功能。但是这些故事还没有特别好地发展，并且没有迹象表明每个故事的重要性。

例如，用户需要在订购之前阅读产品说明，但这是在他们阅读评论之前或之后发生的吗？哪个为用户提供更多价值？

在进行了更多的研究并收集了来自利益相关者的更多意见之后，另一次迭代可能看起来像这样。

请注意，我们通过将其中的一些细分为更小的部分来改进我们的用户故事，我们引入了一个新的维度，故事按照用户旅程中的位置排列，我们已经开始安排最高的我们地图顶部附近的优先故事

在这个方向上进一步发展，很容易看出我们最终是如何得出一张地图，指出在前几个版本中需要包含哪些故事。

建立故事地图 (Visual Paradigm)

故事地图是一个用于需求收集的4级层次结构。故事地图从不同来源（即积压）收集的用户特征集合开始，这些用户特征将通过执行某些任务作为活动来实现。这些任务可以转换为史诗，然后转换为软件开发的用户故事。

故事地图结构：用于实现目标的用户功能（待办事项记录）>活动>任务>史诗>故事

用户故事地图的结构

为了促进敏捷开发，Story Map可以接收从不同来源识别的用户功能。如上所述，它可能是来自EA合同的要求，来自项目管理计划的工作包或特殊分析（例如 - 是和将来的分析），使用图中的用例与敏捷软件开发集成等等。

将用例发送到Backlog

假设我们已经从多个不同的来源累积了故事地图积压中的用户特征列表。通过执行某些任务，将实现用户功能作为活动。每个任务都可以进一步分解为几个史诗（更大的用户故事）。每个史诗都包含一个用户故事列表，这些用户故事被分解为适合适合sprint迭代的大小。以下是规划故事地图所涉及的步骤：

请注意：我们可以考虑从左到右安排实施的优先级，从顶部到底部安排用户故事。