用户故事在软件开发过程中被作为“描述需求”的一种表达形式，是定义用户想要什么的简单方法。通过它可以清楚地解释产品。一个好的用户故事能帮助利益相关者理解产品的功能，并且有助于向客户介绍产品是什么。用户故事都会写，但如何写出最贴近用户实际场景的用户故事？
1 ）用户故事基本表达式
为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。
一个完整的用户故事还应该包含以下三个要素：
- 角色（who）：谁要使用这个。
- 活动（what）：要完成什么活动。
- 价值（value）：为什么要这么做，这么做能带来什么价值。
举个例子：“作为一名禅道项目管理软件的用户，我希望看板选择自适应列宽时，不会铺满全屏，这样可以节省空间，操作便捷，在观感上更加美观简洁。”
除了格式规范、要素完整外， 一个好的用户故事还要遵循INVEST原则：
User Story: The INVEST Principle2 ）好故事编写指南
一个好的用户故事可以用简单的语言让每个人都可以理解。让技术和非技术成员都使用它作为交流的媒介。如何编写出一个好的、让人易于理解的优秀故事呢？下面分享几个要点：
- 从目标故事开始
一些大型项目，通常会涉及多个用户角色，这就导致我们有时很难知道从哪里开始识别故事。要想识别故事，首先要 思考每个用户角色，并考虑他们使用本产品的目标是什么。
举个例子，比如开发某招聘网站项目，角色是求职者，TA的目标是找到一份工作（这是主目标）。我们可理解为：有什么功能可以支持TA找到一份工作。然后将其拆解为几个子目标：
a) 搜索TA感兴趣的工作（基于技能、薪资和地点等）。
b) 自动执行搜索，因此不必每次都手动搜索。
c) 让TA的简历可见，以便招聘公司可以搜索到TA。
划分之后，上述的子目标还能根据需要衍生出其他的故事。比如根据定位自动推荐相应区域的岗位，这样故事的撰写就逐渐清晰了起来：
- 编写封闭的故事
封闭故事是指随着故事的实现完成，一个有意义的目标也随之完成，这能让用户觉得TA完成了某件事。
比如，还是招聘网站项目。其中一个故事为“招聘人员可以管理其发布的广告”，这就不是一个封闭故事，因为这是一项持续的活动。怎么编写能更好呢？可以这样：
a) 招聘人员可以更改招聘广告的截至时间。
b) 招聘人员可以删除与职位不匹配的申请等等。
- 故事中要包括用户角色
如果项目团队已经识别出了用户角色，那么在编写故事时就应该使用这些具体的角色，而不是用较为笼统的角色。比如不要写成“用户可以发布自己的简历”，应该写成“求职者可以发布自己的简历”。因为“用户”包含了“岗位发布者”和“求职者”两种，这会增加开发对需求理解的难度。
可以用前面我们提到的表达格式：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。这样就能帮助区分重要的和无价值的故事，也能更加清晰明确。
- 不要过度依赖用户故事
用户故事虽然是一种常见的需求收集和表达方式，但并不是唯一的方式。团队根据项目的具体情况，可以结合其他方法来收集和记录需求，以确保全面和准确地捕捉项目的需求。这样做可以提供更完整的视角，并满足项目的特定需求和要求。
- 为一个用户编写故事
当只为单个用户编写故事时，故事通常更容易被理解和阅读，故事也更加具体和清晰。但并不是所有的故事都会因为用户数量的变化而产生差异。对于很多故事来说，无论是为一个用户还是多个用户编写，故事的内容并没有太大区别。但是，对于某些故事，用户数量的变化可能会对故事产生很大的差异。比如以“求职者可以从网站上删除简历”为例。它就有两种解释：
a) 一个求职者可以删除自己的简历；
b）一个求职者可以删除其他人的简历。
如果我们只考虑一个用户的故事，那么问题就会变得清晰起来。比如可以将故事改为：求职者可以删除自己的简历。
- 使用主动语态
在编写用户故事时用主动语态，而非被动语态，尽可能让故事清晰简洁易懂。比如“简历可以被求职者发布”就可以改为“求职者可以发布简历”。
- 客户编写
在理想状态下，客户应该参与编写故事。客户有责任确定每次迭代的故事优先顺序，所以客户对每个故事的了解至关重要。为了确保客户对故事有充分的了解，可以让客户亲自参与进故事编写，同时也为了避免只由开发人员单独编写故事而导致的理解偏差或误解。
- 不要忘记目的
在编写时，记住故事的目的是为了 促进对话，确保故事能够起到引发对特定功能或需求的讨论和交流的作用。为了达到这个目的，用户故事应该保持简洁明了。
3) 最后
假设“求职者可以搜索未完成的工作”这个故事太大了，不适合一次迭代完成。你会如何拆分它？
