方法

User Story

一段从用户视角讲述功能的简短描述，采用「作为[角色]，我想要[目标]，以便[收益]」的形式，用来捕捉意图而非技术规范。

最近审阅: 2026-06-02 审阅人Kevin Riedl wiki ↗

用户故事从想要它的那个人的视角捕捉一块价值，通常采用"作为[角色]，我想要[目标]，以便[收益]“的格式。这个格式不是为形式而设的官僚主义。“作为"迫使你说出究竟是谁想要这个，“以便"迫使你陈述为什么，而这正是团队会跳过、然后构建出错误东西的那一部分。故事是一次对话的占位符，而不是一份合同。

好的故事往往满足 INVEST 标准：Independent（可以独立构建）、Negotiable（细节在你讨论之前都是开放的）、Valuable（交付用户或买家在意的东西）、Estimable（团队可以估算它）、Small（能装进一次迭代）和 Testable（你能判断它何时完成）。大多数故事在后两项上垮掉：太大而无法完成，或写得太含糊以至于没人说得清"完成"是什么意思。

验收标准是故事变得可测试的途径。它们是故事被接受所必须满足的具体条件，在工作开始之前就写好。“作为用户我想要重置我的密码"是一种意图。验收标准（重置链接在一小时后失效、无效令牌显示清晰的错误、成功重置后让用户登录）才是团队实际据以构建和测试的东西。

常见的反模式是那种伪装成故事的任务。“作为开发人员我想要给订单表加一个索引"穿着用户故事的戏服，但既没有用户也没有收益，只是一个戴着帽子的工程任务。跟踪它没问题，但它不是用户故事，而把技术任务伪装成故事会悄悄抹去这个格式本应保护的用户视角。

// FAQ

常见问题

常见问题

一段从用户视角出发的功能简短描述，通常为「作为[角色]，我想要[目标]，以便[收益]」。它捕捉谁想要某样东西以及为什么，并充当一次对话的占位符，而不是一份完整的技术规范。
一份判断好故事的清单：Independent、Negotiable、Valuable、Estimable、Small 和 Testable。大多数故事栽在 Small（太大而无法在一次迭代中完成）或 Testable（太含糊而无法定义完成）上。这些标准是一种在团队做出承诺之前就发现会惹麻烦的故事的快捷办法。
当它是一个伪装的技术任务时。「作为开发人员我想要加一个数据库索引」既没有真实用户也没有收益，只是一个穿了戏服的工程任务。跟踪这类工作没问题，但把它称作用户故事会抹去这个格式本应保护的用户视角，从而违背了它的初衷。