关于敏捷开发:学习敏捷创建用户故事地图User-Story-Mapping的8个步骤-IDCF

《用户故事地图》这本书的原作者 Jeff Patton 是一位独立参谋，讲师和麻利教练；他所提出的用户故事地图的办法次要用于解决麻利需要剖析过程中的问题：

• 只见树木不见林，重要的待办项容易吞没在各种细节中看不到全貌，因此难以排列优先级
• 不能显著地聚焦于用户需要
• 很难理解不同粒度故事 (史诗故事、主题故事以及故事) 之间的关系 —
• 不能不便地理解零碎提供的性能的完整性 —
• 不能不便地理解零碎提供的工作流以及价值流 —
• 不能不便地利用递增和迭代的形式去确定公布打算以及公布指标

当开始进行一个产品或者我的项目布局的时候，首先须要梳理出一个 backlog，在其中依照优先级列出所要实现的场景和具体性能。这时咱们首先遇到的一个问题就是如何确保咱们的 backlog 笼罩了最重要的用户体验门路，是否咱们以后所布局的场景的确能够为用户提供价值？这点对于麻利开发十分重要。对精益有肯定理解的敌人肯定晓得 MVP（Most Variable Product 最小化可用产品）的概念，MVP 的目标是以最小的投入公布对用户有价值的产品，帮忙咱们疾速试错，并通过不停的迭代最终找到产品的正确方向。这个思路很好，但如何确认咱们的 backlog 中的内容是那个 ” 最小的 ” 而且 ” 可用 ” 的产品却是件很艰难的事件。我在和团队一起探讨初始产品需要的时候经常会因为大家的了解不同而破费大量的工夫进行梳理，但却发现每次即使咱们将后果用文档记录下来，大家依然不足对产品的总体意识，这就是所说得 ” 只见树木不见林 ” 的状态 … … 因为，不足一种将用户故事可视化的办法。

一、用户故事可视化 — 起床故事

明天的实战工坊中最精彩的局部就是团队演练，李老师首先对用户故事地图的构造进行了简略介绍，而后要求咱们分组讨论一个最简略的场景：早上起床出门。以下就是我和小伙伴们整顿的第一个用户故事地图：

• 每个人都十分相熟这个场景，然而当咱们开始探讨的时候，2 个问题开始浮现
• 每个人习惯不同，如何对立咱们的故事？
• 从起床到出门要经验几个不同的阶段，到底应该如何确定阶段？

第一个问题其实是 ” 用户故事 ” 要解决的首要问题，这个场景的角色（Persona）是谁？第二个问题其实就是确认需要的粒度过程。

在麻利需要剖析过程中，对 Persona 的确认十分要害，如何对立大家的思路并让大家能够在探讨某个场景的时候能够聚焦到特定的 Persona 上是我之前常常遇到的问题。探讨中常常会跑偏，原本谈这个 Persona，后果跑到另外一个 Persona 下来了。明天探讨中，咱们首先将 Persona 的定义通过卡片贴在了工夫线的左侧，这个很小的动作，却让团队的成员能够十分专一于以后 Persona 的场景探讨，效率很高。

再说说粒度，以前常常有人问我 backog item 的粒度如何确定，而我的答复常常是从实现的角度来思考，比方：管制在 2 - 3 天的工作量上。其实这是个十分不靠谱的倡议，因为在探讨需要的过程中还无奈确认是否要做，更谈不上评估工作量。

这里裸露了 Scrum 的一个最次要的问题，backlog 解决的是在 story 确认当前如何进行开发过程布局的问题，而对 story 该如何产生，如何设计的问题并没有给出很好的解决办法。咱们往往把 story 当成需要来看，而实际上麻利应用 story 来形容需要的目标是为了帮助团队进行探讨，以便最终确认需要（也就是 specification）。用户故事地图的作用就是将 user story 的简略形容：

As a …. I want to … so that …

用可视化的形式展示在团队背后，让团队能够认真梳理，探讨，确认这个 story 蕴含的内容，最终产出 specification 进行开发。

二、用户故事地图的构造

• 每个用户故事地图代表一个残缺的用户故事
• 地图的外围是一条从左到右的工夫线
• 工夫线的上部搁置最大粒度的内容（能够了解为 Epic
• 工夫线的下部的第一行搁置二级粒度内容（能够了解为 backlog item），并在每个一级粒度下依照从左到右的优先级进行搁置
• 每个二级粒度内容的上面，自上而下搁置三级粒度内容（能够了解为 task）

最终咱们绘制进去一个残缺的端到端的用户故事。明天的 ” 起床故事 ” 体验中感触最强烈的是：大家专一，指标明确，探讨实现的故事十分残缺。

三、创立用户故事地图 (User Story Mapping) 的 8 个步骤

1、招集到 3 - 5 名对产品十分相熟的人员参加。3- 5 人听下来像是个魔法数字，实际上是的。因为更少的人意味着你无奈取得足够的倡议，而更多人则会因为探讨和协调升高会议效率。

