# 用户故事与用例指南

用户故事（User Story）是敏捷开发中表达需求的标准方式，强调从用户视角描述价值。

## 用户故事格式

### 标准模板

```
作为 <用户角色>，
我希望 <目标/动作>，
以便 <获得的价值/收益>
```

### 示例

| 优先级 | 用户故事 | 验收标准 |
|--------|----------|----------|
| P0 | 作为注册用户，我希望用手机号一键登录，以便快速进入应用 | 1. 输入手机号 → 获取验证码 ≤ 60s<br>2. 验证码 4位数字<br>3. 验证码有效期 5分钟 |
| P1 | 作为求职者，我希望按薪资范围筛选岗位，以便找到匹配预算的工作 | 1. 支持设置最低/最高薪资<br>2. 筛选后结果实时更新<br>3. 无结果时显示空状态 |

## INVEST 原则

好用户故事应符合：

- **Independent（独立的）**：故事间依赖尽量少
- **Negotiable（可协商的）**：细节可讨论，非合同
- **Valuable（有价值的）**：对用户或业务有明确价值
- **Estimable（可估算的）**：开发团队能评估工作量
- **Small（小的）**：一个迭代内能完成
- **Testable（可测试的）**：有明确的完成标准

## 史诗（Epic）与故事拆分

### 拆分层级

```
史诗（Epic）：一个大主题
  └── 特性（Feature）：功能模块
        └── 用户故事（Story）：最小可交付单元
              └── 任务（Task）：开发动作
```

### 拆分示例

**Epic**：订单管理
- Feature：创建订单
  - Story：作为买家，我希望能从购物车生成订单
  - Story：作为买家，我希望选择收货地址
  - Story：作为买家，我希望使用优惠券
- Feature：支付订单
  - Story：作为买家，我希望能使用微信支付
  - Story：作为买家，支付失败后我能重新支付
- Feature：查看订单
  - Story：作为买家，我希望能查看订单列表
  - Story：作为买家，我希望能查看订单物流

## 验收标准（Acceptance Criteria）

### 编写原则

- **具体可测**：用数字、条件、状态描述，避免"快速""友好"
- **覆盖主流程+异常**：不仅写正常情况，要写边界和错误
- **Given-When-Then 格式**：

```
Given [前置条件]
When [用户动作]
Then [系统响应]
```

### 示例

```
AC1：有效手机号注册
Given 用户输入未注册的手机号 13800138000
When 点击"获取验证码"
Then 60秒内收到验证码短信
And 页面显示"验证码已发送"

AC2：重复手机号
Given 用户输入已注册的手机号 13800138000
When 点击"获取验证码"
Then 页面提示"该手机号已注册，直接登录？"
And 提供"去登录"跳转按钮

AC3：无效手机号
Given 用户输入格式错误的手机号 138001
When 点击"获取验证码"
Then 页面提示"请输入正确的11位手机号"
And "获取验证码"按钮保持可点击
```

## 用例图说明

当需要展示系统与外部参与者的交互时，用文字描述用例关系：

```
参与者：
- 注册用户（主参与者）
- 系统管理员（次参与者）
- 支付网关（外部系统）

用例：
- 用户注册（包含：验证手机号、设置密码）
- 用户登录（扩展：忘记密码、第三方登录）
- 提交订单（包含：选择商品、确认地址；扩展：使用优惠券）
- 支付订单（包含：调用支付接口；扩展：支付失败重试）
```

## 故事地图（Story Map）

按用户旅程组织故事，识别MVP：

```
用户旅程阶段：浏览 → 选择 → 购买 → 收货 → 评价

浏览阶段的故事：
- 搜索商品
- 筛选分类
- 查看推荐

选择阶段的故事：
- 查看详情
- 选择规格
- 加入购物车

[...其他阶段...]

MVP 选择：每个阶段选1-2个最高价值故事
```