5.5 KiB
5.5 KiB
# Story设计流程
```mermaid
flowchart TD
A[Feature功能拆解] --> B[识别用户角色]
B --> C[编写Story格式]
C --> D[INVEST原则验证]
D --> E[编写验收标准]
E --> F[Story估算]
F --> G{质量检查}
G -->|通过| H[Story就绪]
G -->|不通过| I[重新编写]
I --> C
B1[主要用户角色] --> B
B2[次要用户角色] --> B
B3[系统角色] --> B
```
## Story编写模式
```mermaid
mindmap
root((Story结构))
3C模式
Card(卡片)
简洁故事描述
标准格式
Conversation(对话)
团队讨论
需求澄清
Confirmation(确认)
验收标准
完成定义
INVEST原则
Independent(独立)
Negotiable(可协商)
Valuable(有价值)
Estimable(可估算)
Small(小粒度)
Testable(可测试)
```
```
作为 [用户角色]
我想要 [完成什么功能]
以便于 [获得什么价值/达成什么目标]
```
- **用户角色**: 具体明确，避免"用户"这样的泛化表达
- **功能描述**: 从用户视角描述，避免技术实现细节
- **价值目标**: 明确用户为什么需要这个功能
### 验收标准编写(GWT格式)
```
给定 [前置条件/初始状态]
当 [用户执行的操作]
那么 [预期的结果/系统反应]
```
- **覆盖主要场景**: 正常流程、异常流程、边界条件
- **具体可测**: 避免主观词汇，使用具体标准
- **完整性**: 功能验收、质量验收、非功能性要求
### Story大小控制
| Story类型 | 建议大小 | 开发时间 | Story Points |
|----------|---------|---------|-------------|
| 简单Story | 1-2 SP | 0.5-1天 | 1-2点 |
| 标准Story | 3-5 SP | 1-3天 | 3-5点 |
| 复杂Story | 8 SP | 3-5天 | 8点(需拆分) |
### Story到Task拆解策略
```mermaid
flowchart LR
A[Story] --> B[前端Tasks]
A --> C[后端Tasks]
A --> D[测试Tasks]
A --> E[其他Tasks]
B --> B1[UI组件]
B --> B2[交互逻辑]
C --> C1[API接口]
C --> C2[业务逻辑]
D --> D1[单元测试]
D --> D2[集成测试]
E --> E1[文档更新]
E --> E2[部署配置]
```
2. **Story格式强制要求**
- 必须使用"作为...我想要...以便于..."标准格式
- 用户角色必须具体明确，不能使用"用户"泛称
- 功能描述从用户视角，避免技术实现术语
- 价值目标必须明确表达用户获得的价值
3. **验收标准强制要求**
- 必须使用Given-When-Then格式
- 至少包含3个场景：正常、异常、边界
- 标准必须具体可测，避免主观判断
- 必须包含功能、质量、性能标准
4. **拆分触发条件**
- 超过8 Story Points必须拆分
- 开发时间超过1周必须拆分
- 涉及多个用户角色需要拆分
- 包含技术风险或不确定性需要拆分
2. **技术债务约束**
- 现有代码质量影响新功能开发
- 技术架构限制功能实现方式
- 测试覆盖率影响Story验收
3. **业务约束**
- 业务规则复杂度影响Story大小
- 合规要求增加开发复杂度
- 用户体验一致性要求约束实现
4. **项目约束**
- 迭代时间盒限制Story数量
- 测试资源限制验收能力
- 发布窗口影响Story优先级