背景

某公司在二手房交易平台项目中采用了敏捷开发模式，项目的一个需求为通过输入关键字可以为用户检索对应的房源信息。产品经理将这个需求编写成用户故事如下：

“我想通过输入一些词，查询相关的房源信息”

开发团队拿到用户故事后，有很多疑问：

• 输入的信息包含哪些？

• 搜索完成后，给用户展示什么信息？

• 在展示效果上，只做一个查询房源信息的搜索框，能否满足用户需求？

• 这条用户故事要实现得价值是什么？

很多团队都遇到过这样的情况。

用户故事可以帮助开发人员更好的理解需求，让开发人员形成以用户为中心的思维模式，从而开发出更符合用户期望的产品。那么应该如何有效的编写一个用户故事呢？

问题分析

什么是用户故事

分析问题之前，我们先了解下用户故事。用户故事维基百科给出的定义是：

“In software development and product management, a user story is an informal, natural language description of one or more features of a software system.”

即在软件开发和产品管理过程中，对系统的一个或多个功能进行非正式，自然的语言描述。用户故事是为了表述用户渴望的功能和价值。

与需求规格说明书对比

同样是用来记录需求，用户故事和传统的需求规格说明书有什么差别呢？

需求规格说明书是软件开发过程的范围标准，通常会很正式客观的说明系统需求范围，功能实现要点等，说明书的好处是可以让产品完全符合约定规范，达到交付标准；但是说明书要求做到的和客户内心期望的可能并不一样，比如：说明书中写“产品logo是黑豹”，产品经理是一个漫威粉丝，他希望产品logo是漫威的黑豹；只看说明书，很难看出产品经理的真实需求，于是研发人员就画了一个动物黑豹作为logo；从结果来看，按照说明书做出的产品与用户期望之间存在着很大偏差。

用户故事通常比较短小，其核心是围绕用户期望的价值；它不像说明书那样事无巨细的记录下产品想要实现的功能，而是提醒研发人员正在开发或者待开发的功能要实现什么价值（理论上，用户故事应该由用户或用户代理如产品经理录入）。

用户故事的三要素为角色、功能、价值，编写用户的通用模板如下：

“作为一个<角色>, 我想要通过 <功能>, 以便于实现 <价值>。”

使用用户故事来写描述刚才的需求可能就会写成，“作为产品经理，我想制作一个黑豹的logo，以便于利用漫威品牌去吸引用户。”研发人员通过用户故事的“价值”，可以知道这个logo应该是漫威的人物；如果不知道，也可以去问产品经理，这豹子和漫威有啥关系，经过产品经理解释，需求也可以被正确理解（体现了用户故事“可以商讨的”的原则），简而言之，需求规格说明书强调：“功能”，而用户故事比起“功能”更注重“价值”。

根本原因

了解了上述信息，再看背景中用户故事存在的问题。这条故事虽然有用户故事的样子，但是本质上更像一条需求说明——没有体现用户期望的价值，它只写了“作为 一个<角色>, 我想要通过 <功能>”，没有后半部分的“以便于实现 <价值>”， 所以这条用户故事不合格的根本原因是没有体现价值，这是一条无效的用户故事。这种无效的用户故事一方面会导致研发人员很难理解需求要实现的目的，做出的产品令用户不满意；另一方面，这个用户故事写的太粗略，研发人员不知道从哪下手。

无效的用户故事只是一种形式，对需求澄清起到的作用微乎其微。接下来看下合格的用户故事应该怎么写。

解决措施

要写好用户故事，首先应该了解用户故事的必备条件，或者说用户故事的原则。

用户故事的原则

一个用户故事通常具备6个原则：独立的（Independent），可以商讨的（Negotiable），有价值的（Valuable），可以估计的（Estimatable），合适的小（Small），可测试的（Testable），6个原则取英文首字母会组成一个单词“INVEST”，所以用户故事的6个原则也被称为“INVEST原则”。

独立的（Independent）：避免故事之间的依赖；这样做的好处是便于故事优先级排序以及估算。

