用户故事地图
实习公司最近在做产品规范，提出了采用用户故事地图的模式管理开发产品，从中了解了一些，简单谈谈我对用户故事地图的理解
一、用户故事地图简介
用户故事这个词源于敏捷，什么是产品设计中的用户故事？
就是以用户能自我代入的方式，设计产品，用产品讲述用户的故事。你上网去查，肯定会得到的解释大多解释都是：
“描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。用户故事通常的格式为：作为一个<角色>，我想要<功能>，以便于<商业价值>。”
这样的描述对吗？对！但是太狭隘了。
用户故事首先应该是一个种思维，即故事思维，是运用故事的元素进行思考和设计，以求解决某种问题，达到特定效果的思维。在用户故事设计中，核心是要通过故事来传递信息，引起共鸣，解决问题。
故事地图是一门在需求拆分过程中保持全景图的技术 ——《用户故事地图》
二、用户故事地图结构
Epic史诗，theme故事篮子，userstory故事
例如一个邮件系统的例子：
三、故事地图步骤
1. 召集到3-5名对产品非常熟悉的人员参与。3-5人听上去像是个魔法数字，实际上是的。因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。
2. 使用静默头脑风暴模式，让每个人在便签纸上写下自己认为重要的“所要做的事情”也就是 用户任务（user task）。每个人都用同样颜色的便签来书写自己的用户任务描述，这个阶段不要互相讨论。一旦大家都基本完成了准备，让每个人轮流大声读出自己的内容，并把便签纸全部放置在桌面上，这时如果出现重复的内容就可以省略掉：
- 根据你的产品规模，这个过程可能需要3-10分钟的时间；你可以观察大家的行为来判断是否需要停止。
- 基本上每张便签都会以一个动词开头，如：发送邮件、创建联系人、添加用户等。
- 这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton）部分。
- 这时可以提示参与者：我们只用了很少的时间就完成了需求的收集过程，而且有些内容你可能没有想到，而其他人帮你想到了。
3. 然后，让大家将桌面上所有的便签进行分组，将类似的任务分为一组，其他的的类似
- 这个过程最好也让大家采用静默模式进行，因为这样做会更快。如果发现重复的内容，就略过
- 基本上分组会很容易完成
- 这时同样观察每个人的行为，判断大家是否已经做完，基本上这个过程需要2-5分钟
4. 选择另外一个颜色的便签，对每个组进行命名，并贴在每组便签的上部
5. 对这些分好组的便签进行排序，一般按照用户完成操作的顺序，从左到右摆放
- 如果大家无法决定顺序，那么顺序可能没有那么重要（明显）。
- 这一组便签，Jeff Patton称为 用户活动 （User Activities）
- 这时你的地图应该类似于
6. 现在，按照 “行走的骨骼” 用户行为 这行开始讲述用户故事，确保你没有遗漏任何用户行为和用户任务。这时一般由组织者进行讲述，其他人提出意见，甚至可以让最终用户来参与讨论。
7. 这时，我们已经完成了用户故事地图的基本框架；可以在每个用户任务下面添加更加细节的 用户故事（User Stories）了。这时仍然建议使用静默头脑风暴的模式来进行第一轮用户故事的产生，同时借助如Persona和Scenario等方式协助完成这个过程。一旦你完成了用户故事的创建，就可以开始划定你的 发布计划（Releases）了
- 一般我习惯在第一个发布中只选择每个用户任务的2-3个用户故事。这对于帮助大家排定优先级和范围将很有帮助。
- 基本上我们不必使用用户故事的标准句法（As a …）来书写这些故事，因为每张便签都处于我们的地图的特定位置，大家很容易识别其所处的场景和角色。
8. 最后，针对第一个发布的所有用户故事进行分解，确保我们的第一个发布越小越好，基本上你需要保证在1-2个迭代后就可以发布你产品的第一个版本(MVP)
MVP是指可以产生预期成果的最小产品发布
MVP:最小可行方案是指可以产生预期成果的最小发布方案
————《用户故事地图》
四、用户故事价值与作用
1.既见树木又见森林
2.记录
3.团队之间的高效沟通