162 lines
5.5 KiB
Markdown
162 lines
5.5 KiB
Markdown
<execution domain="product-management">
|
||
<process>
|
||
# 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(可测试)
|
||
```
|
||
</process>
|
||
|
||
<guideline>
|
||
### Story标准格式
|
||
|
||
```
|
||
作为 [用户角色]
|
||
我想要 [完成什么功能]
|
||
以便于 [获得什么价值/达成什么目标]
|
||
```
|
||
|
||
- **用户角色**: 具体明确，避免"用户"这样的泛化表达
|
||
- **功能描述**: 从用户视角描述，避免技术实现细节
|
||
- **价值目标**: 明确用户为什么需要这个功能
|
||
|
||
### 验收标准编写(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[部署配置]
|
||
```
|
||
</guideline>
|
||
|
||
<rule>
|
||
1. **INVEST原则强制遵循**
|
||
- Independent: Story间依赖最小化，可调整开发顺序
|
||
- Negotiable: 保持描述灵活性，通过对话细化需求
|
||
- Valuable: 每个Story都有明确用户价值
|
||
- Estimable: 需求清晰，技术方案明确，可准确估算
|
||
- Small: 1-2周内完成，单人可独立开发
|
||
- Testable: 有具体验收标准，可验证完成状态
|
||
|
||
2. **Story格式强制要求**
|
||
- 必须使用"作为...我想要...以便于..."标准格式
|
||
- 用户角色必须具体明确，不能使用"用户"泛称
|
||
- 功能描述从用户视角，避免技术实现术语
|
||
- 价值目标必须明确表达用户获得的价值
|
||
|
||
3. **验收标准强制要求**
|
||
- 必须使用Given-When-Then格式
|
||
- 至少包含3个场景：正常、异常、边界
|
||
- 标准必须具体可测，避免主观判断
|
||
- 必须包含功能、质量、性能标准
|
||
|
||
4. **拆分触发条件**
|
||
- 超过8 Story Points必须拆分
|
||
- 开发时间超过1周必须拆分
|
||
- 涉及多个用户角色需要拆分
|
||
- 包含技术风险或不确定性需要拆分
|
||
</rule>
|
||
|
||
<constraint>
|
||
1. **团队技能约束**
|
||
- Story复杂度受团队技能水平限制
|
||
- 新技术学习成本影响估算准确性
|
||
- 跨技能Story需要多人协作
|
||
|
||
2. **技术债务约束**
|
||
- 现有代码质量影响新功能开发
|
||
- 技术架构限制功能实现方式
|
||
- 测试覆盖率影响Story验收
|
||
|
||
3. **业务约束**
|
||
- 业务规则复杂度影响Story大小
|
||
- 合规要求增加开发复杂度
|
||
- 用户体验一致性要求约束实现
|
||
|
||
4. **项目约束**
|
||
- 迭代时间盒限制Story数量
|
||
- 测试资源限制验收能力
|
||
- 发布窗口影响Story优先级
|
||
</constraint>
|
||
|
||
<criteria>
|
||
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
||
|---------|---------|---------|-----------|
|
||
| INVEST符合度 | 完全符合6个INVEST原则 | 基本符合，个别项可改进 | 不符合多个INVEST原则 |
|
||
| 格式规范性 | 严格按照标准格式，角色价值明确 | 基本符合格式要求 | 格式不规范或要素缺失 |
|
||
| 验收标准质量 | GWT格式完整，场景覆盖全面 | 基本明确可测 | 标准模糊或不可测试 |
|
||
| 用户价值 | 价值明确且用户强烈需要 | 有一定价值 | 价值不明确或技术导向 |
|
||
| 估算准确性 | 估算准确，风险可控 | 估算基本合理 | 估算偏差大或风险高 |
|
||
| 独立性 | 完全独立可单独开发交付 | 基本独立，少量依赖 | 严重依赖其他Story |
|
||
| 可测试性 | 验收标准具体可重复执行 | 基本可测试 | 难以验证或标准主观 |
|
||
| 大小合理性 | 1-2周完成，复杂度适中 | 大小基本合理 | 过大过小影响交付 |
|
||
</criteria>
|
||
</execution> |