新的用户故事待办列表就是一副地图—（Ⅱ）如何构建和使用用户故事地图

本文翻译自《用户故事地图》作者Jeff Patton的博客，原文地址：http://jpattonassociates.com/the-new-backlog/。因博客比较长，被翻译整理成两篇公众号文章：Ⅰ扁平化用户故事待办列表存在的问题和Ⅱ如何构建和使用用户故事地图。

构建用户故事地图

让我们把用户故事展示成一个有帮助的形状——一副对我工作很有帮助的，地图。

这确实是一个很简单的想法。一个小的用户故事地图看起来就像这样：

地图的顶层是“大故事”。我称他们为用户活动。活动是由人执行的一个比较大的动作，它包含大量的步骤，虽然并不总是有一个精确地工作流。举个栗子，如果我正在构建一个邮件系统，我会有这样一些活动：“管理邮件”，“配置邮件服务器”，“设置不在办公室自动回复”。

一个关于“活动”的用户故事应该这样读：作为一个顾问，我希望能够管理我的邮件，使我可以与客户，同事和朋友保持联系。

但是活动太大了，很难放入迭代或冲刺中。

这个活动可以被分解成一些用户故事，例如“发送邮件”，“读邮件”，“删除邮件”，“标识垃圾邮件”等。我把这些称为用户任务。对于许多敏捷开发人员来说，任务就是为了完成用户故事所做的事情。事实上，任务是用来达成一个目标的一个步骤。一个用户任务是可以帮助用户达成一个目标，而开发人员的任务是用以完成用户故事的。

我把简单的小的事物（用户任务）安排在大的事物（用户活动）下面，形成成一个网状结构。

我总是想象时间从左往右流动。例如当我在地图中放置用户故事时，如果用户在使用系统时总是按某种顺序执行操作，我总是把先执行的放在左边，后执行的放在右边。对用户活动和用户任务我都是这样处理。

当我传授这种方法时，人们总是告诉我“用户可能按照任何顺序进行操作。我应该按什么顺序在地图上进行摆放呢？”我会问他们“请解释给我听系统是用来做什么的——只需要告诉我用户活动。”他们会列举给我。“那就是正确的顺序”，我会说。事实上，你描述系统行为的顺序就是正确的顺序。我们正在构建一副地图，它让我们能够讲述一个关于系统的真实故事。用可以让你讲故事的方式来构建用户故事地图。

保留你的史诗故事，但不要再使用这个叫法，因为这个术语让我困惑

真正的大故事可以被称作“史诗故事”，就像Mike Cohn那样称呼他们。他们也是故事——一些大到无法估算和构建的故事。当一个史诗故事进入到你的待办列表，就需要详细的讨论，我经常看到人们把史诗故事从待办列表中移除，然后进行分解，把分解出的结果放入待办列表。回忆一下我上面的故事吧：把树砍掉，然后把树叶放入袋子。

大的故事是上下文。它能够让我很快想起用户正在做的完整用户活动，也能够让我很快解释给其他人系统是用来做什么的。

然而，我讨厌“史诗故事”这个词，我认为仅仅使用“管理邮件”——一个从用户视角的基本描述就够了。至少“用户活动”和“用户任务”这样的术语让我清晰的知道他们对应的故事类型。也就是说，我也不喜欢“用户故事”这个词汇，但是我已经慢慢接受它。我仍然会很难面对C-level管理人员的眼睛，当我解释给他听“我们已经把您的系统分解成一系列的史诗故事和用户故事”。如果我这样说，我可以想象他会充满敌意的考虑我的每人天咨询价格。

‍遍历你的地图进行测试——获得全景图

对着一副组合好的用户故事地图，我能够和用户，开发人员，或者干系人一起遍历地图，并且讲述一个关于用户如何使用系统的故事。我可以只遍历地图的最上层，high-level的描述一下系统。我也可以深入地图对细节进行讨论。

和用户或者其他人遍历地图可以帮助我找到遗漏的内容。我经常从用户那里听到“你在这漏掉了一些步骤”。

我经常在地图上标识出痛点或者机会。当我和用户遍历地图时，我通常会听到“这里确实是系统目前面临的问题”。

和用户一起工作时，他们经常纠正我。昨天我和一个新系统的潜在用户一起工作——她是一个公司的合规官。她一边说，我一边记下流程步骤并且放到地图上。我用绿色卡片记录大的活动，黄色卡片记录小的任务。她迅速纠正我——“不，那个应该使用黄色卡”。在不到一个小时的讨论中，她能够仅仅使用很少的话语就可以提供大量的关于她会如何使用系统的信息。他知道黄色卡片代表的工作比绿色的要小，并且能够告诉我她在系统中做的事情并没有我想象的那么大。

构建和遍历用户故事地图让我比以往任何时候都感到舒适，因为我能够获取信息并且不会遗漏大的事物。

你的软件拥有脊椎和骨架—你的地图把它们显示出来了

我发现地图顶部的卡片看起来有点像脊骨，挂在下面的卡片像肋骨。那些顶部的卡片通常代表系统需要具备的基本能力。我称它们为软件的“脊椎”。

