［小编］上周六了解了用户故事地图后，小编又查阅了一些资料，找到了以下这篇关于如何组织用户故事地图规划的文章，分享给大家。也希望大家如果有好的实践，也可以留言一起交流。
原文地址：http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html
感谢Jeff Patton和其他人的大力推广，用户故事地图已经成为敏捷需求规划中的一个流行方法。用户故事地图可以将你的backlog变成一张二维地图，而不是传统的简单列表。用户故事地图可以解决以下问题：
– 让你更容易看清backlog的全貌
– 为新功能筛选（grooming）和划定优先级提供了更好的工具，帮助你做出决策
– 便于使用静默头脑风暴模式和其他协作方式来产生用户故事
– 帮助你更好的进行迭代增量式开发，同时确保早期的发布可以验证整体架构和解决方案
– 为传统的项目计划提供了一个更好的替代工具
– 有助于激发讨论和管理项目范围
– 允许你从多个维度进行项目规划，并确保不同的想法都可以得到采纳
创建用户故事地图的8个步骤
- 召集到3-5名对产品非常熟悉的人员参与。3-5人听上去像是个魔法数字，实际上是的。因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。
- 使用静默头脑风暴模式，让每个人在便签纸上写下自己认为重要的“所要做的事情”也就是 用户任务（user task）。每个人都用同样颜色的便签来书写自己的用户任务描述，这个阶段不要互相讨论。一旦大家都基本完成了准备，让每个人轮流大声读出自己的内容，并把便签纸全部放置在桌面上，这时如果出现重复的内容就可以省略掉：
- 根据你的产品规模，这个过程可能需要3-10分钟的时间；你可以观察大家的行为来判断是否需要停止。
- 基本上每张便签都会以一个动词开头，如：发送邮件，创建联系人，添加用户等。
- 这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton）部分。
- 这时可以提示参与者：我们只用了很少的时间就完成了需求的收集过程，而且有些内容你可能没有想到，而其他人帮你想到了。
- 然后，让大家将桌面上所有的便签进行分组，将类似的任务分为一组，其他的的类似
- 这个过程最好也让大家采用静默模式进行，因为这样做会更快。如果发现重复的内容，就略过
- 基本上分组会很容易完成
- 这时同样观察每个人的行为，判断大家是否已经做完，基本上这个过程需要2-5分钟
- 选择另外一个颜色的便签，对每个组进行命名，并贴在每组便签的上部
- 对这些分好组的便签进行排序，一般按照用户完成操作的顺序，从左到右摆放
- 如果大家无法决定顺序，那么顺序可能没有那么重要（明显）。
- 这一组便签，Jeff Patton称为 用户活动 （User Activities）
- 这时你的地图应该类似于
- 现在，按照 “行走的骨骼” 用户行为 这行开始讲述用户故事，确保你没有遗漏任何用户行为和用户任务。这时一般由组织者进行讲述，其他人提出意见，甚至可以让最终用户来参与讨论。
- 这时，我们已经完成了用户故事地图的基本框架；可以在每个用户任务下面添加更加细节的 用户故事（User Stories）了。这时仍然建议使用静默头脑风暴的模式来进行第一轮用户故事的产生，同时借助如Persona和Scenario等方式协助完成这个过程。一旦你完成了用户故事的创建，就可以开始划定你的 发布计划（Releases）了
- 一般我习惯在第一个发布中只选择每个用户任务的2-3个用户故事。这对于帮助大家排定优先级和范围将很有帮助。
- 基本上我们不必使用用户故事的标准句法（As a …）来书写这些故事，因为每张便签都处于我们的地图的特定位置，大家很容易识别其所处的场景和角色。
- 最后，针对第一个发布的所有用户故事进行分解，确保我们的第一个发布越小越好，基本上你需要保证在1-2个迭代后就可以发布你产品的第一个版本。
用户故事地图样例
这里是一个电子邮件系统的用户故事地图
– 第二行所包含的内容就是“大家在电子邮件系统所要做的事情”，包括类似：书写邮件，发送邮件，创建约会等等。
– 第一行对这些事情进行了分组
– 黄色的便签的第一行包含了最小化的用户故事，如：写邮件只包括发件人，收件人，标题，内容和发送取消按钮。其他如支持RTF，HTML格式，添加附件，从通讯部获取联系人邮件地址等，都不在此行，放入更靠下的便签中。
– 黄色便签上的更小的蓝色和橘黄色便签表示了不同的状态，比如：蓝色代表完成，橘黄色代表进行中（wip），这样你就可以看到项目的进展
现在如果我们专注于从左到右完成第一行的黄色便签，我们就可以确保很快发布一款包含了最最基本功能的邮件系统。这样我们就可以验证我们的邮件系统整体架构（发送邮件同时确保其可以被阅读）可行。同时也可以帮助我们对系统的功能进行端到端的测试，确保我们可以从用户处获取到反馈，知道我们是否解决了它们的问题（提供了商业价值）。注意我们在第一行没有包含“删除邮件”这一功能，因为并不一定要完成所有用户任务的开发。
用户故事地图规范
– 第2个步骤中的便签表示 用户任务（user tasks），蓝色便签
– 第3-4个步骤中的便签表示 用户行为（user activies），橘色便签。Jeff 称这两行的内容为 “行走的骨骼”（walking skeleton）和 “主干”（backbone）
– 用户故事（user stories），黄色便签在每个用户任务下自上而下排列，便于我们确定优先级
– 一般来说用户会按照从左到右的顺序来使用你的系统（用户故事地图）
请关注微信公众号 devopshub，获取更多关于DevOps研发运维一体化的信息
