北京这几日的天儿真是好的出奇，白天风和日丽，晚上繁星漫天；在这样一个周六的下午，小编参加了一次北京敏捷社区（微信号：Agile1001）组织的活动：《用户故事地图User Story Mapping 实战工坊》，虽然对用户故事地图是第一次接触，但也有一些小小的体会，回到家中在按捺不住写下来分享给大家。
今天的活动由《百度方法+》发起人，软件工程团队负责人李涛引领大家进行实战体验，他也是《用户故事地图》这本书中文版的译者。
《用户故事地图》这本书的原作者 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）
最终我们绘制出来一个完整的端到端的用户故事。今天的“起床故事”体验中感受最强烈的是：大家专注，目标明确，讨论完成的故事非常完整。
用户故事地图如何衔接开发计划
因为有时间线和卡片放置方式的约束，可以很容易的划分出每个Release所需要完成的需求，如下图：
自上而下，我们可以划分出不同的Release；同时因为每个Release都是和时间线平行的，确保了在放入Release的过程中必须考虑故事的完整性。
小结
今天下午短短的4个小时，对用户故事地图只能说有了一个非常肤浅的了解；个人觉得这是一个非常简单易行的方法，确实能够解决敏捷需求分析/设计阶段的问题。而这，恰恰是Scrum中所缺失的部分。
小编也很喜欢实战工坊的组织形式，很感谢北京敏捷社区的组织者们，这才是用敏捷的方式学习敏捷！
这里也附上北京敏捷社区2016年活动预告，感兴趣的同学自己扫码关注吧。
附上几张照片，让大家也体会一下现场的火爆：
小编在现场也忍不住体验了一把产品经理， 一个字：爽！
推荐这本书大家，封面上这行字道出了用户故事地图的真谛 “洞察真需求，研磨好产品”。不过，此书还未正式出版（应该很快了），大家先不要急着去搜，今天小编在现场也是第一次见到“毛（坯）书”，只可惜没有抢到。索性定了英文原著，待我仔细研读后再和大家分享。
请关注微信公众号 devopshub，获取更多关于DevOps研发运维一体化的信息