最近在给几个客户的培训和辅导中，都用到了用户故事地图(User Story Mapping or USM)，越来越发现USM是一个强大的工具。USM有它特殊的妙用之处和适用范围，我们不用指望USM能解决多的问题，比如产品架构和用户体验旅程就不在USM的范围。我还是有一种强烈的意愿想把用户故事地图USM推荐给PO和SM或敏捷教练，静下心来写一篇短文，与大家共勉。

记得早在2016年11月，清华出版社准备发布Jeff Patton的《用户故事地图》中文一书之前，文开琪老师和上海敏捷社区的核心成员组织了一场工作坊，译者李涛分享了本书的精华，大家都觉得USM很实用。后来我的CSPO课件加上了USM演练，学员敏捷工具箱里多了一个工具。

我认为，用户故事地图最重要的贡献，就是把Scrum框架下的最重要的工件，一维的产品待办列表变成了二维，原来的产品待办列表(flat product backlog)只见树木，不见森林。

用户故事地图到底是什么？用户故事地图是从一个典型用户的视角开始，围绕一个大的目标，从左到右列出用户为达到目标需要实施的每个步骤(steps)，多个步骤聚集成一个活动(Activity)。

参考下图电商平台系统所示：

用户活动就是主干(backbone)，USM的一些术语定义如下。

这些定义和术语并不重要，也不用太纠结和区分，实际上就是考虑两个维度：任务的宽度和深度，宽度是不同功能的排列。首先要识别基本的功能，不要忽略或漏掉，先专注宽度的讨论，引用Jeff的原话“go a kilometer wide and a centimeter deep”。USM的一个好处是对于某特定的用户，保证功能完整不缺失。深度是对一个功能的细化和优先级排序，包括用户任务或子任务的多个变化的实现，替换方法，异常情况等细节。通常情况下，我们会习惯花费很多时间在这个维度上讨论，过于细节化，反而会忽视横向基本功能是否完整。当然，有时候要用便签标注“需要研究“，“开口问题”或“有差异”。以避免讨论走的太远，能够刹车。后续可安排follow-up session，邀请相关人员讨论细节。比如产品待办列表的梳理(PBR)活动，估算大小，分解细节，Kano方法投票优先级等等 。

USM是规模化敏捷(Scaling)的一个非常有效的工具，它把业务，开发，干系人拉在一起，做半天或一天的工作坊，正是多团队的参与，相互检查，避免出现功能漏洞(hole)，包括第三方单位的协作和支持。横向维度的步骤，不同功能的依赖关系容易看出来，但团队之间的依赖需要讨论，识别并在用户故事地图上可视化出来。

用户故事地图的工作坊设计，有经验的引导师引导，控制对细节的力度，同时要做好充分的准备工作。

用户故事地图能解决哪些产品开发中经常碰到的问题？有哪些好处？

（1）系统思考，展示一个大全貌（A Big whole picture）。

传统开发团队成员面临最大的一个困境是，每天疲于埋头开发功能和完成任务，抱怨看不到一个产品或项目整体的全貌和架构，工作没有尽头和动力，即没有目标感和成就感。

那些还没有被“麻木”的工程师，即不被业务人员强势所左右，不被商业合同所束缚的新生一代，开始寻思：这些无休止加班加点开发的或即将开发的功能，客户真的会用吗？反问业务，要开发什么？为谁，为什么？这几年人们炒得很火频度很高的一个词汇---“价值”，开发以目标为导向，客户为中心。

USM从产品愿景出发，框定问题，是给谁的？我们为什么要构造它？特别是对复杂的产品，系统或服务。我们都熟悉规模化敏捷的框架，比如SAFe或LeSS，但涉及到多团队参与的敏捷开发，如何去创建一个发布计划，Scrum指南也没有描述。USM让每一个开发人员开始关注和理解业务，在项目初期看到一个高阶计划和一个全貌图；PO把握产品方向和目标，SM利用USM工具引导实践落地。实际操作中，也可以先做设计思维(DT)，再做USM的练习，然后是产品待办列表的梳理活动(PBR)。

如果你有机会观看TED视频“如何烤土司(how to make a toast)”，用户故事地图的活动背后是系统思考的过程。一群人，不同的背景，围绕一个目标和问题，针对某一类典型用户，头脑风暴讨论解决方案。对话的发生和思想火花的碰撞是USM的核心。卡片的形式，简洁方便，挪动灵活。

