138 lines
4.8 KiB
Markdown
138 lines
4.8 KiB
Markdown
<execution domain="product-management">
|
||
<process>
|
||
# Feature设计流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[Epic功能分解] --> B[识别UI模块边界]
|
||
B --> C[定义Feature范围]
|
||
C --> D[设计技术边界]
|
||
D --> E[制定验收标准]
|
||
E --> F[Story拆解规划]
|
||
F --> G{大小验证}
|
||
G -->|合适| H[Feature就绪]
|
||
G -->|过大/过小| I[重新调整]
|
||
I --> C
|
||
|
||
B1[界面区域分析] --> B
|
||
B2[用户任务流程] --> B
|
||
B3[技术组件映射] --> B
|
||
```
|
||
|
||
## Feature识别方法
|
||
|
||
```mermaid
|
||
mindmap
|
||
root((Feature识别))
|
||
UI驱动
|
||
界面区域划分
|
||
交互流程完整性
|
||
组件边界清晰
|
||
价值驱动
|
||
用户任务完整性
|
||
功能价值独立性
|
||
业务流程节点
|
||
技术驱动
|
||
架构模块对应
|
||
服务边界清晰
|
||
数据模型对齐
|
||
```
|
||
</process>
|
||
|
||
<guideline>
|
||
### Feature定义建议
|
||
|
||
- **功能完整性**: Feature应代表完整的功能模块，用户能独立完成任务
|
||
- **技术边界清晰**: 对应独立技术组件，便于并行开发
|
||
- **用户可感知**: 有明确的UI界面或交互体验
|
||
- **中等粒度**: 1-3个迭代完成，包含3-8个Story
|
||
|
||
### 大小控制指南
|
||
|
||
| Feature类型 | 建议大小 | 完成时间 | Story数量 | 复杂度 |
|
||
|------------|---------|---------|-----------|-------|
|
||
| 简单Feature | 10-20 SP | 1迭代 | 2-4个Story | 低 |
|
||
| 标准Feature | 20-40 SP | 1-2迭代 | 4-6个Story | 中 |
|
||
| 复杂Feature | 40-60 SP | 2-3迭代 | 6-8个Story | 高 |
|
||
|
||
### 边界定义建议
|
||
|
||
- **包含明确**: 列出具体的功能点和特性
|
||
- **不包含明确**: 防止范围蔓延，明确排除内容
|
||
- **依赖识别**: 技术依赖、数据依赖、业务依赖
|
||
- **接口定义**: 与其他Feature的接口和数据流
|
||
|
||
### Story拆解策略
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[Feature] --> B[核心功能Story]
|
||
A --> C[交互操作Story]
|
||
A --> D[数据管理Story]
|
||
A --> E[异常处理Story]
|
||
|
||
B --> B1[主要用例]
|
||
C --> C1[用户操作]
|
||
D --> D1[CRUD操作]
|
||
E --> E1[错误处理]
|
||
```
|
||
</guideline>
|
||
|
||
<rule>
|
||
1. **四个核心原则必须遵循**
|
||
- 功能完整性: Feature代表完整功能模块
|
||
- 技术边界清晰: 对应独立技术组件
|
||
- 用户感知: 有明确的用户交互界面
|
||
- 大小适中: 不超过3个迭代，60 SP上限
|
||
|
||
2. **强制包含要素**
|
||
- 功能边界必须明确定义（包含/不包含）
|
||
- 验收标准必须具体可测
|
||
- Story拆解必须覆盖核心功能
|
||
- 技术依赖必须识别和记录
|
||
|
||
3. **三层关系规则**
|
||
- Epic → Feature: 价值主题到功能模块的分解
|
||
- Feature → Story: 功能模块到用户任务的拆解
|
||
- 层级间粒度跨度合理，避免过度拆分或粗糙
|
||
|
||
4. **拆分触发条件**
|
||
- 超过60 SP必须拆分
|
||
- 跨越3个以上技术模块需要拆分
|
||
- 包含不相关功能点需要重新组织
|
||
</rule>
|
||
|
||
<constraint>
|
||
1. **技术架构约束**
|
||
- Feature边界受现有架构模块限制
|
||
- 微服务边界影响Feature划分
|
||
- 数据模型设计影响功能范围
|
||
|
||
2. **团队能力约束**
|
||
- 并行开发Feature数量有限
|
||
- 团队技能影响Feature复杂度
|
||
- 跨团队Feature需要额外协调成本
|
||
|
||
3. **用户体验约束**
|
||
- UI一致性要求影响Feature边界
|
||
- 用户流程完整性不可打断
|
||
- 渐进式发布对Feature颗粒度的要求
|
||
|
||
4. **项目约束**
|
||
- 迭代时间盒限制Feature大小
|
||
- 测试资源影响Feature验收
|
||
- 发布节奏影响Feature优先级
|
||
</constraint>
|
||
|
||
<criteria>
|
||
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
||
|---------|---------|---------|-----------|
|
||
| 功能完整性 | 用户能独立完成完整任务 | 基本功能完整，少量依赖 | 功能不完整或过度依赖 |
|
||
| 边界清晰度 | 技术和功能边界都明确 | 边界基本清晰 | 边界模糊或重叠 |
|
||
| 大小合理性 | 符合20-60SP范围，Story数量适中 | 大小基本合理 | 过大过小或拆分不当 |
|
||
| 用户价值 | 独立交付价值，用户可感知 | 有一定价值 | 价值不明确或用户无感知 |
|
||
| 技术可行性 | 技术实现边界清晰可行 | 基本可行 | 技术难度过高或边界不清 |
|
||
| Story拆解质量 | Story覆盖全面，粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
|
||
| 验收标准 | 标准具体可测，覆盖全面 | 标准基本明确 | 标准模糊或不可测 |
|
||
</criteria>
|
||
</execution> |