【沉积】用户故事地图

用途：解决产品设计和需求管理

US（User story 用户故事)了解过敏捷的人一般都熟悉，一般由PB (Product backlog 产品待办列表）开始，在Sprint 计划会上需求被拆分得到US。在软件开发中，只关注US容易只见树林不见森林，丢失软件系统全景图。

那么，就有了以下两个问题，

问题1：US的源头-PB是如何产生的？

问题2：如何在US的碎片中不会迷失在细节中？

答案是：用户故事地图，其是一门在需求拆分过程中保持全景图的技术。

开发人员需要通过沟通理解用户想要达成什么目标，懂故事地图的开发人员可以更好地理解用户场景，更好的地推动开发进程。

故事，是开发人员、产品和其他角色进行沟通的基本要素，故事地图以结构化方式来组织这些要素，以来强化软件开发过程中最关键的环节-沟通。 并增加参与人员的愿景和使命感，我们是在建一个房子，而不是在堆砌水泥，构件。

PS： 用户故事的3C：卡片、沟通、确认

通过构造简单的用户故事地图来使产品使用过程中的用户体验图形化和可视化，从而提升团队的协同效率。故事地图可以使我们专注 于用户和用户体验，产生更好的沟通效果，最终做出更好的产品。

基于用户故事地图可以得到产品规划，产品发布计划，产品路线图（时间，主题）等各种你和团队想要的目标、里程碑、价值等关键要素的组合体，一方面方便内部信息同步，另一方面也有了向上汇报的资料。

步骤：

1. 一边讲故事，一边讲一边把用户经过的重要步骤记录在便签上，并按照从左到右的顺序水平排列。

2. 再讨论每个步骤的细节，在便签上纪录，垂直向下贴在每个步骤的下方。

3. 得到一个网络结构，从左到右讲述故事，从上到下拆分细节。每一列顶层的卡片都是大故事，在每个大故事上停一下，然后提出以下问题：

用户在这一步具体要做什么事情？

用户在这一步还有其他选择吗？

如何才能使用用户觉得更炫酷？

出现问题时如何处理？

4. 可能根据故事的重要性和紧急程度，移动卡片的位置

5. 切分发布计划（应以成果，即用户能使用和感知的东西）为导向，把成果/主题写在右侧

6. 当发布计划完成后，我们也得到一个可以向上汇报的精简的产品路线。

PS：MVP 是指可以产生预期成果的最小产品发布，是为了验证假设而做的最小规模的实验。

简单地讲，就是团队在一起讲述用户故事，通过讲故事的方式 ，大家一致理解，然后共同创建更好的产品解决方案。用户故事地图是一个模式，团队对事个产品或整个特性达成共识，将大的用户故事进一步拆分。

用户故事地图通过良好沟通并以地图的形式来系统、全局、高维组织沟通的内容，提供 有一个空间来充分思考各类可行方案，从而找到一条可以最大化投入产出的路子，聚集于系统外的预期成果来决定系统内需要什么功能。

参考：

1. 用户故事地图， Jeff Patton 著， 李涛 向振东译