用户故事地图
[TOC]
一、前言
本文是我在阅读Jeff Patton所著的《用户故事地图》（User Story Mapping）一书后的感悟和理解的整理。
二、用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能。一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能。
- 功能：需要完成什么样的功能。
- 价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常如此表达：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
需要注意的是，用户故事不是另一种写需求的方式，讲述用户故事，在过程中用文字和图片相结合的方式辅助讨论，是一种建立共识的机制；用户故事也不是需求，用户故事是关于问题解决方案的讨论，解决公司的问题，解决客户的问题，解决用户的问题，目的是我们对要开发的功能达成共识。
三、为什么要使用用户故事地图
使用故事地图来组织用户故事，是为了保持对产品全景图的理解，避免只见树木，不见森林。
通常使用用户故事的方法是先组织需求故事列表，排列优先级，讨论故事，然后逐个进行开发。这听起来似乎非常合理，实际上却会造成严重的问题:
- 容易聚焦于开发什么功能，而忽略了期望达成的业务成果；
- 优先级排序是基于用户故事的一维、线性的，忽略了不同种类的用户也应该按优先级排序；
- 未经组织的用户故事，难以阐明用户故事的顺序、不同顺序可能的分支、不同故事之间可能的替换关系，因此团队成员难以对产品全景图达成完整、一致的共识；
- 容易过早地陷入各种细节上的争论，而未聚焦于故事的整体。
用户故事地图是一个模式，通过组织用户故事，使团队对整个产品或整个特性达成共识，将大的用户故事进一步拆分。
四、计划
1.为了更少的开发
想要开发的功能，总是超出你能投入开发的资源，所以必须通过计划决定做什么以及不做什么。判断系统内某功能做与不做，应该以系统外的预期成果为标准。每一个发布发布计划，也都应该以产品发布后用户能够使用和感知的东西，即成果为导向。
用户故事地图聚焦的正是用户能使用和感知的东西，即成果，而非某具体功能。
使用用户故事地图能带来的主要收益之一，是能够有一个空间充分思考各类可行方案，从而找到一条可以最大化投入产出的路子。
2.为了更快的学习
与《精益创业》中的观点类似，我们应该通过最小可行产品实验实验，快速获得经证实的认知，并迭代开发直至可行。
使用故事地图来划分出可行产品更小的发布，用它来支撑最小可行产品实验，以迭代方式发现什么才是真正的可行。
3.为了按时发布
为了开发新特性，需要团队所有成员达成一致的理解。团队成员需要能够指出设计方案中的问题和改进点，并对需要投入多少开发时间迸行估计。这才是构建故事地图的最终目的。毕竟，最靠谱的估算，来自于真正理解自己在估算什么的工程师。
五、如何创建故事地图
1.分步骤写出故事
每个步骤都是一个用户任务，以动词开头。同时要注意，不同用户在使用软件时，有不同的目的；用户也会在不同情况下使用软件，有时还必须考虑其他人和事情的影响。
使用目标层级的概念，可以帮助汇总小任务或分解大任务。
2.组织情节
以从左到右的顺序组织卡片（用户故事），每个故事之间用“然后，我这样做”连接，形成叙事流。这是人们讲故事最自然的方式。
通过叙事流来组织故事，发现并补充之前遗漏的细节。
3.探索替代故事
用户执行任务的顺序往往不会一成不变，叙事流也不会只是一条线往下发展。对于每个用户故事，如果有不同的执行方式，就形成一个替代故事，叙事流中也从此处衍生出一个分支。
细节、替代、变化和异常，构成故事地图的主体。
4.提取主干
部分用户故事高度相关，需要放到一起，对这些用户故事提炼出更高目标层级的任务，即“活动”。活动由一群相似的人在相似时间完成的任务组成。
5.切分出能达成特定目标的任务
按照特定目标，将故事地图水平切分。对每一个目标（通常也是一个迭代），水平切分中的从左到右的任务，就是为了达成此目标所需要完成的全部任务。与此目标不相关的任务不会出现在此切分中。
