背景

最近公司在一个新的领域准备投入研发。前期的概念海报宣传尝试，得到了不错的反馈，感兴趣的客户咨询络绎不绝。这说明市场潜力很大。所以公司希望在年底前能够有一个可以投入市场的可用的产品，尽快验证市场反馈。在这个背景之下，是否业务、BA、Team已经目标一致准备大干一场了呢？我打算用一次用户故事地图工作坊的方式来验证一下。

什么是用户故事地图

用户故事地图是使用可视化方法把你的软件整体需求呈现在你的面前的一个工具。
标准的用户故事分为几个组成部分：

用户(Users)
使用轻量级的用户画像描述用户特点。在地图中可以带入不同用户画像，看是否当前系统能够满足他的目标。
用户任务(User Tasks)
用户故事地图的基本块之一，每一个是用户为了达成某一个目的而使用当前系统的一个主要动作。
叙事流(Narrative Flow)
用户任务可以组合，按照操作或者叙事流程可以从左到右的顺序来走读用户任务，同时讲解用户故事。有时候可能无法完全顺序，中间可能有跳过的步骤，这些都可以在讨论中通过声明来解决。
子任务(Details)
将对应的用户任务进行拆分，可以是子任务；可替换任务；异常处理；甚至可以包括UI设计和一些后台逻辑设计。
用户活动(Activities)
为了达到某个目的，在一相同时间，相同的用户可能会有相同的一组用户任务，给这些任务起一个统一的名字就是用户活动。
主骨架(Backbone)
用户活动和用户任务一起组成了系统级别需求目标，他们构成了当前系统的主流程框架，按照一定的叙事顺序，结合用户角色你是可以讲出来High level的用户故事的。这个框架就是当前系统的主骨架。
Release分片(Release Slice)
根据release计划和MVP(Minimal Viable Product)原则将可以达成的用户故事卡片保留在对应Release分片内。

userstorymap.png

结合上面的元素可以组合出很多用户故事生成迭代期使用的backlog。例如：某个用户，为了达到某个目标，需要根据系统的某个操作步骤，执行一系列的任务来达成。

Tips: Ron Jeffries等人在<极限编程实施>一书中提出了3C原则可以用来作为用户故事的编写原则：

卡片(Card): 在一堆卡片上写下你期望的软件特性
交谈(Conversation)：聚在一起对要开发的软件进行深入讨论
确认(Confirmation)：对完工条件进行确认

感受

这次工作坊一共14个团队成员参与，涵盖开发、测试、BA、业务方，历时2.5个小时的工作坊，经过激烈的讨论，中间有一度小混乱之后，我们这个新产品的用户故事地图终于构建出来了。在这个过程中，作为敏捷教练在一旁引导观察的我有几个感受：

团队对于需求理解实际上没有自己认为的那么好。
就算是各自看了同一份需求文档，大家理解的同一个需求依然会有出入。甚至BA和业务方的理解都是不一样的。
用户故事需要讲出来而不只是写出来，而张开嘴巴讲故事非常需要勇气。
可能是害怕说错，可能是不理解，不过当你能够说出来的时候用户故事地图的神奇作用就会发生了。
MVP是最小可用产品，而它的目的一定是业务方认可的最小有价值的实现。其他自己认为的都不能称之为MVP。
今天和业务方讨论最小MVP的时候业务方的底线居然让团队张大了嘴。很多时候可能我们要达到的MVP比我们自己想的还要简单。
和一群工程师一起做需求减法有点小难。
敏捷12原则中有一句：以简洁为本，它是尽可能减少不必要工作的艺术。在工作中，工程师大多是完美主义者，要给用户最大的灵活度，设计的足够可扩展，而往往这个时候我们回头去看，功能已经臃肿不堪，可用性全无的产品是否能够赢得市场呢？生活中的断舍离，软件开发中的需求减法需要我们更多的思考和魄力。
Outcome 高于 Output
传统开发转向敏捷开发的过程中还有一个是大家需要转变的思想，成果(outcome)高于产出(output)。成果是有价值的、客户想要的东西，而产出的功能只代表你做了什么。Team往往在意产出了多少功能而忽略了我到底提供给客户多少有价值的成果。
用户故事地图和Product Backlog的区别
用户故事地图可以给团队即见树又见森林的能力，而普通的product backlog只能是一维的list。就像下图:树可以表现出用户、故事以及故事之间的关系，树叶是每一个独立的用户故事，而product backlog可能就是将树叶搜集到一个袋子里面。失去了联系，我们的用户故事还能否正确的传递给Team来实现原始的目标呢？
storymap_backlog.jpg
【欢迎关注我的个人博客】