什么是用户故事？

关注公众号

跟Sam一起学需求分析

让你知道需求分析师需要如何成长

━━━━━━

想着改变人类

顺便征服世界

文 |  Sam

敏捷开发在近些年在国内软件开发公司中十分流行，因为它为开发指引了一个方向。而用户故事是敏捷实践中一个十分重要的环节。它能帮助我们高效地收集客户真正的需求。软件开发的起点就是需求收集与分析，就等于建筑中的打地基，基地都没有打好，那建筑物就可想而知了。同时用户故事还带来了一个十分重要的作用，即高效沟通，不论开发团队与客户沟通，还是团队与团队的沟通。沟通使团队成员都朝着同一个方向前进，这意味着更少的错误、风险和成本。用户故事还是敏捷计划估算的重要基础。

软件开发项目失败的原因方方面面，但是需求分析却是被各大行业研究、权威人士讨论或者是我自身经历，都指向该环节为大多数的失败因素。针对该环节多年以来的解决方法，就是使用越来越冗长的文档，尝试用精确的语言来记录越来越细化和具体的全面需求。世界上指定标准的各个组织（PMI、IIBA等）提供了各种文件模板和相应的语言书写规范让大家清楚地定义。数不尽的书籍和文章告诉你怎么用详细的文档描述需求。不知道多少森林因为组织产出的堆积如山的需求文档被看法。即便如此，失败的项目仍然不断地出现而且问题指向的环节仍然是需求分析这一方面。为什么会这样子？

针对这个问题，我们权威专家发现：是不是使用固话呆板的文档及精确想法是错误的方向？

问题出路是否不在复杂而在简单？

解决方法是否不在尽力前期的定义出细节，而在于需求分析及时响应，开发又能随需而动？

是否不在于文档，而在于密切的交流？

讲了那么久用户故事产品的铺垫，我们来讲讲什么是用户故事？

用户故事（英语：User story）是指在软件开发和项目管理中用日常语言或商务用语写成的句子。User Story 是用户需求的简化表达，用一两句话表达完整的想法。User Sotry 只要求写下最有价值不能被忘记的东西，而这些内容足够帮助估算工作量以及与客户沟通。

用户故事由下面三方面组成：

1、一份书面的故事描述。

2、有关故事的对话，用于具体化故事细节。

3、测试，用于表达和编档故事细节且可用于确定故事何时完成。

用户故事描述是以传统的手写在纸质卡片上，用户故事这三个方面可以用三个词总结：

卡片是用户故事最明显的表现，但它不是最重要的。Rachel Davies说过：卡片代表客户需求而不是记录需求。这是对用户故事的最佳诠释：卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在“确认”部份得到记录。

卡片是有客户团队编写，因为她们最了解如何表达需要实现的需求，也因为他们会在后期与开发人员共同确定故事细节并安排故事的优先级顺序。

一个好的用户故事包括三个要素：

1.角色：谁要使用这个功能。

2.功能：需要完成什么样的功能。

3.价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：As a <Role>, I want to <Activity>, so that <Business Value>.

中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>

举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。

理想的用户故事是这样子的：

企业可以发布商品。

用户可以搜索商品。

用户可以使用信用卡付款。

因为用户故事是对用户有价值的功能，以下例子就是不太理想的用户故事：

这个软件将用C++编写。

接口将用微服务实现。

为什么不太理想，因为系统用户根本不关心你用写代码用什么技术细节。之后你可能绝对会说，用微服务是需求之一啊！关键是在于故事应该以对客户有价值的方式写下来，还有其他方法来表示对用户有价值的故事。

这个时候问题来了，需求细节在哪里？？？

说了那么多不就是记录个故事吗，那么系统的细节和某些限制条件在哪里？

对，细节很重要。“用户可以搜索商品”，说起来很简单。这句话如果你说给开发听，可能四十米的大刀都已经在桌子上了。如果下面这个问题应该怎么办呢？

用户可以搜索哪些值？（省份？、城市？、关键字？）

用户必须是网站的注册会员吗？

搜索参数需要保存吗？

要显示哪些与商品匹配的信息？

许多如此这般的细节，我们会在另外的用户故事描述。因为多个小故事远远胜于一个庞大的故事。比如一个电商网站可描述成下面两个故事：

用户可以搜索商品。

公司可以发布商品信息。

很明显，这两个故事太大了，派不上用场。理想的情况是所写的故事能够让程序员让程序员花半天到两周写完代码和完成测试。如果一个故事很大，会被称为史诗故事。史诗故事可以分为两个或更多。例如：

“用户可以搜索商品”可以分成下面几个故事：

用户可以通过地区、价格、生产商、发布日期属性进行搜索工作。

用户可以查询商品的信息。

用户可以查看发布商品的企业详细信息。

但是我们并不需要一直分解故事直到每个故事覆盖每一个细节。例如：“用户可以查看搜索结果中每个商品的信息”这是比较合理和实际的故事。然而不需要再分成下面的小故事：

用户可以查看商品描述

用户可以查看商品价格

用户可以查看商品生产地

用户故事不需要像典型的需求文档样式进行扩充，典型的需求文档是这样描述的：

1、用户可以查看搜索结果中每个商品的信息

1.1用户可以查看商品描述

1.2用户可以查看商品价格

1.3用户可以查看商品生产地

与其这些细节，还不如当这些细节变得重要的时候再和用户讨论。故事并不具有契约意义，没有人会3个月后翻开你写的故事说：“你看我当时这样说过吧。”

故事是可以迭代的，不一定要马上所有细节都先考虑进去！！

为什么要用用户故事？

很多人会问，为什么要用用户故事？而不继续编写需求文档或用例？

理由如下：

1、用户故事强调对话交流而不是交流而不是书面沟通。

2、用户故事可以同时被你和开发人员理解。

用户故事的大小适合于做计划。

用户故事适用于迭代开发。

用户故事鼓励推迟考虑细节，直到你非常清楚客户的需求。

用户故事的简介先说到这里，具体操作需求工具方法接下来我们一步一步说~

乐于推动需求分析师达到行业的标准，也与你分享人生深刻的无趣。

这里有关于对产品经理的小见解，也有关于生活肤浅的快乐

#谢谢你 于千万人中 朝我走来#

#将还你一个不偷懒的人生#