A故事：“作为购房者，我想要通过学区搜索房源，以便买到学区房，方便孩子上学”，B故事“作为购房者，我想要通过学校名称搜索房源，以便于生活在有文化气息的地方”，一定程度上来说，B故事对A故事有依赖，学校的范围包含学区内的公立学校外，还有学区外的私立学校和大学等。如果A故事需要1天，B故事需要3天，总体估算两个故事完成应该是4天，可是A故事完成后，B故事相当于完成了一部分，最后B故事可能只需要2天就完成了；而且本来优先级相同的两个故事，A故事优先级无形之中提高了。用户故事之间的依赖会让估算不准确，即不符合“独立的”原则；

想解决这个问题，我们可以对故事重新划分，比如：重新划分成三个故事：“作为购房者，我想要通过私立学校名称搜索房源，以便于孩子将来得到不一样的教育”，“作为购房者，我想要通过大学名称搜索房源，以便于生活的地方有文化气息”，“作为购房者，我想要通过学区搜索房源，以便买到学区房，方便孩子上学”，这样故事之间就没有耦合性，每个故事都是独立的，便于优先级排序和估算故事点。

可以商讨的（Negotiable）：用户故事只提供适量信息，让开发人员和用户（产品经理）针对一些细节进行讨论；

“作为购房者，我想要通过学校名称搜索房源，以便于生活的地方有文化气息 ”，常规理解，这条需求包含：小学，中学，那大学是否包含呢，这样就形成了讨论性。这种情况我们可以在故事中加一段注释：“注释：包含小学，中学，是否包含大学待确认”。与客户的讨论过程在可能会挖掘新的需求，比如艺术学校等。

用户故事注释不建议写的面面俱到，因为会减少故事的可商讨性。

有价值的（Valuable）：敏捷开发以价值为导向，所以故事应该体现对用户的价值。

“有价值的”原则在问题分析里面已经做了部分解释；还有一种情况“作为研发人员，我希望给后台数据库创建XX表，以便于我实现XX模块的功能”，这条用户故事看似ok，但实际上该用户故事只对研发人员有价值，换句话说用户不关心后台表结构，只关心系统是否可用，所以这条故事不符合“有价值的”原则。

技术实现方面的需求可以适当转化成对用户有价值的故事，或者把它作为“作为购房者，我希望通过XX功能，以便于实现XX价值”这条故事下面的一个Task。

可以估计的（Estimatable）：每个故事都应该可以估算出故事点，以便于对个人工作量以及团队速率进行估算；一个用户故事估算的工作量不能超过一个迭代，如果故事太大难以估算，可以将大的故事进行分解，分解成多个小的可估算的故事。

“作为购房者，我需要按交通线路搜索房源，以便于找到方便搭乘公共交通的房源”，公共交通种类繁多：公交，地铁，轻轨等，假设实现每种交通工具搜索需要4天，要一下子实现这个故事至少需要12天，一个迭代开发不完，这不符合“可以估计的”的原则。

针对这种情况，我们可以将这个大的故事拆分成三个小的用户故事，每种交通工具分别对应一个故事，这样一个故事就是4天，就符合了“可估计的”原则。

合适的小（Small）：故事分解的小，便于估算也便于交付，但是如果故事分解的太小，以至于难以估算故事点，就需要对多个实现共同功能的小故事进行整合。

“作为购房者，我希望搜索框背景是红色，以便于我可以更好的找到搜索框”这种用户故事工作量很难估算，可能少至十分钟，多则半小时就完成了；如果迭代中有很多这种小的故事，那对于整体速率估算是非常不利的。

小故事可以和其他故事进行整合，形成可估算大小的故事；或者将小故事作为一个Task挂到其他类似用户故事下。

可测试的（Testable）：用户故事必须要有一个明确的完成标准，以判断开发的功能是否满足用户期望。

“作为购房者，我希望搜索到大房子，以便于我和父母孩子居住”，“大房子”是一个模糊的概念，面积90㎡还是140㎡算大房子？是不是三室两厅就符合条件？这种用户故事很难进行验收，也不符合“可测试的”原则。

正确描述是：“作为购房者，我希望搜索到90㎡以上，三室两厅的房子，以便于我和父母孩子居住”这样标准就清晰很多，评审会议时也好判断功能是否符合用户期望。

用户角色

