这是鼎叔的第八十五篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），各大电商平台热销中，30 万字 350 页，“阅读原文” 有官方购买链接。
相关上文：聊聊测试左移到需求阶段https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484386&idx=1&sn=219bd680bdd83246517871b47da0a7a8&chksm=c24fb680f5383f96f014111f7bed4135b5c0b7dbce9cb990029e44a5cf931bbe847559804136&scene=21#wechat_redirect

主要的用户故事场景，就是测试应优先关注的覆盖场景。本文就聊聊用户故事场景的脑爆梳理方法：用户故事地图。相关理论来自 Jeff Patton。

常规的需求拆分手法，很容易让人忘掉软件需求的全景图，用户故事地图则是一个生动的全景故事挖掘活动，参加者不限于产品经理和设计师，也可以包括开发，测试，运营，业务代表。鼎叔曾参加了两次用户故事地图的工作坊，花了两三个小时完成了 “早上起床做什么” 的故事地图设计及讨论，印象还挺深刻。

用户故事的目的就是在协作中更好地达成共识，它比单纯描述事实的效率高很多倍，它也不是需求分析，后者目标是精确构建软件结构。因此，用户故事使用视觉方式是一个非常自然的结果，它为开发和设计之间建立桥梁。敏捷文档就应该做成类似度假照片/视频的回忆录。

好的用户故事讨论，是讨论为谁做，和为什么做（怎么做能让世界更美好），而不是只讨论做什么。最终我们希望用最小化的输出，来最大化成果及其影响力。

用户故事卡片很适合边讲边记，讲的时候工程师可充分利用肢体语言，并能灵活移动卡片的摆放顺序。

随着梳理出来的用户故事卡片越来越多，我们可以按照一定的时间先后顺序（横向）和必要程度（纵向）进行排列梳理，形成一张用户故事地图。即从左到右讲述故事，自顶向下拆分细节。

地图中的用户活动，是指的相似的人在相似时间完成的任务集合，它沟通了用户故事地图的主干脉络。

我们可以把用户故事的相应界面草图和其他注释，放在这个故事卡片的周边。故事卡的内容标签可以尽量生动，比如痛点、乐趣和奖励、问题、创意，鼓励多放照片而不仅靠文字。

借助创建用户故事地图的头脑风暴活动，我们可以对产品需求的价值及发生场景更加明晰。这是一场让用户需求变成 “正好、更好、最好” 的故事分解游戏。

我们应该从整体团队视角，展示不同卡片故事的依赖关系。粗看起来参与脑爆的人让卡片越来越多，但这不代表需求范围被延伸了，而是我们对需求的理解更加深刻了。

我们还会对现实成果排列优先级，而不是只从一个个功能本身排列优先级。具体功能的优先级建议这么排序：差异化功能（代表了产品的竞争优势），搅局功能（叫板领先的对手），降成本功能，基础功能（这是我们入场竞争的筹码）。参考文章聊聊竞品体验对比评测（上）

产品负责人（PO）也会根据必要程度把梳理出来的用户故事分批纳入不同的发布（release）版本计划。

PO 应聚焦预期发布成果来决定系统内需要什么功能，用分割线划分出发布版本和路线路，这也体现了产品对现实世界产生的价值。通常前三个迭代版本可以这么划分：see it work（必备的主流程），make it better（周边功能，提高质量，增加风险故事 - 把风险可视化），make it releasable（为发布打磨细节，看到抢眼的效果，关注真实用户数据反馈）。

整个脑爆团队围绕产品故事的交流，从讨论具象的机会开始，验证要解决的问题是否存在。注意：用户不一定是他想要的产品的使用者。最佳的问题解决方案，来自需要解决问题的人，和有能力解决这些问题的人彼此协作。

图片

团队具体可以从以下三点进行梳理和交流。

1) 用户类型分析：主要有哪几类典型用户，按什么属性能清晰区分？每一类用户使用产品（需求）的主要场景（差异化场景）在哪里？该类用户是如何在使用中获得满足感的（实现想要的价值）？