2、应用静默头脑风暴模式，让每个人在便签纸上写下本人认为重要的 ” 所要做的事件 ” 也就是 用户工作（user task）。每个人都用同样色彩的便签来书写本人的用户工作形容，这个阶段不要相互探讨。一旦大家都根本实现了筹备，让每个人轮流大声读出本人的内容，并把便签纸全副搁置在桌面上，这时如果呈现反复的内容就能够省略掉：

• A. 依据你的产品规模，这个过程可能须要 3 -10 分钟的工夫；你能够察看大家的行为来判断是否须要进行。
• B. 基本上每张便签都会以一个动词结尾，如：发送邮件，创立联系人，增加用户等。
• C. 这些便签组成了一级用户故事，Jeff Patton 称为用户工作（user tasks），它们组成了用户故事地图上的 “ 行走的骨骼 ”（the walking skeleton）局部。
• D. 这时能够提醒参与者：咱们只用了很少的工夫就实现了需要的收集过程，而且有些内容你可能没有想到，而其他人帮你想到了。

3、而后，让大家将桌面上所有的便签进行分组，将相似的工作分为一组，其余的的相似:

• A. 这个过程最好也让大家采纳静默模式进行，因为这样做会更快。如果发现反复的内容，就略过
• B. 基本上分组会很容易实现
• C. 这时同样察看每个人的行为，判断大家是否曾经做完，基本上这个过程须要 2 - 5 分钟

4、抉择另外一个色彩的便签，对每个组进行命名，并贴在每组便签的上部

5、对这些分好组的便签进行排序，个别依照用户实现操作的程序，从左到右摆放:

• A. 如果大家无奈决定程序，那么程序可能没有那么重要（显著）。
• B. 这一组便签，Jeff Patton 称为 用户流动（User Activities）
• C. 这时你的地图应该相似于

6、当初，依照 “ 行走的骨骼 ” 用户行为这行开始讲述用户故事，确保你没有脱漏任何用户行为和用户工作。这时个别由组织者进行讲述，其他人提出意见，甚至能够让最终用户来参加探讨。

7、这时，咱们曾经实现了用户故事地图的根本框架；能够在每个用户工作上面增加更加细节的 用户故事（User Stories）了。这时依然倡议应用静默头脑风暴的模式来进行第一轮用户故事的产生，同时借助如 Persona 和 Scenario 等形式帮助实现这个过程。一旦你实现了用户故事的创立，就能够开始划定你的 公布打算（Releases）了

• A. 个别我习惯在第一个公布中只抉择每个用户工作的 2 - 3 个用户故事。这对于帮忙大家排定优先级和范畴将很有帮忙。
• B. 基本上咱们不用应用用户故事的规范句法（As a …）来书写这些故事，因为每张便签都处于咱们的地图的特定地位，大家很容易辨认其所处的场景和角色。

8、最初，针对第一个公布的所有用户故事进行合成，确保咱们的第一个公布越小越好，基本上你须要保障在 1 - 2 个迭代后就能够公布你产品的第一个版本。

四、用户故事地图样例

这里是一个电子邮件系统的用户故事地图

第二行所蕴含的内容就是 ” 大家在电子邮件系统所要做的事件 ”，包含相似：书写邮件，发送邮件，创立约会等等。第一行对这些事件进行了分组 黄色的便签的第一行蕴含了最小化的用户故事，如：写邮件只包含发件人，收件人，题目，内容和发送勾销按钮。其余如反对 RTF，HTML 格局，增加附件，从通讯部获取联系人邮件地址等，都不在此行，放入更靠下的便签中。黄色便签上的更小的蓝色和橘黄色便签示意了不同的状态，比方：蓝色代表实现，橘黄色代表进行中（wip），这样你就能够看到我的项目的停顿

当初如果咱们专一于从左到右实现第一行的黄色便签，咱们就能够确保很快公布一款蕴含了最最基本功能的邮件系统。这样咱们就能够验证咱们的邮件系统整体架构（发送邮件同时确保其能够被浏览）可行。同时也能够帮忙咱们对系统的性能进行端到端的测试，确保咱们能够从用户处获取到反馈，晓得咱们是否解决了它们的问题（提供了商业价值）。留神咱们在第一行没有蕴含 ” 删除邮件 ” 这一性能，因为并不一定要实现所有用户工作的开发。

五、用户故事地图规范

第 2 个步骤中的便签示意 用户工作（user tasks），蓝色便签 第 3 - 4 个步骤中的便签示意 用户行为（user activies），橘色便签。Jeff 称这两行的内容为 “ 行走的骨骼 ”（walking skeleton）和 “ 骨干 ”（backbone）用户故事（user stories），黄色便签在每个用户工作下自上而下排列，便于咱们确定优先级 一般来说用户会依照从左到右的程序来应用你的零碎（用户故事地图）

玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022 年 3 月 5 - 6 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入