以我所主，为我所用

什么才是有效 User Story

16 min read

什么才是有效 User Story

一句话先讲清楚：

有效的 User Story 不是把功能换成“作为谁、我想要、从而”的句式，而是用稳定的角色和价值定义问题，再把功能留作可以协商的解决方案。

很多团队写用户故事，最后写出来的其实还是功能需求。只是把“新增编辑按钮”改写成：

作为编辑者，
我希望编辑文档，
从而我可以编辑文档。

这类写法看起来符合三段式，但它并没有真正提供业务上下文。它的问题不在格式，而在于它没有说清楚：谁为什么需要这件事，价值发生在哪里，系统要保护什么规则，以及这一步在用户旅程中承接了什么。

有效 User Story 的关键，不是句式，而是问题定义。

用户故事不是功能需求

用户故事和功能需求最大的区别在于：

用户故事侧重定义问题，功能需求经常已经包含了解决方案。

比如：

作为学校教职员工，
我希望学生可以根据录取通知将学籍注册到教学计划上，
从而我可以跟踪他们获取学位的进度。

这条故事没有指定页面、按钮、API、表结构，也没有规定是 Web、移动端还是后台服务。它定义的是一个问题：教职员工需要知道学生是否进入了可被跟踪的教学计划进度中。

至于实现方式，可以是：

  • 学生在 Web 页面点击注册；
  • 学生在移动端确认注册；
  • 后台根据录取通知自动注册；
  • 教务人员通过管理端代为注册；
  • 通过 API 从招生系统同步注册。

这些都是解决方案。

所以，一个好的 User Story 应该先保留问题的稳定性，而不是过早绑定某个交互或实现。

角色和价值比功能更稳定

常见三段式是：

作为 <角色>
我希望 <功能>
从而 <价值>

但真正重要的是：

角色 - 价值 定义问题
功能 是可协商的解决方案

比如：

作为系统管理员，
我希望注册用户通过用户名/密码登录系统，
从而可以追踪不同用户的行为。

这里真正稳定的是：

系统管理员需要追踪不同用户的行为

“用户名/密码登录”只是一个方案。它可以被替换成微信登录、企业 SSO、手机号验证码，甚至设备指纹，只要仍然能满足“追踪不同用户行为”的目标。

如果把功能误当成问题本身，就会写出大量低价值故事：

作为用户，我希望点击按钮，从而我可以点击按钮。
作为编辑者，我希望编辑文档，从而我可以编辑文档。
作为管理员，我希望新增配置项，从而我可以配置系统。

这些句子的问题是，它们只是在复述功能，没有表达价值。

真正的价值不一定发生在操作人身上

写 User Story 时，最容易犯的错误是：谁点按钮，就把谁写成角色。

但真实业务中，操作人不一定是受益人。

比如登录：

作为注册用户，
我希望通过用户名/密码登录系统，
从而访问我的个人信息。

这个故事有时成立，但不总是成立。如果用户登录只是为了让平台识别身份、追踪行为、防止滥用，那么真正受益者可能不是用户，而是系统管理员、运营方或合规方。

再比如员工打卡。表面上是员工操作，但价值通常不在员工，而在管理者：

作为考勤管理员，
我希望员工可以提交考勤记录，
从而我可以核对出勤并处理薪资与合规问题。

所以判断用户故事是否有效，要问：

这件事完成以后，谁的目标被满足了？

不要机械地把“发起操作的人”当成故事角色。

价值陈述不能复述功能

无效价值陈述通常长这样：

我希望登录系统，从而我可以登录系统。
我希望编辑文档，从而我可以编辑文档。
我希望导出报表，从而我可以导出报表。

它没有解释为什么这件事值得做。

更好的价值陈述通常来自三个方向：

  1. 满足某个用户角色的目标；
  2. 满足整体解决方案中的规则或流程；
  3. 推进用户旅程的下一步。

比如“编辑文档”可以有几种不同写法。

如果价值是协作产出：

作为被授予该文档编辑权限的成员，
我希望可以修改并保存文档内容，
从而我可以参与协作完成文档。

如果价值是流程推进：

作为文档负责人，
我希望被指派的成员可以提交文档修改，
从而我可以进入评审和发布环节。

如果价值是治理与审计：

作为组织管理员，
我希望系统记录成员的文档编辑操作，
从而我可以追踪内容变更的责任来源。

同样是“编辑文档”，由于价值不同，故事角色、验收条件和模型边界都会不同。

为什么“被授予编辑权限的成员”比“编辑者”更好

在文档协作场景里，很多人会写：

作为编辑者，
我希望编辑文档，
从而我可以修改文档。

这不是一个好故事。因为“编辑者”往往不是稳定的用户角色，而是权限系统里的一个标签。

更好的表达是：

作为被授予该文档编辑权限的成员，
我希望可以修改并保存文档内容，
从而我可以参与协作完成文档。

这个表达更好，是因为它显式保留了业务前提：

  • 他首先是一个成员，而不是抽象的“编辑者”；
  • 他能编辑，是因为被授予了该文档的 edit 权限；
  • 权限有范围：该文档，而不是所有文档；
  • 系统要保护的规则是：只有被授权的人可以编辑；
  • 编辑操作会产生保存、版本和审计记录。

