更新多个执行最佳实践文档，增加Epic、Feature、Story、Task、TestCase和Milestone的核心理念、职责边界、常见陷阱及自检清单，强调问题导向的需求管理和障碍识别方法，提升文档的指导性和实用性。同时，更新产品负责人角色文档，增加Scrum最佳实践链接，确保文档内容的完整性和准确性。
This commit is contained in:
sean
@ -1,138 +1,216 @@
|
||||
<execution domain="product-management">
|
||||
|
||||
# Feature设计核心理念
|
||||
|
||||
## 🤔 Feature = 功能域问题发现
|
||||
|
||||
```markdown
|
||||
Feature的本质：发现用户在特定功能域遇到的问题
|
||||
核心思考：用户在这个功能域被什么困难阻碍了？
|
||||
|
||||
问题导向框架：
|
||||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||||
🛠️ 解决问题层: Task (技术实现)
|
||||
✅ 验证层: TestCase (质量保证)
|
||||
🎯 价值确认层: Milestone (交付确认)
|
||||
```
|
||||
|
||||
**Feature的职责边界**：
|
||||
- ✅ 发现用户在功能域的具体痛点和障碍
|
||||
- ✅ 识别功能缺失导致的用户任务中断
|
||||
- ✅ 定义用户在特定场景下的困难体验
|
||||
- ❌ 不设计具体功能模块实现方案
|
||||
- ❌ 不定义技术架构和接口细节
|
||||
- ❌ 不描述"用户需要什么能力"
|
||||
|
||||
## ⚠️ 常见陷阱与避免方法
|
||||
|
||||
```markdown
|
||||
陷阱1: 写成功能设计书
|
||||
错误表述: "用户角色管理功能模块，包含角色选择、配置生成、状态展示"
|
||||
正确表述: "用户无法快速识别和切换可用的AI角色，配置过程繁琐易错"
|
||||
|
||||
陷阱2: 定义解决方案而非问题
|
||||
错误表述: "提供命令行工具让用户一键生成角色配置文件"
|
||||
正确表述: "当前角色配置需要手动操作多个步骤，新用户配置失败率高"
|
||||
|
||||
陷阱3: 关注能力需求而非缺失痛点
|
||||
错误表述: "用户需要可视化的记忆状态监控能力"
|
||||
正确表述: "用户对记忆系统运行状态缺乏感知，无法确认功能是否正常"
|
||||
|
||||
陷阱4: 混合问题与功能清单
|
||||
错误表述: "角色初始化复杂，需要包含别名解析、文件生成、状态反馈功能"
|
||||
正确表述: "角色初始化过程用户不知道进度，经常不确定是否成功完成"
|
||||
```
|
||||
|
||||
**问题导向自检清单**：
|
||||
- [ ] Feature描述中是否包含"功能"、"模块"、"提供"等解决方案词汇？
|
||||
- [ ] 是否先描述用户遇到的困难，再描述期望改善？
|
||||
- [ ] 能否用"什么问题阻碍了用户"而非"用户需要什么"来概括Feature？
|
||||
- [ ] 开发团队看到Feature能理解要解决的痛点，而非要开发的功能？
|
||||
|
||||
<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
|
||||
A[Epic问题域分解] --> B[识别功能场景痛点]
|
||||
B --> C[定义问题边界]
|
||||
C --> D[分析用户困难]
|
||||
D --> E[制定问题解决标准]
|
||||
E --> F[Story问题拆解规划]
|
||||
F --> G{问题完整性验证}
|
||||
G -->|完整| H[Feature就绪]
|
||||
G -->|不完整| I[补充问题分析]
|
||||
I --> B
|
||||
|
||||
B1[界面区域分析] --> B
|
||||
B2[用户任务流程] --> B
|
||||
B3[技术组件映射] --> B
|
||||
B1[用户旅程断点分析] --> B
|
||||
B2[任务执行障碍识别] --> B
|
||||
B3[体验缺失评估] --> B
|
||||
```
|
||||
|
||||
## Feature识别方法
|
||||
## Feature问题识别方法
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((Feature识别))
|
||||
UI驱动
|
||||
界面区域划分
|
||||
交互流程完整性
|
||||
组件边界清晰
|
||||
价值驱动
|
||||
用户任务完整性
|
||||
功能价值独立性
|
||||
业务流程节点
|
||||
技术驱动
|
||||
架构模块对应
|
||||
服务边界清晰
|
||||
数据模型对齐
|
||||
root((问题识别))
|
||||
用户体验断点
|
||||
任务中断节点
|
||||
操作困难环节
|
||||
反馈缺失场景
|
||||
功能缺失分析
|
||||
必要能力缺失
|
||||
信息获取障碍
|
||||
操作效率低下
|
||||
技术约束导致的用户问题
|
||||
性能瓶颈影响
|
||||
兼容性问题
|
||||
稳定性缺陷
|
||||
```
|
||||
|
||||
## 📊 问题影响量化模板
|
||||
|
||||
```markdown
|
||||
### 用户痛点量化
|
||||
- 具体困难: [用户遇到的具体问题，如"配置角色需要10个步骤"]
|
||||
- 影响范围: [受影响用户比例，如"80%的新用户"]
|
||||
- 困难成本: [时间/错误损失，如"平均失败3次才成功"]
|
||||
- 当前缺失: [什么能力的缺失导致了这个问题]
|
||||
|
||||
### 功能缺失分析
|
||||
- 缺失能力: [具体缺少什么功能支持]
|
||||
- 导致后果: [缺失导致的用户困难]
|
||||
- 替代方案: [用户当前如何绕过这个问题]
|
||||
- 绕过成本: [替代方案的额外成本]
|
||||
|
||||
### 改善期望
|
||||
- 期望体验: [解决问题后用户应该有什么体验]
|
||||
- 成功指标: [如何衡量问题得到解决]
|
||||
- 优先级: [相对其他问题的重要程度]
|
||||
```
|
||||
</process>
|
||||
|
||||
<guideline>
|
||||
### Feature定义建议
|
||||
### Feature问题定义建议
|
||||
|
||||
- **功能完整性**: Feature应代表完整的功能模块，用户能独立完成任务
|
||||
- **技术边界清晰**: 对应独立技术组件，便于并行开发
|
||||
- **用户可感知**: 有明确的UI界面或交互体验
|
||||
- **中等粒度**: 1-3个迭代完成，包含3-8个Story
|
||||
- **问题完整性**: Feature应代表完整的问题域，用户困难有明确边界
|
||||
- **技术边界对应**: 问题域对应技术模块边界，便于解决方案设计
|
||||
- **用户可感知**: 问题是用户直接体验到的困难和障碍
|
||||
- **中等粒度**: 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 | 高 |
|
||||
| 问题类型 | 复杂度 | 解决时间 | Story数量 | 影响范围 |
|
||||
|---------|-------|---------|-----------|---------|
|
||||
| 简单问题域 | 低 | 1迭代 | 2-4个Story | 单一场景 |
|
||||
| 标准问题域 | 中 | 1-2迭代 | 4-6个Story | 多个相关场景 |
|
||||
| 复杂问题域 | 高 | 2-3迭代 | 6-8个Story | 跨场景影响 |
|
||||
|
||||
### 边界定义建议
|
||||
### 问题边界定义
|
||||
|
||||
- **包含明确**: 列出具体的功能点和特性
|
||||
- **不包含明确**: 防止范围蔓延，明确排除内容
|
||||
- **依赖识别**: 技术依赖、数据依赖、业务依赖
|
||||
- **接口定义**: 与其他Feature的接口和数据流
|
||||
- **包含痛点**: 列出具体的用户困难和障碍点
|
||||
- **不包含问题**: 防止范围扩散，明确排除的问题
|
||||
- **问题依赖**: 此问题与其他问题的关联和依赖
|
||||
- **影响接口**: 解决此问题对其他功能域的影响
|
||||
|
||||
### Story拆解策略
|
||||
### Story问题拆解策略
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Feature] --> B[核心功能Story]
|
||||
A --> C[交互操作Story]
|
||||
A --> D[数据管理Story]
|
||||
A --> E[异常处理Story]
|
||||
A[Feature问题域] --> B[核心困难Story]
|
||||
A --> C[操作障碍Story]
|
||||
A --> D[信息缺失Story]
|
||||
A --> E[反馈不足Story]
|
||||
|
||||
B --> B1[主要用例]
|
||||
C --> C1[用户操作]
|
||||
D --> D1[CRUD操作]
|
||||
E --> E1[错误处理]
|
||||
B --> B1[主要痛点]
|
||||
C --> C1[操作困难]
|
||||
D --> D1[信息获取问题]
|
||||
E --> E1[状态不明确]
|
||||
```
|
||||
</guideline>
|
||||
|
||||
<rule>
|
||||
1. **四个核心原则必须遵循**
|
||||
- 功能完整性: Feature代表完整功能模块
|
||||
- 技术边界清晰: 对应独立技术组件
|
||||
- 用户感知: 有明确的用户交互界面
|
||||
- 大小适中: 不超过3个迭代，60 SP上限
|
||||
- 问题完整性: Feature代表完整问题域
|
||||
- 用户视角: 从用户困难角度定义问题
|
||||
- 可观察性: 问题是用户直接感受到的
|
||||
- 边界清晰: 问题域边界明确不重叠
|
||||
|
||||
2. **强制包含要素**
|
||||
- 功能边界必须明确定义（包含/不包含）
|
||||
- 验收标准必须具体可测
|
||||
- Story拆解必须覆盖核心功能
|
||||
- 技术依赖必须识别和记录
|
||||
- 用户痛点必须具体可观察
|
||||
- 问题边界必须明确定义（包含/不包含痛点）
|
||||
- 解决标准必须具体可验证
|
||||
- Story问题拆解必须覆盖核心困难
|
||||
- 问题依赖必须识别和记录
|
||||
|
||||
3. **三层关系规则**
|
||||
- Epic → Feature: 价值主题到功能模块的分解
|
||||
- Feature → Story: 功能模块到用户任务的拆解
|
||||
- 层级间粒度跨度合理，避免过度拆分或粗糙
|
||||
3. **三层问题关系规则**
|
||||
- Epic → Feature: 价值问题到功能域问题的分解
|
||||
- Feature → Story: 功能域问题到具体用户困难的拆解
|
||||
- 层级间问题粒度跨度合理，避免过度拆分或粗糙
|
||||
|
||||
4. **拆分触发条件**
|
||||
- 超过60 SP必须拆分
|
||||
- 跨越3个以上技术模块需要拆分
|
||||
- 包含不相关功能点需要重新组织
|
||||
- 问题域跨越3个以上技术模块需要拆分
|
||||
- 包含不相关困难点需要重新组织
|
||||
- 解决时间超过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覆盖全面，粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
|
||||
| 验收标准 | 标准具体可测，覆盖全面 | 标准基本明确 | 标准模糊或不可测 |
|
||||
| 问题清晰度 | 用户痛点具体可观察，困难描述准确 | 问题基本清晰可理解 | 问题模糊或偏向解决方案 |
|
||||
| 边界合理性 | 问题域边界清晰，困难点内聚相关 | 边界基本清晰 | 边界模糊或问题分散 |
|
||||
| 用户视角 | 完全从用户困难角度描述问题 | 基本体现用户视角 | 偏向系统或技术视角 |
|
||||
| 影响量化 | 问题影响范围和程度量化清晰 | 影响基本明确 | 影响不明确或无量化 |
|
||||
| 可解决性 | 问题有明确解决标准和验证方式 | 基本可解决验证 | 问题过于抽象或无法验证 |
|
||||
| Story拆解质量 | 问题拆解全面，困难点粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
|
||||
| 问题导向性 | 避免解决方案描述，纯问题导向 | 基本问题导向 | 混合解决方案或功能描述 |
|
||||
|
||||
**快速检查要点**：
|
||||
📝 **问题导向**: 描述用户困难而非功能需求，避免"需要"、"提供"、"实现"等词汇
|
||||
🎯 **用户视角**: 从用户遇到的具体障碍和痛点角度定义问题
|
||||
📊 **困难量化**: 用户痛点影响范围和程度必须量化，有明确解决标准
|
||||
🔍 **边界清晰**: 问题域边界明确，困难点内聚，可独立解决和验证
|
||||
</criteria>
|
||||
</execution>
|
||||
Reference in New Issue
Block a user