user-story

user-story

延迟加载规则

• 默认只使用本文件内容
• 只有在用户明确要求细节或需要模板时，才加载 references 中的附件
• 未加载附件时，先给摘要与下一步

核心说明

用户故事技能。用于生成可执行的用户故事与验收标准。

---

用户故事模板

标准格式

作为 [用户角色]， 我想要 [执行某个操作/获得某个功能]， 以便 [实现某个价值/解决某个问题]。

完整要素

要素	说明	示例
As a (角色)	谁来用？	未登录用户
I want (功能)	要什么？	通过手机验证码登录
So that (价值)	为什么？	无需记忆密码即可访问账户

---

INVEST 原则

一个好的用户故事应满足：

原则	含义	检查问题
I (Independent)	独立的	这个故事可以独立开发吗？
N (Negotiable)	可协商的	实现方案可以讨论吗？
V (Valuable)	有价值的	用户/业务能获得价值吗？
E (Estimable)	可估算的	能估算工作量吗？
S (Small)	小的	能在一个迭代内完成吗？
T (Testable)	可测试的	有明确的验收标准吗？

---

验收标准写法

Given-When-Then 格式

#### 场景 1：正常登录
- **Given**（前置条件）：用户手机号已注册
- **When**（操作）：用户输入手机号，获取验证码，输入正确验证码，点击登录
- **Then**（预期结果）：登录成功，跳转到首页，显示用户信息

边界场景

必须考虑的情况：

• 输入为空
• 输入格式错误
• 输入超长
• 网络错误
• 权限不足
• 数据不存在

异常场景

• 服务超时
• 第三方接口失败
• 并发冲突
• 资源不足

---

用户故事拆分

从史诗到故事

史诗（Epic）：太大无法在一个迭代完成的故事

用户可以管理个人资料
    ↓ 拆分
├── 修改头像
├── 修改昵称
├── 修改密码
├── 绑定手机
└── 设置隐私

拆分技巧

技巧	说明	示例
按流程拆	按业务流程步骤	支付 → 选择支付方式 → 确认支付 → 支付结果
按数据拆	按数据类型	导出 → 导出CSV → 导出Excel → 导出PDF
按角色拆	按用户角色	搜索 → 普通搜索 → 高级搜索 → 管理员搜索
按优先级拆	按功能重要度	评论 → 发表评论 → 回复评论 → 点赞评论

---

故事点估算

估算参考

故事点	预估工时	复杂度
1	0.5-1天	简单，清晰
2	1-2天	中等，有细节
3	2-3天	复杂，有依赖
5	3-5天	很复杂，不确定
8	5-8天	需要拆分

估算考虑因素

• 技术难度：涉及新技术、算法、性能
• 依赖关系：等其他人/团队完成
• 不确定因素：需求不明确、技术未知
• 测试复杂度：多场景、多数据源

---

致命问题检查

用户故事常见错误：

• 解决方案伪装故事："我要一个弹窗框"不是故事
• 缺少验收标准：没有明确的验收条件
• 太大无法完成：一个迭代做不完
• 没有用户价值：纯技术实现
• 只有 happy path：不考虑边界和异常
• 依赖关系不清：不知道等谁

记住：用户故事是开发看的，不是写给老板看的。开发看了就知道做什么、怎么做对。

---

PRD 协作引导

本技能可补充 PRD 中的以下章节（仅当 PRD 已包含该章节时）：

可补充章节	补充内容	输出位置
用户故事 / 用户分析	用户故事（As a... I want... So that...）、验收标准	02-user-analysis.md 或 PRD 对应章节

协作约束

• ✅ 只补充上述已有章节，不新增章节
• ✅ 用户故事需包含验收标准（Acceptance Criteria）
• ❌ 不编辑其他章节（如功能规格、技术规格等）

---

输出结构（概览）

1. 故事识别：用户角色、核心价值
2. 用户故事：标准的 As a... I want... So that... 格式
3. 验收标准：Given-When-Then 格式，覆盖正常/边界/异常场景
4. 业务规则：具体的业务约束
5. 技术任务拆解：可执行的开发任务
6. 估算：故事点、工时、复杂度

---

用户故事卡片模板

## 用户故事：[故事名称]

### 故事信息

| 项目 | 内容 |
|-----|-----|
| Story ID | US-001 |
| 优先级 | P0 |
| 复杂度 | 中等(3-5天) |
| 状态 | TODO |

---

### 故事描述

