5.5.1 像用户一样描述需求——用户故事格式
一句话破题
用户故事的标准格式：作为 [角色]，我希望 [做什么]，以便 [获得什么价值]。
用户故事的三要素
作为 [Who] - 谁会使用这个功能
我希望 [What] - 想要做什么
以便 [Why] - 为什么想要这样做好的用户故事 vs 差的用户故事
| 差的描述 | 好的用户故事 |
|---|---|
| "做登录功能" | 作为用户，我希望用邮箱密码登录，以便访问我的个人数据 |
| "文章列表" | 作为读者，我希望浏览文章列表，以便发现感兴趣的内容 |
| "添加搜索" | 作为读者，我希望搜索文章，以便快速找到特定主题 |
为什么要写"以便"
"以便"部分是最容易被忽略，却最重要的：
❌ 作为用户，我希望能登录
✅ 作为用户，我希望能登录，以便：
- 保存我的阅读记录
- 发表评论
- 收藏文章知道了"为什么"，才能更好地设计"怎么做"。
不同角色的用户故事
一个产品可能有多种用户角色：
markdown
## 博客系统用户故事
### 作为访客
- 我希望浏览文章列表，以便发现感兴趣的内容
- 我希望阅读文章详情，以便学习新知识
- 我希望搜索文章，以便快速定位内容
### 作为注册用户
- 我希望登录账号，以便使用个人功能
- 我希望评论文章，以便与作者互动
- 我希望收藏文章，以便日后重读
### 作为博主
- 我希望撰写文章，以便分享我的知识
- 我希望管理文章，以便维护内容质量
- 我希望查看统计，以便了解读者偏好用户故事的验收标准
每个用户故事都应该有验收标准：
markdown
## 用户故事：文章发布
作为博主，我希望发布文章，以便分享我的技术经验
### 验收标准
- [ ] 可以输入标题（1-100 字符）
- [ ] 可以输入正文（支持 Markdown）
- [ ] 可以选择分类（至少选一个）
- [ ] 可以添加标签（最多 5 个）
- [ ] 发布成功后跳转到文章详情页
- [ ] 发布成功后在列表页可见
### 边界情况
- 标题为空：显示错误提示
- 正文为空：显示错误提示
- 网络失败：保存为草稿INVEST 原则
好的用户故事应该符合 INVEST 原则：
| 原则 | 含义 | 示例 |
|---|---|---|
| Independent | 独立，不依赖其他故事 | 登录和注册可以分开做 |
| Negotiable | 可协商，细节可讨论 | 密码规则可以再定 |
| Valuable | 有价值，对用户有意义 | 不做"为了技术而技术"的功能 |
| Estimable | 可估算，能评估工作量 | 大故事要拆小 |
| Small | 小，几天内能完成 | 太大就拆分 |
| Testable | 可测试，有验收标准 | 知道什么算"完成" |
用户故事拆分
太大的故事需要拆分：
❌ 作为用户，我希望完整的认证系统
✅ 拆分为：
1. 作为用户，我希望注册账号
2. 作为用户，我希望登录账号
3. 作为用户，我希望重置密码
4. 作为用户，我希望修改个人信息让 AI 帮你写用户故事
你：我要做一个博客系统，帮我写用户故事
AI：## 博客系统用户故事
### 内容管理
1. 作为博主，我希望创建文章，以便分享我的知识
2. 作为博主，我希望编辑文章，以便修正错误
3. 作为博主，我希望删除文章，以便移除过时内容
4. 作为博主，我希望保存草稿，以便稍后继续编辑
### 内容消费
1. 作为读者，我希望浏览文章列表，以便发现内容
2. 作为读者，我希望阅读文章详情，以便学习知识
3. 作为读者，我希望搜索文章，以便快速定位
...实用建议
- 每个功能都写用户故事：养成习惯
- 不要跳过"以便"：这是理解需求的关键
- 用 AI 生成初稿：然后你来修改完善
- 保持简短：一个故事描述一个功能点