2) 这几类用户的占比如何？行为习惯和关注点有什么差异？是否有调研数据支撑这点？这会成为我们判断场景优先级的参考。

3) 关注用户故事场景地图中的 “风险区域”。某些用户功能面临很多样的分支路径，需要进一步拆解为多个子场景；也有一些场景的预期响应结果难以判断，需要进一步地剖析。我们从地图中会发现，这些有待挖掘的 “麻烦” 通常会集中在地图中的特定功能区域，这个区域既是产品设计的难点，也是质量验收的难点。

以 “手机管家 App 产品” 作为例子，最早的产品主打功能是安全，防范手机木马病毒，但在实际运营和对用户行为的洞察中，发现传统安全的场景占比很低，而反骚扰、隐私保护等 “泛安全” 的需求更为迫切。于是产品的需求重心向泛安全演化，相应的测试体系内容也发生很大变化，从木马病毒的识别，转换为以骚扰拦截效果，隐私漏洞等为高优先级。

图片

随着产品用户进一步的扩展，为了突破价值瓶颈，手机管家的重心放到了更高频的用户需求 - 手机空间管理（瘦身功能），因为空间占用越来越快且大容量手机价格昂贵，相关体验和精细化需求持续升级。测试策略和自动化建设的重心自然也发生变换，安全类功能就变成以稳定运营为主的模块，而团队在瘦身效果评测、微信等空间占用大户的专项清理等场景，投入了更多的测试精力，确保用户价值——“清理要快，空间释放足够大，重要信息不误删” 这三项指标达到设计预期。

在地图集体脑暴中要注意的系列技巧：

1 不要从自己而非真实用户角度出发来思考

2 对于异地脑爆，可以借助远程工具让两地看板卡片能同步移动。

3 如果参与的人比较多，可以采用少数人（不超过 5 人）集中讨论用户故事，再分享出去。讨论过程采取金鱼缸协作模式，没有跳入讨论的人只能默默观察，出去一人才能进来一人参与讨论。

4 我们可以交付半个烤好的蛋糕，但不能交付一整个半熟的蛋糕。因此，用户故事要有完整的使用价值。

5 用户故事中会存在一些特别巨大的故事，如果我们像行星战机一样急着射碎巨石，碎裂的石头会让主角死得更惨。相反，我们可以把不重要的一类小故事（碎石）聚集成一张新卡片，暂时无需讨论它。

6 发散讨论完，我们还可以做一个收敛的讨论过程，把彼此关联的一组故事聚合在一个主题下，以方便集中解决一个商业机会。一个机会是否值得现在解决，还是延迟解决，我们主要基于这几个要素的讨论：对象是谁、解决什么问题，构想是怎样的，为什么，工作量大小。

7 地图脑爆团队是多样化的探索团队，主要角色是 PO，UED/UX 专家，技术专家，决定最终设计是看 feasible、valuable、usable，而不是看民主投票，我们和用户不是乙方和甲方的关系。

8 用户故事地图也不一定要一次完成，也可以再次改进。我们拿出初版的地图展示，邀请让其他人针对疏漏提问，或者扮演不同的用户角色，排练这个时间轴上的用户活动，甚至让大家打散所有卡片重新组成地图。这个时候可以让旁边的观察者进行提问，最终巩固大家的共识。

9 从用户故事地图的脑爆，到最终的产品设计方案，需要良好的设计思维。设计者需要和用户共情，把产品的定义聚焦，形成关键想法，进而绘制原型图，并拿给干系人和目标用户进行测试。这个测试过程要避免仅仅邀请专业人士，避免强势否定，并合理控制成本。

迭代完成后：

为了自我学习，我们应该在迭代结束时进行回顾，从产品、设计和过程三个要素找到下一周期能进行的 “小改变”，并承诺要达成，再对用户活动进行评分和反思。等产品真正发布后，我们的改进就更有价值了。这种验证性的学习胜过 “可以工作的软件” 和 “面面俱到的文档 “。

结语：

伟大的产品永远没有 “完成” 这回事。我们做的用户故事地图和持续的规划，就像海平面任务一样，连贯完成且不会中断。