**作为** [用户角色]，
**我想要** [执行某个操作]，
**以便** [实现某个价值]。

---

### 验收标准 (Acceptance Criteria)

#### 场景 1：正常流程
- **Given**：[前置条件]
- **When**：[操作]
- **Then**：[预期结果]

#### 场景 2：边界情况
- **Given**：[边界条件]
- **When**：[操作]
- **Then**：[预期结果]

#### 场景 3：异常情况
- **Given**：[异常条件]
- **When**：[操作]
- **Then**：[预期结果]

---

### 业务规则

- BR-01：[规则描述]
- BR-02：[规则描述]

---

### 技术任务拆解

1. [ ] [任务1] (复杂度：低)
2. [ ] [任务2] (复杂度：中)
3. [ ] [任务3] (复杂度：高)

---

### 备注

- [ ] 需要注意的事项
- [ ] 待确认的问题

---

示例对话

用户说："写一个登录的用户故事"

输出：

登录有很多种，先确认几个问题：

1. 登录方式：用户名密码？手机验证码？第三方登录？
2. 登录失败：密码错误几次锁定？怎么解锁？
3. 登录状态：保持多久？关浏览器失效还是记住7天？
4. 多设备：同一账号能同时登录几个设备？

用户说："手机验证码登录"

输出：

用户故事：手机验证码登录

故事信息

项目	内容
Story ID	US-001
优先级	P0
复杂度	中等(3-5天)
状态	TODO

---

故事描述

作为 未登录用户， 我想要 通过手机验证码快速登录， 以便 无需记忆密码即可访问我的账户。

---

验收标准 (Acceptance Criteria)

场景 1：正常登录 - 已注册用户

• Given：用户手机号已注册
• When：用户输入手机号，获取验证码，输入正确验证码，点击登录
• Then：登录成功，跳转到首页，显示用户信息

场景 2：正常登录 - 新用户自动注册

• Given：用户手机号未注册
• When：用户输入手机号，获取验证码，输入正确验证码，点击登录
• Then：自动创建账户并登录，跳转到首页

场景 3：边界 - 验证码过期

• Given：验证码已超过5分钟
• When：用户输入过期验证码
• Then：提示"验证码已过期，请重新获取"

场景 4：边界 - 验证码错误

• Given：用户已获取验证码
• When：用户输入错误的验证码
• Then：提示"验证码错误，请重新输入"，允许重试

场景 5：边界 - 频繁获取验证码

• Given：用户60秒内已获取过验证码
• When：用户再次点击获取验证码
• Then：按钮禁用，显示倒计时"X秒后重新获取"

场景 6：异常 - 短信发送失败

• Given：短信服务异常
• When：用户点击获取验证码
• Then：提示"短信发送失败，请稍后重试"

场景 7：异常 - 手机号格式错误

• Given：用户在输入框
• When：用户输入非11位数字
• Then：提示"请输入正确的手机号"，禁用获取验证码按钮

---

业务规则

• BR-01：验证码有效期5分钟
• BR-02：同一手机号60秒内只能获取一次验证码
• BR-03：登录状态保持7天
• BR-04：首次登录自动创建账户

---

技术任务拆解

1. 用户表设计 (复杂度：低)
2. 验证码表设计 (复杂度：低)
3. 发送验证码接口 (复杂度：中) - 对接短信服务商
4. 验证登录接口 (复杂度：中)
5. 登录页面UI (复杂度：低)
6. 登录状态管理 (复杂度：中)

---

备注

• ⚠️ 需要对接短信服务商（阿里云/腾讯云），有成本
• ⚠️ 需要加图形验证码防止短信被刷

---

常见错误对照

错误	问题	正确做法
"我要一个弹窗"	这是解决方案，不是故事	"作为用户，我想确认删除操作"
没有验收标准	开发不知道怎么做对	每个场景有明确的Then
只考虑happy path	边界情况没考虑	加上边界和异常场景
故事太大	一个迭代做不完	拆分成多个小故事
没有价值说明	不知道为什么做	加上So that从句

---

最佳实践

1. 和开发一起确认

写完故事后，让开发确认是否理解，是否可估算。

2. 验收标准可测试

每个验收标准应该是可观察、可测试的。

3. 保持独立性

故事之间不要有强依赖，可以按任意顺序开发。

4. 定期回顾

每个迭代结束后，回顾故事估算是否准确，调整下次估算。

5. 用故事对话

不要只把故事写文档，要和开发、测试一起讨论故事。