在学习用户故事的地图之前，先让我们来学习用户故事的概念
用户故事是指用户来描述用户渴望获得的功能，是具有一定价值的端到端交付。用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。
一个完整的用户故事包含三个要素：
“用户故事”源于1996年Kent Beck提出的极限编方法（《Agile Development》，中译名《敏捷开发的艺术》）。在2004年，敏捷大师Mile Cohn在《User Stories Applied For Agile Software Development》(中译名：《用户故事与敏捷方法》)一书中，正式定义“用户故事”这一概念，并提出著名的“INVEST”特点。
《用户故事地图》中，介绍了一个好的用户故事所应该具备的特性：3C原则。
（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
卡片的正面书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。
（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通；确保各方对故事的理解正确。
（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。
用户故事地图可以看做是用户故事的升级版本，用户故事地图已经成为敏捷需求规划中的一个流行方法。用户故事地图可以将你的backlog变成一张二维地图，而不是传统的简单列表。用直白一点的话讲，用户地图是在特定场景下，贴在墙上的（可视化）一系列用户行为的集合。
一个用户故事地图的典型样例如下：
第一步：团队召集
主持人召集3-6人左右的团队，要求参与者有比较丰富的业务及产品经验。提前准备好便利贴、笔、白板等道具
第二步：背景介绍
产品发起人或者主持人对本次会议的目的进行介绍，描述用户的画像，并介绍大概的用户需求
第三步：静默头脑风暴
全体成员使用便利贴，每个人将自己对于用户在产品使用过程中的行为进行穷举，要求格式为动词+名词形式，例如打开手机，输入用户名，输入密码等等，此过程要求大家不做相互的交流，保持静默。
第四步：汇总创意并分组
请所有人依次介绍自己写的用户行为，这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton）部分。
然后，让大家将桌面上所有的便签进行分组，将类似的任务分为一组，选择另外一个颜色的便签，对每个组进行命名，并贴在每组便签的上部。这一组便签，Jeff Patton称为 用户活动 （User Activities）
第五步：二次头脑风暴
针对已经做好的便签分组，请大家再次做一次头脑风暴，对用户行为细节进行补充细化，确保所有的用户行为都已经得到了体现。
第六步：优先级排序
对所有的用户任务的优先级进行排序，这个排序决定了后续产品开发的优先级，优先级排序建议先确定一些排序的规则，例如KANO或者MoSCoW等，确定优先级的过程中，可以采用小红点投票方式确认优先级。通过优先级确认，可以将用户任务分为3-5组，这些将成为未来产品开发分期交付的backlog。
用户故事地图制作的过程，也是团队对产品开发范围和优先级的共识过程。用户故事地图可以广泛应用于产品0-1的过程中，其中优先级最高的一批需求构成MVP，更多的细节请参考Jeff Patton的《用户故事地图》。
无论对于传统的瀑布型的项目，还是敏捷开发模式的项目，梳理用户故事地图都能够帮助我们更有效的管理用户需求。传统的项目管理使用需求跟踪矩阵来对需求进行管理，其实质和用户故事地图是类似的，但是用户故事地图更加的直观，沟通的效率相对来说更加高效，但是缺点也是有的，用户故事地图中描述的信息相对较少，对于需求的细节体现不足，因此在具体的工程实践过程中，还需要额外的一些文档来进行需求的详细阐述。
另外，用户故事地图的生成也是一个很好地团队建设的过程，有利于提升团队对于项目目标理解的一致性，在项目前期梳理业务需求的时候是很好的一个手段和方法。
联系客服