现在该给用户故事排优先级了，我不需要给脊椎排优先级，脊椎的优先级已经排好了。我只给肋骨—那些挂在脊椎下面的故事排优先级。把脊椎摆在最上面意味着他们不可或缺，摆在下面的意味着重要性降低。当你做这件事的时候，你会发现摆在最上面的故事描述了你可以构建的最小可行性系统，它包含了端到端的功能集。我总是试着首先构建出这副地图。

‍

使用脊骨进行计划

现在开始制作发布计划，通常对脊骨进行排序并不重要。例如如果你希望为汽车构建一个high-level待办列表，它看起来像这样：
引擎
传动系统
刹车
悬架
…

这似乎是愚蠢的，如果你让干系人对这些进行排序：“哪一个更重要，引擎或者传动系统？”或者“我们在这个发布周期没有足够时间，我们可否先发布没有刹车的汽车？”这些内容都是必要的—我们需要所有的内容去交付一个最小可行性产品（MVP）。

当优先级排序到了更低的层次：4缸引擎或者6缸引擎？是否应该具有防抱死功能？是否要有运动悬挂？这就是我们构建肋骨的过程—对重要的特性进行排序。

当你在用户故事地图上进行优先级排序时，你需要上下移动卡片来表示优先级的高与低。之后，我会用长胶带在故事地图上为每个发布创建泳道，接下来我会在泳道之间上下移动用户故事，甚至改变泳道的高度。

保留故事地图，用以沟通系统的全景

构建用户故事地图可以在开始阶段理解系统需要的功能。问你自己一个问题：你是否需要持续理解系统需要什么样的功能？我知道这不是一个公平的问题，但是我确实发现有些人花费了大量时间整理出类似用户地图的东西，然后把分析结果塞入扁平的待办列表中。如同砍掉了树，然后把树叶塞入了袋子。
我发现用户故事地图就好像一个信息雷达一样，我们总是对着它讨论我们正在构建的产品。当项目正在进行时，它会转化为我们的冲刺板或迭代计划板。我们可以在地图上直接标识出下个迭代要完成的用户故事。在迭代过程中，我们把要完成的用户故事放置到任务墙上管理它们的开发—但是故事地图始终提醒我们系统的全景图是怎样的，我们现在已经走到了哪里。

当我们增量构建软件时，一个故事接着一个故事，我们按照地图上从左到右的，从上到下的顺序。我们慢慢的从左到右的遍历脊骨，从上到下的遍历肋骨。我们并不是每次只构建一个特性，而是同时构建所有的主要特性。就好像我们从不会发布一个没有刹车的汽车。

为老产品增加特性，构建不同的用户故事地图

当为老产品增加特性时，产品已经有了脊骨—足够多的特性已经被发布。我发现识别脊骨依然可以让我有效了解上下文—让我了解新的特性应该被放在什么位置。

对某些项目而言，如果要对一个很大规模的产品增加少量特性时，可能很难和干系人讨论并构建故事地图。这种情况下，我仅仅对新的特性进行优先级排序，然后针对每个特性构建一个小的用户故事地图并对用户故事进行优先级排序。每个小故事地图大约包含10张左右的卡片—但它们仍然按照从左到右，从上到下的方式进行排布，我们应该尽早专注于构建一个小的行走的特性骨架。

这是一种模式—而不是一种发明

虽然我尽量避免，但当有人告诉我这个概念时（一个知名的咨询顾问正在教授这种方法管理待办列表），我依然非常愤怒。“他们窃取了我的方法！”是的，我是这么认为的。但是我不得不提醒自己我也从其他人那里学习了很多类似的东西。我清楚早期在ThoughtWorks工作时，我就已经碰巧看到Luke Barrett正在构建几乎同样的模型。

我总是提醒自己这种方法是一个模式。如果你解释给其他人一个概念，他们说“好酷的想法！”这不是模式。但是如果他们说“我们也在做类似的事情！”这就是模式。因为我经常看到类似的方法，所以这个方法是一种模式。

当教授这个方法时，我喜欢播放Indi Young的用户研究构思模型，模型把用户行为按照从左到右的顺序排列，把特性放置在相关的用户行为的附近。我喜欢Todd Warfel的任务分析网状图，它拥有类似用户故事地图的脊骨，所有用户故事按照优先级排在下面。Todd使用颜色代表优先级，而不是垂直方向的顺序。

翻译，李强，现任英捷创软（LEANSOFT）资深DevOps顾问和解决方案专家兼市场总监，曾任微软Visual Studio产品资深解决方案专家，IBM Rational产品资深解决方案专家，汇丰中国区软件开发中心CMMI咨询顾问，具有Scrum Master，SAFe，CMMI，PMP和CSQA等资质。

项目经验：

–          OPPO敏捷开发及工具平台项目

–          中兴通讯敏捷开发项目

–          远光软件开发过程改进及工具平台项目

–          广发银行ALM项目

–          广州农商行ALM项目

–          四川农信ALM项目

–          PICC ALM项目