本文内容整理于《用户故事与敏捷开发》，这本书介绍了用户故事的重要价值和实践方法，同时介绍了如何在敏捷开发方法中使用用户故事。

一、什么是用户故事

用户故事描述了对用户有价值的功能。用户故事站在最终用户的立场考虑问题，从用户角度出发描述功能。

以求职网站为例，“用户可以发布新职位”是一个故事，“这个软件用C++语言来编写”则不是一个故事，用户并不关心系统是用什么语言编写的。

完整的用户故事主要由三部分组成：

1）描述：“作为（角色），我想要（功能），以此（商业价值）”，用来做计划和作为提示

2）对话：记录产品经理和开发之间的对话，用于具体化故事细节

3）测试：表达和编档故事细节，用于验证故事是否完成

二、用户故事不是什么

为了更好地理解用户故事是什么，应该了解用户故事不是什么。用户故事与其他三种常见的需求方法产品需求文档、用例和交互设计场景的区分如下。

1.用户故事不是产品需求文档

产品需求文档与用户故事的区别在于：

1）撰写目的不同

需求文档假定事先可以完整定义所有需求，如细节改动被记录为“需求变更”；用户故事的细节在开发前才讨论确定

2）侧重点不同

需求文档是需求列表，是一个check list；用户故事描述用户目标

3）时间成本不同

需求文档成本不可见，撰写文档、需求排期还需额外花费时间；用户故事以故事点为单位，速率估算更直观

2.用户故事不是用例

1）范围不同

用例覆盖的范围比故事范围大，故事会与用例中的某个场景类似

2）完整性不同

故事对应用例的主要成功场景，故事测试对应用例扩展

3）寿命不同

用例常常永久性存在，故事不会超过包含他们的迭代，迭代结束时故事即完结

4）关注用户界面程度不同

用例比较容易包含用户界面，用例编写者会过早地关注软件实现，而不是去关注商业目标；在项目早期，故事会避免过早涉及用户界面，更为关注需求和目标

5）目的不同

用例用来记录客户和开发团队之间的协议；用户故事为了更方便发布计划和迭代计划，充当用户具体需求对话的占位符

3.用户故事不是交互设计场景

交互设计场景包含更多细节，范围通常涵盖多个故事。

三、用户故事的优势在哪里

在开发中使用用户故事具有以下优势：

1）方便多种角色理解

从用户角度出发描述功能，方便与不同角色人员沟通“一个软件系统应该做什么”

2）强调口头沟通

口头沟通便于调整切换需求或开发方向，同时面对面沟通能促进团队内隐性知识的累积

3）鼓励延迟细节

故事作为占位符，可以提醒产品与开发将来需要沟通。快速写出故事可以帮助产品和开发先建立系统整体概念，在开发中再讨论具体故事细节，先整体后局部

4）适合迭代开发

以故事点为单位，方便掌握实现目标所需的时间成本，适合做迭代开发计划

5）鼓励参与设计

用户故事收集和描述方式，可以激发用户积极性，成为软件设计的参与者