用户故事与验收标准:敏捷需求编写核心方法
用户故事是敏捷与 Scrum 中最常见的需求表达形式。Mountain Goat Software 的 Mike Cohn 认为,用户故事最大的价值不在于写下来的文字,而在于它是"未来对话的占位符"。相比传统需求文档,用户故事把团队的关注点从"写功能"转向"谈需求"。
用户故事的 3C 模型
Ron Jeffries 在 2001 年用三个"C"概括了用户故事的组成:
- 卡片(Card):故事的书面描述,用于规划,也作为后续讨论的提醒。
- 对话(Conversation):围绕故事展开的讨论,用来补充细节、澄清边界。
- 确认(Confirmation):用于判断故事何时算完成的测试或条件,也就是验收标准。
其中对话比文字更重要——一份用户故事在真正讨论之前是不完整的。正因为如此,写在 Jira 或 Trello 里的故事,也不该因为"进了工具"就不舍得丢弃。
模板与示例
用户故事通常遵循一个简单模板:作为一个<角色>,我想要<目标>,以便<理由>。这个句式从真实用户的视角出发,同时回答了"谁""做什么"和"为什么"。例如:
- 作为网站访客,我想要按分类筛选文章,以便快速找到感兴趣的内容。
- 作为客户,我想要在线提交工单,以便不用发邮件也能获得支持。
注意故事的主角应该是终端用户或客户,而不是产品负责人自己——"作为产品负责人,我想要一个文章列表"这类写法方向就偏了。
从平庸到合格:一个重写例子
对比两个版本就明白差距。“作为用户,我想看到文章列表,以便浏览”——角色模糊(是访客还是登录用户?)、目标空洞、没有理由。改写成“作为匿名访客,我想按分类和标签筛选文章列表,以便在几百篇文章里快速找到感兴趣的内容”,方向立刻清晰。真正拉开差距的是验收标准:“按分类筛选时 URL 要带可分享的查询参数(如 ?cat=ai)”,加上这一条,开发、测试、产品对“完成”的理解就完全一致了。
史诗与拆分
用户故事可以写得很大(史诗),也可以写得很小。大故事细节少,一般无法在一个迭代内完成,需要先拆分成多个小故事。例如"作为用户,我可以备份整个硬盘"可以拆成"我可以按文件大小选择备份"、"我可以指定不备份的文件夹"等更小的故事。拆分是给故事增加细节的第一种方式。
验收标准:完成条件
给故事增加细节的第二种方式,是添加完成条件(conditions of satisfaction),也就是验收标准。它是一组高级验收测试,当这些条件全部成立时,故事才算完成。例如"作为营销副总裁,我想选择节假日来评估历史广告效果"可以补充:
- 支持主要零售节假日:圣诞、感恩节、新年等。
- 支持跨两个自然年的节假日。
- 节假日周期可以设定为节前若干天。
- 周期可以从一个节假日延续到下一个节假日。
把验收标准写清楚,等于把"什么叫做完"从团队讨论中固定下来,避免返工。
除了“完成条件”列表,很多团队用 Given/When/Then 把验收标准写成可执行的场景:
| Given(前提) | When(动作) | Then(结果) |
|---|---|---|
| 用户已登录且有购买历史 | 用户提交退款申请 | 系统 1 小时内发送确认邮件,且订单状态变为“退款中” |
| 文章按分类发布 | 访客点击“AI 分类” | 列表只展示该分类文章,URL 带 ?cat=ai |
这种写法比一句话描述更严密,也更容易直接转成自动化测试。
一个好故事的检验标准:INVEST
判断故事写得好不好,业界常用 INVEST 这个缩写:Independent(独立)、Negotiable(可协商)、Valuable(有价值)、Estimable(可估算)、Small(小)、Testable(可测试)。其中最容易被忽视的是 T——没有验收标准的故事无法测试,也就无法确认“完成”。写故事时对着这份清单过一遍,能拦住大部分低质量条目。
谁写、何时写
任何人都可以写用户故事。产品负责人负责确保产品待办列表(Product Backlog)存在,但不一定亲自写每条故事;好的项目里,团队每个成员都会贡献故事。通常在项目启动附近会举办一次故事编写工作坊,产出覆盖整个项目或 3-6 个月发布周期的待办列表;之后新故事随时可以由任何人补充。
待办列表可以看作传统需求文档的替代品,但要记住:书面的"作为……我想……"只有在相关讨论发生后才算完整。必要时,故事可以指向一张流程图、一张计算表格,或任何团队需要的制品。
与 AI 时代的衔接
验收标准与 AI 时代的评估数据集在思路上高度一致:都是把"什么是好的"变成可运行的判定条件。前者用于确定性的软件功能,后者用于 AI 输出。对 AI 功能,可以先用故事表达意图,再用评估集定义"好的输出",两者互补。上线后,也可以借助虚拟用户测试在迭代间快速检查验收标准是否真的被满足。
16IDC 观察
对网站与 SaaS 团队,用户故事的价值是把需求从"描述"变成"可讨论、可验收"。写得好不好,不在于模板是否标准,而在于是否有持续的对话、明确的完成条件。更完整的分析流程,可参考本站需求分析分类。
原文来源:https://www.mountaingoatsoftware.com/agile/user-stories
参考:Atlassian — 用户故事指南 https://www.atlassian.com/agile/project-management/user-stories