第三节：用户故事编写实战——从零开始写一个完整的故事

好，咱们直接动手。前面讲了那么多理论，今天就来真的——从零开始写一个完整的用户故事，连验收标准一起搞定。

我个人习惯，每次写用户故事前，先问自己三个问题：

• 这个功能到底给谁用？
• 他为什么要用？
• 用完之后他得到什么？

这三个问题想明白了，故事骨架就有了。咱们拿一个真实场景来练手——电商系统的“订单取消”功能。

第一步：确定角色和需求

先别急着写故事。你得搞清楚，谁需要这个功能？

我遇到过不少团队，上来就写“用户想要取消订单”。但“用户”是谁？是刚下单就后悔的买家？还是发现地址填错了的粗心鬼？不同的人，需求其实不一样。

咱们这次聚焦一个典型角色：已登录的普通买家。他刚下了一单，发现选错颜色了，想取消重来。

第二步：写出故事标题和描述

标准格式还记得吧？

作为 <角色>
我想要 <功能>
以便 <价值>

套到咱们的场景里：

作为 已登录的普通买家
我想要 取消我刚刚下的订单
以便 我可以重新下单选择正确的商品

嗯，看起来挺顺。但别急，这只是骨架。真正让故事“活”起来的，是验收标准。

第三步：编写验收标准（核心难点）

验收标准说白了就是——怎么才算“做完”。我见过太多团队，故事写得很漂亮，一开发就吵架，就是因为验收标准没写清楚。

咱们这个“取消订单”功能，验收标准至少要考虑这些：

3.1 业务规则

• 订单状态必须是“待发货”才能取消
• 已发货的订单不能取消
• 取消后库存要恢复
• 取消后要触发退款流程

3.2 界面交互

• 订单详情页要有“取消订单”按钮
• 点击后弹出确认对话框
• 确认后显示“取消成功”提示
• 取消后按钮变灰，不可重复点击

3.3 异常情况

• 网络中断时提示“操作失败，请重试”
• 订单已被系统自动取消时，提示“订单状态已变更”
• 退款失败时，记录日志并通知客服

你看，光一个取消功能，就能写出这么多条。我建议你把这些整理成表格，开发测试都看得明白：

编号	验收标准	类型
AC-01	只有“待发货”状态的订单显示取消按钮	业务规则
AC-02	点击取消按钮弹出确认弹窗，包含“确定”和“再想想”	界面交互
AC-03	确认后订单状态变为“已取消”，按钮置灰	界面交互
AC-04	取消成功后，对应商品库存+1	业务规则
AC-05	取消成功后，自动发起退款（原路返回）	业务规则
AC-06	网络异常时，显示“操作失败，请稍后重试”	异常处理
AC-07	订单已被他人取消时，提示“订单状态已变更，请刷新”	异常处理

第四步：补充非功能性需求

故事写完了？别急。有些东西用户不会说，但你必须想到。比如：

• 取消操作的响应时间不能超过2秒
• 高并发下（比如双十一）取消操作不能失败
• 取消记录要保存至少180天，方便售后查证

这些可以写在故事的“备注”里，或者单独列一个“非功能需求”段落。我习惯在故事底部加一行：

备注：
- 取消接口响应时间 < 2s (P99)
- 取消操作需记录操作日志，保留180天
- 退款接口调用失败时，需进入人工处理队列

第五步：评审和确认

故事写完了，别急着扔给开发。拉上产品、测试、开发一起过一遍。我经历过一次惨痛的教训——

评审的时候，重点关注这几件事：

• 验收标准是否覆盖了所有正常流程？
• 异常情况有没有遗漏？
• 非功能需求是否明确？
• 有没有歧义？比如“取消后恢复库存”——恢复多少？原数量还是打折后的数量？

完整示例：最终版用户故事

好了，咱们把上面所有内容整合一下，看看最终长什么样：

用户故事：取消未发货订单

作为 已登录的普通买家
我想要 取消我处于“待发货”状态的订单
以便 我可以重新下单或放弃购买

验收标准：
AC-01: 只有“待发货”状态的订单显示“取消订单”按钮
AC-02: 点击按钮后弹出确认弹窗，包含“确定取消”和“暂不取消”
AC-03: 确认后订单状态变为“已取消”，按钮置灰不可点击
AC-04: 取消成功后，对应商品库存+1
AC-05: 取消成功后，自动发起原路退款
AC-06: 网络异常时，显示“操作失败，请稍后重试”
AC-07: 订单状态已被其他操作变更时，提示“订单状态已变更，请刷新页面”

备注：
- 取消接口响应时间 < 2s (P99)
- 取消操作需记录操作日志，保留180天
- 退款接口调用失败时，需进入人工处理队列

你看，这样一个故事，开发拿到手就知道要做什么，测试也知道要测什么，产品也能确认是不是自己想要的。说白了，好的用户故事，就是让所有人都能“对得上号”。

最后送你一句话：写用户故事不是写作文，是写契约。每一句话都要经得起推敲，每一条验收标准都要能验证。下次写故事的时候，试试我这个流程，你会发现团队吵架的次数少了很多。