为什么扁平的用户故事待办列表效果不好？如何构建一个更好的用户故事待办列表，用来更有效的描述你的系统，进行优先级排序和制定发布计划。
这是Gary。
Gary和我用了一整天的时间制作了一副用户故事地图——一个更好的产品待办列表。构建用户故事地图帮助我们聚焦在产品的全貌上而不是关注每一个用户故事。
当进行优先级排序时，Gary基于整个系统的上下文进行排序。Gary的目标是构建一个叫做Mimi (Music Industry Marketing Interface 一个面向音乐行业的系统) 的产品。然而，当对“乐队成员宣传音乐会”这个故事进行排序时，发现这个故事太大了，事实上这应该是一个“史诗故事”，后来它占据了地图上的很大面积去考虑所有的细节，比如：设计一个宣传海报，构建一个邮件列表，邮递宣传海报，跟踪市场反应。在制作用户故事地图的最后环节，发现要完成Mimi产品中所有音乐相关的事情是不可能的，然而，制作一个更快更容易地发送宣传海报的软件看起来是个好主意。后来的事实证明这确实是个好主意。
Mimi在Gary的努力下最终发布了，Mimi目前每月发送上百万条信息。卓越的用户体验让Mimi好像是一个艺术品。同时，我们当时构建的用户故事待办列表仍然可以从最高的视角观察整个系统。
扁平的用户故事待办列表是无效的
对我而言，敏捷实践中其中一项最麻烦的事情就是关于扁平的用户故事待办列表，它看起来是个很笨的主意。如果我希望小规模增量开发软件，我需要知道从哪里开始。待办列表把用户故事进行排序（从高价值到低价值），这对项目经理是一个不错的主意，但是我不是项目经理。
我正在从客户现场返回的飞机上写这篇blog。我和客户都觉得这两天进行的用户故事整理和发布计划制定过程进行得非常顺利。我很高兴的看到客户对他们在做的这项实践非常投入，我把这个实践叫做用户故事地图。我第一次描述这个实践的文章“How You Slice It”发布于2005年1月。其实在写那篇文章之前，我已经使用这种实践很多年了。
几年以后，我越来越热爱这个实践，以至于把这个实践视作“银弹”-这对我来说是一个警告信号。然而，我看到越来越多的人正在采用类似的实践，至少这说明我并不是特别疯狂。
让我描述一下错误的用户故事编写是怎样的，什么是用户故事地图，为什么它可以解决问题。
扁平的待办列表很难解释系统是用来做什么的
当干系人或用户问你：“你们正在开发的系统是做什么的？”，大家一般都会直接把用户故事待办列表发给他看。然而我觉得，把用户故事按照优先级顺序排列并不能帮我向其他人解释系统是做什么的。
对我而言，试图理解整个系统是软件开发中最困难的部分。我从敏捷团队听到的一个最普遍的抱怨就是他们丢失了系统的全景图——即使他们在开始阶段曾经很清晰这个全景图是怎样的。
我一般会这样解释扁平化用户故事待办别表存在的问题，就好像：
“我们花了大量时间与客户一起工作。我们努力理解他们的目标，他们的用户，还有我们要构建的系统的主要功能。最后我们进入细节-我们要构建的系统功能模块。在我的脑海里，我看到一棵树，树干代表着系统的目标或者理想收益；大的树枝代表用户；小的树枝和嫩枝代表用户需要的能力；最终树叶代表用户故事，这些用户故事足够小到被放入迭代。“
“所有的工作完成后，当所有人有了统一的理解之后，我感觉我们摘下了所有的叶子并把叶子放入了一个袋子，然后砍掉了树。“
“这就是我对扁平化待办列表的理解，一袋子没有上下文背景的树叶。”
上下文才是真正可以帮我将一个系统描述清楚的重要信息。
对于一个新的系统，扁平化待办列表无法帮助我确认是否已经识别出全部故事
拿着一堆索引卡，或者一份填满用户故事的表格，我可以花几个小时盯着它们，然后又花上几个小时对它们进行讨论…但我总有一种不安的感觉：似乎漏掉了什么东西。当然我知道我不可能毫无遗漏——我只是希望能够感觉更踏实一点。
想一想，当你梳理软件需求范围时，有多少次你曾经忽略掉重要的功能模块？
使用扁平化待办列表是很难制定发布计划的
对我参与过的典型项目而言，用户故事少则几十，多则上百。在开始阶段，我一般会尽量帮助用户让用户故事都处在比较high level的状态，即便是这样待办列表中包含120个左右的用户故事也是很正常的结果。详细分析每一个用户故事并且做出是否采纳的决定是非常乏味的。优先级排序会议在我生命中从来都是一种痛苦的回忆。
构建用户故事地图
让我们把用户故事展示成一个有帮助的形状——一副对我工作很有帮助的，地图。
这确实是一个很简单的想法。一个小的用户故事地图看起来就像这样：
地图的顶层是“大故事”。我称他们为用户活动。活动是由人执行的一个比较大的动作，它包含大量的步骤，虽然并不总是有一个精确地工作流。举个栗子，如果我正在构建一个邮件系统，我会有这样一些活动：“管理邮件”，“配置邮件服务器”，“设置不在办公室自动回复”。
一个关于“活动”的用户故事应该这样读：作为一个顾问，我希望能够管理我的邮件，使我可以与客户，同事和朋友保持联系。
但是活动太大了，很难放入迭代或冲刺中。
这个活动可以被分解成一些用户故事，例如“发送邮件”，“读邮件”，“删除邮件”，“标识垃圾邮件”等。我把这些称为用户任务。对于许多敏捷开发人员来说，任务就是为了完成用户故事所做的事情。事实上，任务是用来达成一个目标的一个步骤。一个用户任务是可以帮助用户达成一个目标，而开发人员的任务是用以完成用户故事的。
我把简单的小的事物（用户任务）安排在大的事物（用户活动）下面，形成成一个网状结构。
我总是想象时间从左往右流动。例如当我在地图中放置用户故事时，如果用户在使用系统时总是按某种顺序执行操作，我总是把先执行的放在左边，后执行的放在右边。对用户活动和用户任务我都是这样处理。
当我传授这种方法时，人们总是告诉我“用户可能按照任何顺序进行操作。我应该按什么顺序在地图上进行摆放呢？”我会问他们“请解释给我听系统是用来做什么的——只需要告诉我用户活动。”他们会列举给我。“那就是正确的顺序”，我会说。事实上，你描述系统行为的顺序就是正确的顺序。我们正在构建一副地图，它让我们能够讲述一个关于系统的真实故事。用可以让你讲故事的方式来构建用户故事地图。
保留你的史诗故事，但不要再使用这个叫法，因为这个术语让我困惑
真正的大故事可以被称作“史诗故事”，就像Mike Cohn那样称呼他们。他们也是故事——一些大到无法估算和构建的故事。当一个史诗故事进入到你的待办列表，就需要详细的讨论，我经常看到人们把史诗故事从待办列表中移除，然后进行分解，把分解出的结果放入待办列表。回忆一下我上面的故事吧：把树砍掉，然后把树叶放入袋子。
大的故事是上下文。它能够让我很快想起用户正在做的完整用户活动，也能够让我很快解释给其他人系统是用来做什么的。
然而，我讨厌“史诗故事”这个词，我认为仅仅使用“管理邮件”——一个从用户视角的基本描述就够了。至少“用户活动”和“用户任务”这样的术语让我清晰的知道他们对应的故事类型。也就是说，我也不喜欢“用户故事”这个词汇，但是我已经慢慢接受它。我仍然会很难面对C-level管理人员的眼睛，当我解释给他听“我们已经把您的系统分解成一系列的史诗故事和用户故事”。如果我这样说，我可以想象他会充满敌意的考虑我的每人天咨询价格。
遍历你的地图进行测试——获得全景图
对着一副组合好的用户故事地图，我能够和用户，开发人员，或者干系人一起遍历地图，并且讲述一个关于用户如何使用系统的故事。我可以只遍历地图的最上层，high-level的描述一下系统。我也可以深入地图对细节进行讨论。
和用户或者其他人遍历地图可以帮助我找到遗漏的内容。我经常从用户那里听到“你在这漏掉了一些步骤”。
我经常在地图上标识出痛点或者机会。当我和用户遍历地图时，我通常会听到“这里确实是系统目前面临的问题”。
和用户一起工作时，他们经常纠正我。昨天我和一个新系统的潜在用户一起工作——她是一个公司的合规官。她一边说，我一边记下流程步骤并且放到地图上。我用绿色卡片记录大的活动，黄色卡片记录小的任务。她迅速纠正我——“不，那个应该使用黄色卡”。在不到一个小时的讨论中，她能够仅仅使用很少的话语就可以提供大量的关于她会如何使用系统的信息。他知道黄色卡片代表的工作比绿色的要小，并且能够告诉我她在系统中做的事情并没有我想象的那么大。
构建和遍历用户故事地图让我比以往任何时候都感到舒适，因为我能够获取信息并且不会遗漏大的事物。
你的软件拥有脊椎和骨架—你的地图把它们显示出来了
我发现地图顶部的卡片看起来有点像脊骨，挂在下面的卡片像肋骨。那些顶部的卡片通常代表系统需要具备的基本能力。我称它们为软件的“脊椎”。
现在该给用户故事排优先级了，我不需要给脊椎排优先级，脊椎的优先级已经排好了。我只给肋骨—那些挂在脊椎下面的故事排优先级。把脊椎摆在最上面意味着他们不可或缺，摆在下面的意味着重要性降低。当你做这件事的时候，你会发现摆在最上面的故事描述了你可以构建的最小可行性系统，它包含了端到端的功能集。我总是试着首先构建出这副地图。
使用脊骨进行计划
现在开始制作发布计划，通常对脊骨进行排序并不重要。例如如果你希望为汽车构建一个high-level待办列表，它看起来像这样：
- 引擎
- 传动系统
- 刹车
- 悬架
…
这似乎是愚蠢的，如果你让干系人对这些进行排序：“哪一个更重要，引擎或者传动系统？”或者“我们在这个发布周期没有足够时间，我们可否先发布没有刹车的汽车？”这些内容都是必要的—我们需要所有的内容去交付一个最小可行性产品（MVP）。
当优先级排序到了更低的层次：4缸引擎或者6缸引擎？是否应该具有防抱死功能？是否要有运动悬挂？这就是我们构建肋骨的过程—对重要的特性进行排序。
当你在用户故事地图上进行优先级排序时，你需要上下移动卡片来表示优先级的高与低。之后，我会用长胶带在故事地图上为每个发布创建泳道，接下来我会在泳道之间上下移动用户故事，甚至改变泳道的高度。
保留故事地图，用以沟通系统的全景
构建用户故事地图可以在开始阶段理解系统需要的功能。问你自己一个问题：你是否需要持续理解系统需要什么样的功能？我知道这不是一个公平的问题，但是我确实发现有些人花费了大量时间整理出类似用户地图的东西，然后把分析结果塞入扁平的待办列表中。如同砍掉了树，然后把树叶塞入了袋子。
我发现用户故事地图就好像一个信息雷达一样，我们总是对着它讨论我们正在构建的产品。当项目正在进行时，它会转化为我们的冲刺板或迭代计划板。我们可以在地图上直接标识出下个迭代要完成的用户故事。在迭代过程中，我们把要完成的用户故事放置到任务墙上管理它们的开发—但是故事地图始终提醒我们系统的全景图是怎样的，我们现在已经走到了哪里。
当我们增量构建软件时，一个故事接着一个故事，我们按照地图上从左到右的，从上到下的顺序。我们慢慢的从左到右的遍历脊骨，从上到下的遍历肋骨。我们并不是每次只构建一个特性，而是同时构建所有的主要特性。就好像我们从不会发布一个没有刹车的汽车。
为老产品增加特性，构建不同的用户故事地图
当为老产品增加特性时，产品已经有了脊骨—足够多的特性已经被发布。我发现识别脊骨依然可以让我有效了解上下文—让我了解新的特性应该被放在什么位置。
对某些项目而言，如果要对一个很大规模的产品增加少量特性时，可能很难和干系人讨论并构建故事地图。这种情况下，我仅仅对新的特性进行优先级排序，然后针对每个特性构建一个小的用户故事地图并对用户故事进行优先级排序。每个小故事地图大约包含10张左右的卡片—但它们仍然按照从左到右，从上到下的方式进行排布，我们应该尽早专注于构建一个小的行走的特性骨架。
这是一种模式—而不是一种发明
虽然我尽量避免，但当有人告诉我这个概念时（一个知名的咨询顾问正在教授这种方法管理待办列表），我依然非常愤怒。“他们窃取了我的方法！”是的，我是这么认为的。但是我不得不提醒自己我也从其他人那里学习了很多类似的东西。我清楚早期在ThoughtWorks工作时，我就已经碰巧看到Luke Barrett正在构建几乎同样的模型。
我总是提醒自己这种方法是一个模式。如果你解释给其他人一个概念，他们说“好酷的想法！”这不是模式。但是如果他们说“我们也在做类似的事情！”这就是模式。因为我经常看到类似的方法，所以这个方法是一种模式。
当教授这个方法时，我喜欢播放Indi Young的用户研究构思模型，模型把用户行为按照从左到右的顺序排列，把特性放置在相关的用户行为的附近。我喜欢Todd Warfel的任务分析网状图，它拥有类似用户故事地图的脊骨，所有用户故事按照优先级排在下面。Todd使用颜色代表优先级，而不是垂直方向的顺序。
本文翻译自Jeff Partton的博客，原文地址：http://jpattonassociates.com/the-new-backlog/
翻译，李强，现任英捷创软（LEANSOFT）资深DevOps顾问和解决方案专家兼市场总监，曾任微软Visual Studio产品资深解决方案专家，IBM Rational产品资深解决方案专家，汇丰中国区软件开发中心CMMI咨询顾问，具有Scrum Master，SAFe，CMMI，PMP和CSQA等资质。
项目经验：
- OPPO敏捷开发及工具平台项目
- 中兴通讯敏
- 捷开发项目
- 远光软件开发过程改进及工具平台项目
- 广发银行ALM项目
- 广州农商行ALM项目
- 四川农信ALM项目
- PICC ALM项目
请关注微信公众号 【devopshub】，获取更多关于DevOps研发运维一体化的信息
