前一篇我介绍了，什么是用户故事，那这一片我们讲，为什么我们要使用用户故事来表达需求，用户故事的应用都是基于敏捷开发的模式。

1. 敏捷开发的需求敏捷化的手段

就职在互联网企业，在一个不大的项目组里，还是个要发挥产品经理主观能动性的产品，你要去探索商业模式，做产品规划，求生存。就先给你一只打火机让你在黑暗中找金矿，你打着打火机只能照亮周围1米，步子不能跨太大，不知道1米外是不是个坑，先跨一步看看，再能跨下一步。

更悲剧的是你的打火机不能一直按着，一直按着烫手啊，还要担心燃气够不够用。只能走走停停，摸摸索索，还要各方求资源补充燃气。

这种环境下，整个团队都在讲小迭代，讲敏捷，同样你必须写用户故事啊。

用户故事的出现使敏捷开发方法覆盖了软件研发中的“需求”环节，是敏捷开发模式中的需求敏捷化的重要手段。敏捷方法诞生十余年到现在我们知道，一个研发团队要想实现完全的敏捷转型光是实现迭代开发过程的敏捷化是不够的，SCRUM和Kanban都无法解决产品需求敏捷化的问题。

而用户故事的诞生，就是为了实现需求的敏捷化。虽然用户故事实践本身还存在一些不足，但是至少到现在我们知道，用户故事是需求敏捷化的基石之一。

Ps：如果你说你们在敏捷开发，但是你从不写用户故事，那怕是你们对敏捷开发有误解，你们做的应该就是单纯的迭代开发，不是敏捷开发。敏捷中重要的一点就是团队达成一致意见，成员都认同要做的事的价值，这是建立在对需求的3W（who、what、why）重复理解和讨论的基础上达成的。传统的需求表述方式只体现了what，无法支撑这种理解和讨论。

2. 贯穿整个产品实现过程

需求评审会之后，进入开发、测试环节，常常能听到的声音是“这个需求当初为什么要这么定？”“我也不知道，产品就这么定的。”

随着时间的推移，可能产品经理自己也会忘记为什么要做这个需求，以及为什么要这么做。这就会造成团队的后劲不足，无法明确自己正在做的事的价值。当一个人对于正在做的事，不知道有何意义时，是痛苦的。

而用户故事能有效的将软件研发过程中的需求环节、开发环节和测试环节有效的连接起来。通过经典的“三段论“描述和渐进的细节探索，用户故事实现了需求描述的敏捷化；通过优先级排序和故事点的有效应用，用户故事实现了需求到开发的连接；通过验收标准的渐进明确，用户故事实现了需求与测试的连接。

可以说，正是有了用户故事这根线，才把软件研发团队的主要的工作环节：需求、开发、测试都有机的串联起来。整个团队成员都明确自己做的事能给团队和客户带来什么价值，形成内驱动。

3. 提高沟通效果

举个需求评审的场景：敏捷开发中，开发、设计、测试等在需求评审时，就会秉着敏捷参与的文化理念，来挑战你的权威，一起怼产品啊，怎能错过如此良机：这个需求谁提的，为什么这么做，做了有什么价值？

一顿舌战群儒后，身心俱疲，开发还是用怀疑的眼光看着你说：“这都是你YY的吧？”

最后，不得已来一句，老板就让这么做的，下周3上线。

但是，你用用户故事的”三段论”作为一个<用户角色>，我想要<完成活动>，以便于<实现价值>，在会前把故事发出去，注意力就是在故事的主人翁上，会中就是大家一起在探索用户场景、路径、给你提供思路，而不是在怼产品。

讲故事不用太在意听故事的人是谁？

用户故事的一个核心在于对话（Conversation），客户和开发人员可以就某个故事深入的交流，对每个重要的细节达成共识。这避免了通过文字记录而可能导致的不精确性或语义多重性的问题。并且向用户或客户显示价值，不涉及专业的技术术语，从而使得用户和开发者理解起来都很容易。

4. 用户故事适合于迭代开发

在开始编码之前，我们并不需要写出所有的用户故事，我们可以写出一部分故事，就开始编码与测试，然后按需求的节奏重复这个过程。在写故事时，也可以按照我们认为合适的粒度去写，正是因为我们很容易对故事本身也进行迭代，所以用户故事很适合迭代开发。

5. 用户故事鼓励延迟细节

我们可以先写出一个起始的目标层面及占位意义的故事，在这个故事再后来对于开发进程变得重要时，才用更多对的细节来代替这个简单的描述。

这很适用于有时间限制的项目。团队可以非常迅速的写出数十个用户故事，让大家对要开发的系统有一个整体的概念，然后先讨论当前时间优先级较高的故事的细节并开始编码，相对于事先完成系统的整体需求文档，大大加快了研发进度。

6. 用户故事传播隐性知识

缘于对面对面沟通的重视，故事能够促进团队内隐性知识的积累。开发人员与客户之间以及他们内部的沟通越密切，越多的隐性只是能得到传播与加强。

补充：了解用户故事的诞生

要了解为什么要用用户故事，还有很重要的一点是，了解它的起源和发展。就像了解一个人，最好的方式就是了解他的成长环境，去他成长的地方，看看塑造他的环境是什么样子的，以及他的经历。

1998年，用户故事首次提出。

用户故事的起源是来自与XP极限编程的计划游戏环节，据现在能够追查的记录，最早是在1998年这样提到“用户故事”的：客户通过用户故事（像用例）来定义项目范围。 XP没有把用户故事作为一个单独的实践来说明，而是作为计划游戏中的一个游戏环节。

在相同时期，另外一个与用户故事对等的词汇“故事卡片”（Story Card）同样被XP提出，有人说其实那时故事卡片的使用频率要高于用户故事。

这是Ron Jeffries提供的1999年C3项目中的一个用户故事实例照片。

• 2001年，用户故事经典句型出世，As a role，I want to …, so that …
• 2001年，用户故事3C要点由Ron Jeffries提出，Card，Conversation，Confirmation
• 2002年，计划扑克发明，以故事点来估算故事的大小。
• 2003年，用户故事INVEST检查表提出，Independent ， Negotiable ，Valuable，Estimable，Small，Testable。
• 2003年，BDD由Dan North提出，它包括验收测试和客户测试驱动等的极限编程的实践。
• 2004年，User Stories Applied 出版，作者Mike Cohn
• 2005年，Mike Cohn发表 “Agile Estimating and Planning”，planning poker开始流行。epic的使用，难以追查是哪年开始的，应当是在2003年以后。theme在用户故事的使用，同样难以追查何时开始，估计也是在2003年以后。
• 2006年，the Given-When-Then template 出现，适合ATDD和BDD
• 2014年，User Story Mapping 出版，作者 Jeff Patton

以Rally和Jira为代表的用户故事管理工具在2005年以后得到了巨大发展。

从用户故事的发展历程可以看出，用户故事的提出和应用，为后来发展的敏捷开发模式奠定了基础，直到现在也是敏捷开发的中需求敏捷化的重要手段。

相关阅读

系列文章目录

用户故事（一）：什么是用户故事？

用户故事（二）：为什么要使用用户故事表达需求？

用户故事（三）：用户故事该怎么写？

本文由 @chun 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。