好的用户故事除了满足它的基本原则，还应该考虑一个问题：对于不同的“角色”，实现同样“价值”所需要的“功能”是否也不同？

我们来对比两个用户故事：“作为购房者，我想要通过总房款的范围搜索房源，以便于找到我能买的起的房子”和“作为月薪5000，手头有30万存款的职场新人，我想要通过总房款的范围搜索房源，来确定我能负担得起的房子”，开发相同的“通过总房款范围搜索房源”功能，前者需求描述比较模糊：在搜索栏中输入比如100万，然后展示100万左右的房源信息？100万左右的“左”和“右”分别是多少？按这个需求做出来的产品，很大概率是模棱两可的产品，也很难被用户认可；而且在这个用户故事中，“角色”并没有起到该有的作用；第二个故事相对就好很多：30万做首付， 5000月薪可以作为月供的参考，通过这些参数可以大概的推测出总房款的范围，这个范围也可以作为这类人预算的参考；再深一点考虑：房屋总价做成可选区间，代替从搜索栏输入，也许用户体验会更好。由此可见，如果对用户角色进行细致划分能起到意想不到的效果。

敏捷以用户为中心，不了解用户就无法掌握用户真正期待的价值。而研发时每个人对用户的理解是不同的，用户角色可以帮助团队形成统一的用户形象，研发人员可以聚焦目标用户，重点挖掘该角色需要的价值；同时使用用户角色会更有代入感，便于研发人员站在用户角度去实现产品该有的价值。

用户角色可以通过头脑风暴或其他形式进行识别：按实际需求对用户群体进行细致分类；分类完成后，对有共性的用户适量整合形成具有代表性的用户。比如，对于购房者我们头脑风暴后，可能形成如下群体：年轻人，中年人，老年人，每个群体自身条件和期望都会有差异。

年轻人群体中大多数个体财富积累较少，上班时间早，从他们角度会写出特定的用户故事，比如：“在市中心上班的小王，想要通过地跌线路搜索房源，以便于解决上班堵车导致迟到的问题”，要怎么做，为什么这样做，一目了然。

同样对于已经成家的中年人，可能更关注孩子的教育（学区）；对于老年人群体，可能更关注附近是否有菜市场便于买菜，是否有公园便于日常锻炼，从这些群体的角度出发，搜索功能会形成不一样的用户故事。

还应该想到一些极端情况，比如：“作为一个事业有成的企业家，我想要在空气清新的郊区买一个独栋别墅，以满足私人会谈和休假”，所以房源类型是别墅还是普通住宅也要考虑。

接下来看一个例子。

实例操作

用户故事通常以手写的方式写在纸质卡片上，但是纸质卡片很难提供准确的数据用来进行相关分析，所以现在很多企业都选择使用电子卡片。

华为云DevCloud是基于敏捷思想设计的DevOps研发平台，接下来在华为云DevCloud中写几个规范的用户故事，故事呈现的需求是背景提到的搜索功能。

首先对年轻的上班族群体进行需求划分，比如有些年轻人工作单位在市中心，市中心房子太贵，离市中心稍微远一点开车或坐公交时间不可控（容易堵车），所以他们希望按照地铁线路搜索房源，以解决上班迟到的问题。用户角色就是：早晨八点要到单位（单位位置在市中心）的小王，小王想要做的事是：在这个网站里通过地铁线路搜索地铁站附近的房源信息，他这样做的目的是为了减少上班迟到的风险，写成用户故事：

Tips：华为云DevCloud支持填写故事的各种属性，比如所属迭代，优先级，估算工时，故事点等。

通过规范的用户故事，研发人员发现原来用户想要的搜索并不是无目的的搜索，而是想找到和自己特定需求相匹配的房源，如果在搜索框基础上，加上若干CheckBox会更有利于用户搜索，最后产品搜索页面如下。

总结

站在不同用户的角度，遵循用户故事的“INVEST”原则，可以更深层次的挖掘用户的需求，写出更有效的用户故事。

参考附录

Mike Cohn:用户故事与敏捷方法.北京：清华大学出版社

文章论坛地址：【DevCloud · 敏捷智库】“用户故事等于需求说明”——你一定没有写好用户故事