在辅导团队实践敏捷的过程中，用户故事的使用经常是面临的第一个问题，也是一个很难解决的棘手问题，究其原因就是很多团队会习惯性把用户故事作为传统需求的代替，认为只是换了一种写法而已，这就导致很多团队表面在跑敏捷，实际上还是在用传统的思路在工作。我们希望能通过这篇文章让你理解敏捷需求管理的基本思路和方法。
文章由两部分构成，用户故事的相关基础知识以及如何使用用户故事地图这个工具来产出用户故事。
前言
首先我们看一下下面这个图，这是对需求再用户 产品 研发之间流动关系的一个抽象描述，描述了产品经理从用户那里获取新的需求或者对已有功能的反馈，作为研发团队的输入，研发团队完成功能开发后提供给用户使用，产品经理收集反馈进一步指导研发的开发工作。无论是传统项目还是敏捷项目这个过程都是一样的，而我们的目的就是促进这个循环关系不断改进和提效。
但是传统项目管理方法在改进这个过程中遇到了不小的困难，我们看一个如下的对话场景：
产品 ：
我这里有个新需求，比较急，你抓紧时间给加一下
小王 ：
好的，没问题，但是能告诉我为什么要加这几个功能吗？想解决用户的什么问题呢？
产品 ：
你做就好了，这个是客户（领导）要求的，一时半会儿也说不清楚，反正需求就是这样
小王 ：
那你能给我讲讲这些功能都给哪些用户使用？
用户在什么情况下会使用这些功能吗？
用户是如何使用这些功能的？
这些功能和用户工作是如何结合的呢？
产品 ：
（看奇葩一样看着小王，不耐烦的说）
需求就是这样的，你照着做就行了，不用问这么多，出了问题我兜着
小王 ： ...
大家可以思考一下是否遇到过类似的问题，我实际工作中就遇到过开发人员只了解一部分自己涉及的东西，甚至对功能谁来用、什么场景用、怎么用都没搞清楚，最后需要业务测试时候才发现从开发到测试都不了解这个系统的使用流程，只是在按照上游输入的信息被动的进行工作，可以想象这种情况下产品的质量。所谓需求很多时候已经变成了命令而非信息传递的载体。
这段对话我分别给产品和研发都看过，我摘抄了几个比较典型的观点列到这里
产品：
- 我很少遇到这么负责的开发，如果真有人这么问我我会非常乐意给他讲的。
- 我们这个系统太复杂，要想让所有开发都搞清楚使用场景和逻辑确实有点困难。
- 需求是从领导和客户那里来的，领导要求了只能照着做，没办法。
研发：
- 我每天加班加点的，哪有时间管这些，让我怎么改就改呗。
- 我有兴趣了解这些信息，但是大家都很忙，也不知道什么时候该问。
- 研发问这些是不是在挑战产品的专业性啊，会不会让产品觉得我在找理由拒绝需求。
大家应该都能感觉这样是有问题的，需求流转过程需要那几个角色之间进行沟通、哪些内容需要沟通、何时沟通、如何沟通、输入是什么、输出是什么不明确导致的。这就是用户故事所希望避免的问题。那么敏捷是如何看到这个问题并解决的呢呢？
敏捷方法论认识到需求的复杂性和易变性，输入的需求并不一定是对的或者最优的，并且想要开发的功能总比可以投入的资源多，所以敏捷会以最小化输出，最大化成果和价值交付为目的， 停止对完美文档的追求，转而通过使用用户故事促进不同角色之间的沟通，确保各角色达成共识。
这里列出了敏捷需需求管理过程会经常出现的一些工具：
用户画像、用户故事、用户故事地图、用户旅程地图、价值流图
由于篇幅关系我们今天不会对这些工具都进行特别细致的说明，我们着重围绕最常使用到的用户故事和用户故事地图来进行说明。
已经有在实践敏捷的同事可能会感觉到，在敏捷团队中我们说的最多的一个词就是用户故事，接下来我们先了解一些用户故事的基础知识。
用户故事
用户故事最早是由极限编程提出来的，后来被Scrum等敏捷实践者所借鉴并流行，现在用户故事的使用已经成了敏捷实践的关键标志，用户故事通过强调从用户角度讲述用户的需要与价值，让团队成员从关注功能到关注价值的转变。
用户故事可以用来描述通过什么来满足特定角色的需求，会为他带来什么价值。它包括三个部分：角色、用户需求、产品价值。我们常常使用三段式来记录用户故事。
作为一个 [用户角色] ,
我想要[结果],
以便[原因/价值]
用户故事3C模型
一般对于刚开始实践敏捷的团队我们建议大家严格按照这个三段式的模式来编写用户故事。为了便于大家理解并掌握用户故事的基本用法，可以按照用户故事的3C模型来使用用户故事。所谓3C模型就是指用于指导使用用户故事的三个以C开头的英文单词，分别是：Card 卡片，Conversation 交谈 ，Confirmation 确认，下面我们分别说明：
卡片（Card）
一般我们会用卡片来记录用户故事的相关信息，用户卡片记录可以方便的挪动、备注、讨论这个故事，不同的人都可以用做标记，做批注，更利于讨论和理解，卡片上描述需要尽量简洁，确保词汇含义统一，项目成员不会对同一描述有差异性理解。
交谈（Conversation）
卡片内容是通过产品、客户、研发等关键角色之间的交谈的记录，是在沟通中获得的，而非由同一个人输出或更新的，否则它与传统的需求分析方法就没什么区别了；项目成员需要在一起共同待开发内容进行讨论，梳理出清晰的脉络，并达成共识。
确认（Confirmation）
每个故事应具有验收标准（验收条件），以达到让各个角色对故事的完成有统一的判断标准，能够基于这些信息来确认故事是否被正确完成。 这些信息是TDD BDD 等工程实践得以正确执行的基础。
基于以上3C模型我们可以描述了一个用户故事产生过程：PO有了一个想法，按照用户故事的三段式讲故事写到一张卡片上，然后PO与相关人一起讲述故事并进行讨论，讨论过程中讲这个故事需要具备的要点进行记录，作为确认故事完成的判定条件。
用户故事示例
这里是一个用户故事的示例，可以看到卡正面是故事描述，左上角是故事编号，这个编号可以作为这个故事关联文档资料的索引线索，中间的黑体是故事标题，我们日常站会、讨论提到这个故事的时候一般都会通过标题来指代这个故事卡，所以这个标题既要简洁又要能明确表明这个故事的内容。正文部分是故事的内容描述，这里采用的是三段式写法。
右侧这个图是卡片的背面，这里列出了这个故事的几个验收标准，验收标准一般会描述在什么情况下做了什么操作得到了什么结果或反馈。大家需要注意，这里的验收标准是用户视角的验收标准，用于统一用户、PO、开发团队对这个故事最终的完成标准的理解。
Acceptance Criteria
Given 在什么情景或条件下
When 做了什么操作或采取了什么行动
Then 得到了什么结果
一般AC会由团队共同完成，由PO和用户做最终确认。如果有条件我们也建议由潜在的开发人员来编写，这样做的好处是促使更广泛的针对故事的交流与沟通。
用户故事是另一种需求的书写形式吗？
用户故事是不是只是另一种需求形式呢？只是换一个名字还是有什么不同吗？
这个问题是初入敏捷实践的人最容易产生的疑惑，也是最容易陷入的误区，如果你们正在实践敏捷，并且你们的故事是由产品人员闷头写出来的，那么很可能你们只是把用户故事当成了另一种需求写法，而且是十分不好用的写法，因为用户故事本身能承载的信息十分有限，而往往需求想表达的内容又十分繁杂。
用户故事并不简单的只是一种新的书写需求的方式，用户故事最主要作用是让不同角色的人通过一起讲述用户故事， 过程通过使用文字，图片，白板等方式进行讨论，最终达成共识。
用户故事本身也不能认为是一种需求，他可以看作是一个索引卡，代表了一系列关于卡片上问题解决方案的讨论、结论。
一个好的用户故事应该讨论为谁做和为什么做，而不仅仅是做什么和怎么做，对于故事卡来说，重要的不是卡片上写了什么，而是看到卡片时候能想到什么。
总结
希望大家至少记住下面这句话：用户故事并不简单的只是一种新的书写需求的方式，用户故事最主要作用是让不同角色的人通过一起讲述用户故事， 过程通过使用文字，图片，白板等方式进行讨论，最终达成共识。用户故事本身也不能认为是一种需求，他可以看作是一个索引卡，代表了一系列关于卡片上问题解决方案的讨论、结论、关联的文档等。一个好的用户故事应该讨论为谁做和为什么做，而不仅仅是做什么和怎么做，对于故事卡来说，重要的不是卡片上写了什么，而是看到卡片时候能想到什么。
说了这么多，那么如果现在我在面临一个项目，我该如何去产出用户故事呢？我应该做什么准备？我应该从哪儿入手，到哪儿结束呢？下一篇我们来介绍一个完整的用户故事产生的过程。
