用户故事和需求之间有什么区别？

虽然大多数新功能都应该从用户的角度来定义，但在实践中，当定义开发团队需要构建的需求时，我们常常忽略了用户角度的“为什么”。用户故事的重点在于体验——使用产品的人想要实现什么。传统需求则关注功能——产品应该做什么。其余的区别在于那些微妙但至关重要的“谁”、“如何”和“何时”列表。

用户故事应写成一到两句话，涵盖用户是谁、他们想要什么以及为什么。定义功能或用户故事的简单结构如下：

作为一个______，我想要______，以便我可以______。

示例：

作为一个用户，我想要重置我的密码，以便在忘记密码时能够重新访问系统。

尽管目标不同，但用户故事和需求最终都是为了打造客户喜爱的产品。

什么是用户故事？

用户故事是从最终用户角度表达的需求。用户故事也被称为史诗、主题或功能，但它们都遵循相同的格式。

本质上，用户故事是一种清晰表达的需求。由于多种原因，用户故事格式已成为敏捷开发中表达需求的最流行方式：

• 它关注的是使用或受解决方案影响的人的视角。
• 它用对该角色有意义的语言来定义需求。
• 它有助于明确需求背后的真正目的。
• 它有助于在不过早陷入低层次细节的情况下定义高层次需求。

识别用户目标，并立即考虑用户故事中每个需求的商业价值。

用户故事通常被认为包含三个要素——3C:

• CARD——应写在索引卡或便利贴上。
• C对话——从产品负责人处获取详细信息（产品负责人).
• C确认——确保正确实现。必须满足用户验收标准。

用户故事格式

用户故事的格式如下：

作为一个 <角色>, 我想要 <目标>, 以便 <好处>

这两个例子展示了不同层级的用户故事，但使用了相同的格式：

在项目层面：

作为一名 <市场总监>, 我想要 <提升客户服务>, 以便 <我们能够留住客户>。

• 为用户故事编写SMART目标与INVEST标准
• 主题 vs史诗 vs 用户故事 vs 任务
• 产品待办事项列表中的DEEP是什么意思？
• 如何为Scrum项目撰写产品愿景？
• 如何使用Scrum看板进行敏捷开发？
• 在Scrum中谁负责创建产品待办事项或用户故事？
• 什么是敏捷估算？
• 敏捷中的故事点是什么？如何估算用户故事？
• 用户故事拆分——垂直切片 vs 水平切片