ShineScrum捷行

，赞7

(视频：how to make a toast)

（2）增量式的发布计划，使需求范围管理可控。

我们发现一个不争事实，比起有限的人力资源、时间或金钱，人们总是期待有更多的东西开发构建。我们过多关注功能的开发(output)，忽视目标或成果(outcome)，用户故事地图的“横向切一刀”的策略(见下图灰色胶带)，是非常聪明的一步。

这一“刀”，帮助我们解决了以下问题：

• MVP概念在USM中妥妥落地了。MVP帮助我们识别最大的假设和风险，花最低的成本和最短的时间去实验或测试产品的想法，以期达到学习的目的。MVP与USM的第一级用户故事不谋而合，它们组成了用户故事地图发布版本1的第一次切片(slice) -- “行走的骨架” (functional walking skeleton)，检测系统基本功能是否工作，就是MVP的具体应用。 

• 增量式的发布策略和预算管理。(参见我的敏捷发布和预算一文)。即使是只有一个官方版本的发布，也要有开局(open game)，中盘(middle game)，收尾(close game)的开发策略。开局部分多关注风险和技术挑战。

• 产品路线图，每个发布的目标是对产品目标的分解和分步实现，敏捷产品的路线图与传统的产品路线图有非常大的不同，这里暂不讨论。

• 需求范围可控，参与USM讨论的成员都非常清晰，我们在不同的发布层面上聊眼前的或是未来的需求，不用担心需求丢失或被忽视。要注意的是，USM只是一个时间点的快照(snapshot)，它在不停演进和更新，并不是一成不变。

总之，尽管Scrum框架没有提及发布计划的具体操作，USM作为一个模式语言(Pattern)正好给与补充。  

（3）“共创”的过程，人人都参与。

一个优秀产品的打造，过程要重于结果。USM这个工具，提供我们一个非常可操作的步骤“支撑”这个过程。回到现实，组织中的研发和业务通常有部门墙，两张“皮”，貌合神离，互相扯皮。在时机和勇气不具备对组织架构做“手术”的情况下，部门墙存在和甲乙方不平等的关系，USM或许是”Bring People Together”最好的方式之一。不同的产品，USM活动通常一个季度做一次，不需要每周都做。

这让我想起了几年前做过一天USM的工作坊，业务人员在广州，交付的外包团队在上海，甲方的项目经理是一个“光杆司令”。当时把业务人员请到上海，成本确实很高，用他们的话说，这样做“太奢侈”了。这个外包团队签的是固定报价合同，人员不稳定，合作三年，业务和研发外包团队从来没有见过面。这一次USM工作坊算是破天荒，下了决心，停工一天，没有一行代码输出，但结果非常让人兴奋：特别是外包交付团队，终于有机会与业务面对面的对话，不像过去，要么靠文档传递需求，要么依赖项目经理的理解来解读，要么就由开发人员“猜测”。可以想象，这里面有多少误解，有多少返工和浪费，一天的差旅成本是容易度量的；没有人算这个账，产品开发过程中开发对业务理解的不对称会带来更大的浪费。就其原由，根因是大家只看自己碗里的东西，没有一个共同的目标对齐和驱动，这个目标就是产品的目标。

USM正好补缺了在传统组织架构下人们沟通和做事的方式，工作坊的形式事件(event)优于传统的会议(meeting)和报告。

研发通过对话理解业务需求和场景，业务确认研发对需求的验收标准。USM中的用户故事卡片，就是围绕USM最上面活动的目标，分解成不同的子任务(sub-task)去实现。对话的过程就是双方对需求理解达成共识的过程，也是共创的过程。这种工作氛围下，双方是平等和开放的对话。从不同的维度和视角，依据自己的理解，贡献自己的想法, 包括：市场和销售，业务，开发，测试，架构，UI/UX，用户和客户，IT和运维，人人都参与，大家都是产品团队的一员，这才是现代的工作方式，也是我们倡导和追求的。

写此短文，只是对USM话题开个引子，欢迎大家讨论。如何具体通过工作坊的形式去组织和引导USM，我邀请大家参加近期的CSPO课程体验USM，期待后续有机会在企业内部实操，围绕一个产品来让团队实际演练，熟悉和掌握USM的精髓，使敏捷企业早早受益。 

Jim Wang王军 

写于2022年11月25日

参考资料：

（1） CSPO教材

（2） 《User Story Mapping》by Jeff Patton

（3） http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html