这会自然导出更清楚的验收条件：

Given 李四是组织成员
And 张三是文档 A 的所有者
And 张三已将文档 A 的编辑权限授予李四
And 该权限未过期且未被撤销
When 李四修改并保存文档 A
Then 系统应保存修改内容
And 系统应生成新的文档版本
And 系统应记录李四的编辑审计日志

反例也更清楚：

Given 王五未被授予文档 A 的编辑权限
When 王五尝试修改文档 A
Then 系统应拒绝该操作
And 不应生成文档修改记录

如果只说“作为编辑者”，这些业务前提都会被压扁。

User Story 应该从用户旅程中切出来

有效的 User Story 不是从页面控件里切出来的，而是从用户旅程中切出来的。

比如文档协作，至少有几条旅程：

授权旅程：文档所有者 → 授予权限 → 成员获得访问能力
编辑旅程：被授权成员 → 打开文档 → 修改内容 → 保存版本
审计旅程：管理员 → 查看权限变更和编辑记录 → 追踪责任来源
任务旅程：负责人 → 指派修改任务 → 成员提交修改 → 负责人确认完成

因此可以拆成不同故事：

作为文档所有者，
我希望将某个文档的编辑权限授予指定成员，
从而他们可以参与协作完善文档。
作为被授予该文档编辑权限的成员，
我希望可以修改并保存文档内容，
从而我可以参与协作完成文档。
作为组织管理员，
我希望查看文档权限授予和编辑操作记录，
从而我可以追踪文档内容变更的责任来源。
作为文档负责人，
我希望将文档修改任务分配给成员，
从而他可以在截止时间前完成修订并进入评审。

这几条故事看起来都和“编辑文档”有关，但它们解决的是不同问题。

如果把它们都写成“作为编辑者，我希望编辑文档”，业务上下文就会丢失。

从履约建模看 User Story

如果把 User Story 和履约建模结合起来，可以用几个问题检查它是否有效：

  1. 谁在这个故事里获得了价值？
  2. 谁有权主张这件事发生？
  3. 谁有义务让这件事完成？
  4. 什么凭证可以证明它完成了？
  5. 如果没有完成，会触发什么异常或补偿？
  6. 这个故事依赖哪些前置凭证？

以“编辑文档”为例，如果表达的是权限下的协作操作，它不一定是一个独立合同。它通常落在两条链之间：

文档访问授权链：证明这个人有权编辑
文档协作服务链：系统允许并保存这次编辑

也就是：

Permission Grant
→ Edit Request
→ Permission Check
→ Document Change Committed
→ Version Created
→ Audit Log Recorded

这时，User Story 不是在说“系统里有一个 DocumentEditor class”，而是在说：

一个成员在被授予某文档 edit 权限后，可以合法修改并保存该文档。

所以建模时通常不需要默认创建 DocumentEditor 类。更稳定的对象是：

User / Member
Document
PermissionGrant
EditOperation / ChangeSet
AuditLog

“编辑者”只是由 PermissionGrant(permission = edit) 推导出来的临时身份。

有效 User Story 的检查清单

我会用下面这组问题检查一个故事是否有效。

1. 角色是真实角色，还是系统标签？

不好：

作为编辑者……

更好：

作为被授予该文档编辑权限的成员……

2. 价值是真价值，还是功能复述？

不好：

从而我可以编辑文档。

更好：

从而我可以参与协作完成文档。

3. 功能是否过早绑定了解决方案？

不好：

我希望点击右上角蓝色编辑按钮……

更好：

我希望可以修改并保存文档内容……

4. 是否能导出清楚的验收条件？

如果故事无法导出 Given/When/Then，通常说明上下文不够清楚。

5. 是否能说明前置凭证和完成凭证？

比如：

前置凭证：Permission Grant
完成凭证：Document Change Committed / Version / Audit Log

6. 是否来自用户旅程，而不是页面清单？

页面可以变化，旅程更稳定。

一个有效 User Story 应该长什么样

以文档协作为例：

作为被授予该文档编辑权限的成员，
我希望可以修改并保存文档内容，
从而我可以参与协作完成文档。

这条故事是有效的，因为它同时说明了：

  • 角色：被授予该文档编辑权限的成员；
  • 功能：修改并保存文档内容；
  • 价值：参与协作完成文档；
  • 规则：必须被授予该文档 edit 权限；
  • 前置凭证：Permission Grant；
  • 完成凭证：ChangeSet / Version / AuditLog；
  • 后续旅程：评审、发布、归档或继续协作。

它不是完整需求文档，但它足以开启有效对话。

这也正是 User Story 的价值：少而精的卡片描述，加上一段围绕上下文、验收和边界的对话。

最后总结

有效 User Story 不是三段式模板，而是一个问题定义工具。

它应该做到：

用角色和价值稳定问题，
用功能表达可协商的解决方案，
用用户旅程定位故事边界，
用验收条件确认交付是否完成，
用履约和凭证补足业务上下文。

所以我判断一个 User Story 是否有效，不是看它有没有写成“作为谁、我希望、从而”，而是看它能不能帮助团队回答：

谁为了什么价值，需要系统在什么业务前提下完成什么，并且我们如何证明它完成了？

能回答这个问题，它才是有效的 User Story。

Graph View

Backlinks