用户故事在软件开发过程中被作为“形容需要”的一种表达形式，是定义用户想要什么的简略办法。通过它能够分明地解释产品。一个好的用户故事能帮忙利益相关者了解产品的性能，并且有助于向客户介绍产品是什么。用户故事都会写，但如何写出最贴近用户理论场景的用户故事？
1）用户故事根本表达式
为了标准用户故事的表白，便于沟通，用户故事通常的表白格局为：
作为一个 < 用户角色 >, 我想要 < 实现流动 >, 以便于 < 实现价值 >。
一个残缺的用户故事还应该蕴含以下三个因素：
- 角色（who）：谁要应用这个。
- 流动（what）：要实现什么流动。
- 价值（value）：为什么要这么做，这么做能带来什么价值。
举个例子：“作为一名 禅道项目管理软件的用户，我心愿 看板抉择自适应列宽时，不会铺满全屏，这样能够 节俭空间，操作便捷，在观感上更加好看简洁。”
除了格局标准、因素残缺外，一个好的用户故事还要遵循 INVEST 准则：
2）好故事编写指南
一个好的用户故事能够用简略的语言让每个人都能够了解。让技术和非技术成员都应用它作为交换的媒介。如何编写出一个好的、让人易于了解的优良故事呢？上面分享几个要点：
从指标故事开始
一些大型项目，通常会波及多个用户角色，这就导致咱们有时很难晓得从哪里开始辨认故事。要想辨认故事，首先要 思考每个用户角色，并思考他们应用本产品的指标是什么。
举个例子，比方开发某招聘网站我的项目，角色是求职者，TA 的指标是找到一份工作（这是主指标）。咱们可了解为：有什么性能能够反对 TA 找到一份工作。而后将其拆解为几个子目标：
- 搜寻 TA 感兴趣的工作（基于技能、薪资和地点等）。
- 主动执行搜寻，因而不用每次都手动搜寻。
- 让 TA 的简历可见，以便招聘公司能够搜寻到 TA。
划分之后，上述的子目标还能依据须要衍生出其余的故事。比方依据定位主动举荐相应区域的岗位，这样故事的撰写就逐步清晰了起来：
编写关闭的故事
关闭故事是指随着故事的实现实现，一个有意义的指标也随之实现，这能让用户感觉 TA 实现了某件事。
比方，还是招聘网站我的项目。其中一个故事为“招聘人员能够治理其公布的广告”，这就不是一个关闭故事，因为这是一项继续的流动。怎么编写能更好呢？能够这样：
- 招聘人员能够更改招聘广告的截至工夫。
- 招聘人员能够删除与职位不匹配的申请等等。
故事中要包含用户角色
如果我的项目团队曾经辨认出了用户角色，那么 在编写故事时就应该应用这些具体的角色，而不是用较为抽象的角色。比方不要写成“用户能够公布本人的简历”，应该写成“求职者能够公布本人的简历”。因为“用户”蕴含了“岗位发布者”和“求职者”两种，这会减少开发对需要了解的难度。
能够用后面咱们提到的表白格局：作为一个 < 用户角色 >, 我想要 < 实现流动 >, 以便于 < 实现价值 >。 这样就能帮忙辨别重要的和无价值的故事，也能更加清晰明确。
不要适度依赖用户故事
用户故事尽管是一种常见的需要收集和表达方式，但并不是惟一的形式。团队依据我的项目的具体情况，能够联合其余办法来收集和记录需要，以确保全面和精确地捕获我的项目的需要。这样做能够提供更残缺的视角，并满足我的项目的特定需要和要求。
为一个用户编写故事
只为单个用户编写故事时，故事通常更容易被了解和浏览，故事也更加具体和清晰。但并不是所有的故事都会因为用户数量的变动而产生差别。对于很多故事来说，无论是为一个用户还是多个用户编写，故事的内容并没有太大区别。然而，对于某些故事，用户数量的变动可能会对故事产生很大的差别。比方以“求职者能够从网站上删除简历”为例。它就有两种解释：
- 一个求职者能够删除本人的简历；
- 一个求职者能够删除其他人的简历。
如果咱们只思考一个用户的故事，那么问题就会变得清晰起来。比方能够将故事改为：求职者能够删除本人的简历。
应用被动语态
在编写用户故事时用被动语态，而非被动语态，尽可能让故事清晰简洁易懂。比方“简历能够被求职者公布”就能够改为“求职者能够公布简历”。
客户编写
在现实状态下，客户应该参加编写故事。 客户有责任确定每次迭代的故事优先程序，所以客户对每个故事的理解至关重要。为了确保客户对故事有充沛的理解，能够让客户亲自参加进故事编写，同时也为了防止只由开发人员独自编写故事而导致的了解偏差或误会。
不要遗记目标
在编写时，记住故事的目标是为了 促成对话，确保故事可能起到引发对特定性能或需要的探讨和交换的作用。为了达到这个目标，用户故事应该放弃简洁明了。
3) 最初
假如“求职者能够搜寻未实现的工作”这个故事太大了，不适宜一次迭代实现。你会如何拆分它？