用户故事

它是什么

用户故事是用「作为某类用户，我希望做某件事，以便获得某价值」表达的最小需求单元。它把注意力放在「谁、要什么、为什么」上，而不是先写功能规格。

为什么需要它

直接写功能容易丢掉用户和价值，变成「做一个按钮」。用户故事强制在每一小条里带上角色和目的，让团队始终知道为谁、为什么而做，也便于拆分、排期和验收。

它如何工作

一条故事通常写成「作为……我希望……以便……」，再配上验收标准和对话式澄清。故事要小到能在一段迭代内交付，价值要与业务目标挂钩。它不是替代 PRD，而是把 PRD 拆成可交付、可验证的小单元。

必须澄清的误会

用户故事 ≠ 产品需求文档。 用户故事是讨论用的卡片，短且开放；PRD 是把讨论结果固化成范围、验收与边界的文档。

用户故事 ≠ 需求分析。 需求分析是搞清楚要解决什么问题的过程，用户故事是这个过程里用来表达结论的一种写法。

真实例子

「作为客服坐席，我希望回复草稿能显示所引用的政策版本，以便我确认它仍对当前客户有效。」这条故事同时点出角色、动作和价值，验收标准就围绕「能否看到版本、能否确认有效」展开。

什么时候适合与不适合

适合：需要拆分交付、跨角色协作的迭代开发。慎用：只写故事不写验收标准会流于形式；把故事拆得太碎会失去上下文。故事的价值在「用户价值可见」，不在套模板。

亲自试一下

拿一个功能写三条用户故事，每条都用「作为……我希望……以便……」。检查「以便」是否说清了用户价值；如果「以便」写不出，说明这条需求可能只是在做功能而非解决问题。

接下来学什么

为每条故事补上验收标准，再放进 PRD 或迭代计划，用需求优先级排序。

来源与修订

用户故事的「角色-意图-价值」句式与用法依据 Atlassian 的实践指南 [S1] 与用户故事的通用定义 [S2]。本版强调故事必须带用户价值，不把模板本身当成目的。