更新多个执行最佳实践文档，增加Epic、Feature、Story、Task、TestCase和Milestone的核心理念、职责边界、常见陷阱及自检清单，强调问题导向的需求管理和障碍识别方法，提升文档的指导性和实用性。同时，更新产品负责人角色文档，增加Scrum最佳实践链接，确保文档内容的完整性和准确性。
This commit is contained in:
sean
@ -1,162 +1,350 @@
|
||||
<execution domain="product-management">
|
||||
|
||||
# Story设计核心理念
|
||||
|
||||
## 🆚 传统做法 vs PromptX做法
|
||||
|
||||
### **传统User Story格式的问题**
|
||||
```markdown
|
||||
网上标准格式: "作为<角色>，我想要<功能>，以便于<价值>"
|
||||
|
||||
问题分析:
|
||||
❌ 关注解决方案而非问题本身
|
||||
❌ 容易变成功能需求列表
|
||||
❌ 缺乏对用户真实困难的深度理解
|
||||
❌ 开发团队被限制在预设解决方案中
|
||||
❌ 难以激发创新的解决思路
|
||||
|
||||
传统案例:
|
||||
"作为产品经理，我想要一键导入角色配置，以便快速使用AI角色"
|
||||
→ 这是在描述期望的功能，而非用户遇到的真实困难
|
||||
```
|
||||
|
||||
### **PromptX障碍导向的优势**
|
||||
```markdown
|
||||
PromptX格式: "作为<角色>，我在<任务>时，遇到<障碍>，导致<后果>"
|
||||
|
||||
优势分析:
|
||||
✅ 深度挖掘用户真实痛点
|
||||
✅ 让开发团队理解问题本质
|
||||
✅ 为创新解决方案留下空间
|
||||
✅ 促进以用户为中心的思考
|
||||
✅ 提高解决方案的针对性和有效性
|
||||
|
||||
PromptX案例:
|
||||
"作为新用户，我在配置AI角色时需要手动输入大量参数，经常出错导致重新开始"
|
||||
→ 这是在描述用户遇到的具体困难和影响
|
||||
```
|
||||
|
||||
### **从传统到PromptX的转换示例**
|
||||
|
||||
| 传统格式（功能导向） | PromptX格式（问题导向） | 解决方案空间 |
|
||||
|------------------|---------------------|------------|
|
||||
| 作为用户，我想要实时进度条，以便了解系统状态 | 作为用户，我在系统运行时无法知道当前进度，经常不确定是否需要等待 | 进度条/状态指示/时间预估/通知机制等多种可能 |
|
||||
| 作为开发者，我想要命令行工具，以便快速获取提示词 | 作为开发者，我在获取角色提示词时需要手动拼接多个文件，容易遗漏依赖 | CLI工具/聚合API/IDE插件/配置管理等 |
|
||||
| 作为管理员，我想要批量导入功能，以便管理大量数据 | 作为管理员，我在处理100+条记录时只能逐条手动操作，耗时且易错 | 批量导入/模板填写/API批处理/自动化脚本等 |
|
||||
|
||||
## 🤔 Story = 任务障碍问题发现
|
||||
|
||||
```markdown
|
||||
Story的本质：发现用户在执行具体任务时遇到的障碍
|
||||
核心思考：作为XX角色，我在完成XX任务时被什么困难阻碍了？
|
||||
|
||||
问题导向框架：
|
||||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||||
🛠️ 解决问题层: Task (技术实现)
|
||||
✅ 验证层: TestCase (质量保证)
|
||||
🎯 价值确认层: Milestone (交付确认)
|
||||
```
|
||||
|
||||
**Story的职责边界**：
|
||||
- ✅ 发现用户在具体任务中遇到的障碍和困难
|
||||
- ✅ 识别任务执行过程中的中断点和痛点
|
||||
- ✅ 定义用户在特定操作中的困扰体验
|
||||
- ❌ 不设计具体功能实现方案
|
||||
- ❌ 不定义技术解决方案
|
||||
- ❌ 不描述"用户想要什么功能"
|
||||
|
||||
## ⚠️ 常见陷阱与避免方法
|
||||
|
||||
```markdown
|
||||
陷阱1: 写成功能需求单
|
||||
错误表述: "作为用户，我想要一键导入角色配置文件，以便快速使用"
|
||||
正确表述: "作为新用户，我在配置AI角色时需要手动输入大量参数，经常出错导致重新开始"
|
||||
|
||||
陷阱2: 描述解决方案而非障碍
|
||||
错误表述: "作为开发者，我想要命令行聚合工具，以便获取完整提示词"
|
||||
正确表述: "作为开发者，我在获取角色提示词时需要手动拼接多个文件，容易遗漏依赖"
|
||||
|
||||
陷阱3: 关注期望功能而非当前困难
|
||||
错误表述: "作为用户，我想要实时状态反馈，以便了解系统运行情况"
|
||||
正确表述: "作为用户，我在系统运行时无法知道当前进度，经常不确定是否需要等待"
|
||||
|
||||
陷阱4: 任务描述过于宽泛
|
||||
错误表述: "作为产品经理，我想要管理产品需求，以便规划产品发展"
|
||||
正确表述: "作为产品经理，我在制定Sprint计划时无法快速评估需求优先级，经常延误规划"
|
||||
```
|
||||
|
||||
## 🔄 实践转换指南
|
||||
|
||||
### **Step 1: 识别用户真实任务**
|
||||
```markdown
|
||||
问自己: 用户在什么具体场景下需要完成什么任务？
|
||||
|
||||
避免模糊表述:
|
||||
❌ "管理数据" → 太抽象
|
||||
❌ "使用系统" → 太宽泛
|
||||
|
||||
寻找具体任务:
|
||||
✅ "导入客户数据" → 具体操作
|
||||
✅ "配置AI角色参数" → 明确任务
|
||||
✅ "评估需求优先级" → 清晰目标
|
||||
```
|
||||
|
||||
### **Step 2: 挖掘任务执行障碍**
|
||||
```markdown
|
||||
追问方式:
|
||||
1. "用户在执行这个任务时，哪个步骤最困难？"
|
||||
2. "什么情况下用户会失败或中断？"
|
||||
3. "用户最常在哪里出错或感到困惑？"
|
||||
4. "哪些因素让任务变得低效或烦躁？"
|
||||
|
||||
障碍类型检查:
|
||||
📋 操作复杂: 步骤太多、容易出错
|
||||
⏰ 时间成本: 等待太久、重复劳动
|
||||
💭 认知负担: 信息不足、选择困难
|
||||
🔄 流程中断: 依赖缺失、错误恢复
|
||||
```
|
||||
|
||||
### **Step 3: 量化障碍影响**
|
||||
```markdown
|
||||
影响维度:
|
||||
📊 频率: 多少用户会遇到？多久遇到一次？
|
||||
⚡ 严重性: 对任务完成影响多大？
|
||||
⏱️ 时间损失: 额外花费多少时间？
|
||||
😤 挫败感: 用户情绪影响程度？
|
||||
|
||||
具体化表述:
|
||||
❌ "经常出问题" → 模糊
|
||||
✅ "每次配置时30%概率需要重试" → 具体
|
||||
❌ "很慢" → 主观
|
||||
✅ "等待时间超过30秒" → 可量化
|
||||
```
|
||||
|
||||
### **Step 4: 障碍表述检查清单**
|
||||
```markdown
|
||||
格式检查:
|
||||
□ 用户角色具体明确（不是"用户"泛称）
|
||||
□ 任务场景具体可观察
|
||||
□ 障碍描述详细具体
|
||||
□ 影响后果明确可量化
|
||||
|
||||
内容检查:
|
||||
□ 没有包含解决方案暗示
|
||||
□ 没有使用"想要"、"需要"、"希望"词汇
|
||||
□ 从困难角度而非期望角度描述
|
||||
□ 开发团队看后能理解要解决的具体问题
|
||||
|
||||
质量检查:
|
||||
□ 其他团队成员能够理解障碍
|
||||
□ 可以想象多种不同的解决方案
|
||||
□ 障碍解决后用户体验会明显改善
|
||||
□ 符合INVEST原则要求
|
||||
```
|
||||
|
||||
**问题导向自检清单**：
|
||||
- [ ] Story描述中是否包含"想要"、"需要"、"希望"等需求词汇？
|
||||
- [ ] 是否先描述用户遇到的具体困难，而非期望得到的功能？
|
||||
- [ ] 能否用"什么阻碍了用户完成任务"来概括Story？
|
||||
- [ ] 开发团队看到Story能理解要解决的具体障碍？
|
||||
|
||||
<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[重新编写]
|
||||
A[Feature问题域拆解] --> B[识别具体任务场景]
|
||||
B --> C[分析任务执行障碍]
|
||||
C --> D[编写障碍描述格式]
|
||||
D --> E[INVEST原则验证]
|
||||
E --> F[编写问题解决标准]
|
||||
F --> G{障碍完整性检查}
|
||||
G -->|完整| H[Story就绪]
|
||||
G -->|不完整| I[补充障碍分析]
|
||||
I --> C
|
||||
|
||||
B1[主要用户角色] --> B
|
||||
B2[次要用户角色] --> B
|
||||
B3[系统角色] --> B
|
||||
B1[主要任务路径] --> B
|
||||
B2[异常处理路径] --> B
|
||||
B3[边界操作场景] --> B
|
||||
```
|
||||
|
||||
## Story编写模式
|
||||
## Story障碍识别方法
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((Story结构))
|
||||
3C模式
|
||||
Card(卡片)
|
||||
简洁故事描述
|
||||
标准格式
|
||||
Conversation(对话)
|
||||
团队讨论
|
||||
需求澄清
|
||||
Confirmation(确认)
|
||||
验收标准
|
||||
完成定义
|
||||
INVEST原则
|
||||
Independent(独立)
|
||||
Negotiable(可协商)
|
||||
Valuable(有价值)
|
||||
Estimable(可估算)
|
||||
Small(小粒度)
|
||||
Testable(可测试)
|
||||
root((障碍识别))
|
||||
操作困难
|
||||
步骤繁琐复杂
|
||||
操作容易出错
|
||||
学习成本高
|
||||
信息缺失
|
||||
状态不明确
|
||||
反馈不及时
|
||||
结果不可见
|
||||
流程中断
|
||||
等待时间长
|
||||
依赖不可用
|
||||
错误恢复困难
|
||||
体验痛点
|
||||
操作重复冗余
|
||||
界面不友好
|
||||
响应速度慢
|
||||
```
|
||||
|
||||
## 📊 任务障碍量化模板
|
||||
|
||||
```markdown
|
||||
### 具体障碍描述
|
||||
- 任务场景: [用户尝试完成什么具体任务]
|
||||
- 遇到困难: [在哪个步骤遇到什么障碍]
|
||||
- 困难表现: [障碍如何具体表现，如错误、延时、复杂]
|
||||
- 当前处理: [用户如何绕过或处理这个障碍]
|
||||
|
||||
### 障碍影响分析
|
||||
- 影响频率: [多少比例的用户会遇到此障碍]
|
||||
- 困难程度: [障碍对任务完成的阻碍程度]
|
||||
- 时间成本: [障碍导致的额外时间损失]
|
||||
- 错误风险: [障碍可能导致的错误概率]
|
||||
|
||||
### 解决期望
|
||||
- 理想体验: [障碍消除后用户应该有什么体验]
|
||||
- 成功标准: [如何验证障碍得到解决]
|
||||
- 性能指标: [时间、错误率等具体改善目标]
|
||||
```
|
||||
</process>
|
||||
|
||||
<guideline>
|
||||
### Story标准格式
|
||||
### Story障碍描述标准格式
|
||||
|
||||
```
|
||||
作为 [用户角色]
|
||||
我想要 [完成什么功能]
|
||||
以便于 [获得什么价值/达成什么目标]
|
||||
作为 [具体用户角色]
|
||||
我在 [执行具体任务时]
|
||||
遇到 [具体障碍和困难]
|
||||
导致 [任务中断或效率低下的后果]
|
||||
```
|
||||
|
||||
- **用户角色**: 具体明确，避免"用户"这样的泛化表达
|
||||
- **功能描述**: 从用户视角描述，避免技术实现细节
|
||||
- **价值目标**: 明确用户为什么需要这个功能
|
||||
- **任务场景**: 具体的任务执行情境，不是抽象目标
|
||||
- **障碍描述**: 详细说明遇到的具体困难和阻碍
|
||||
- **影响后果**: 明确障碍对任务完成造成的具体影响
|
||||
|
||||
### 验收标准编写(GWT格式)
|
||||
### 障碍解决标准编写(GWT格式)
|
||||
|
||||
```
|
||||
给定 [前置条件/初始状态]
|
||||
当 [用户执行的操作]
|
||||
那么 [预期的结果/系统反应]
|
||||
给定 [用户执行任务的初始状态]
|
||||
当 [用户遇到特定障碍情况时]
|
||||
那么 [障碍应该如何被消除或减轻]
|
||||
```
|
||||
|
||||
- **覆盖主要场景**: 正常流程、异常流程、边界条件
|
||||
- **具体可测**: 避免主观词汇，使用具体标准
|
||||
- **完整性**: 功能验收、质量验收、非功能性要求
|
||||
- **覆盖障碍场景**: 主要障碍、边界情况、异常处理
|
||||
- **解决标准具体**: 避免主观词汇，使用可验证的改善标准
|
||||
- **完整性**: 操作改善、信息改善、体验改善
|
||||
|
||||
### Story大小控制
|
||||
### 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 Points | 影响范围 |
|
||||
|---------|-------|---------|-------------|---------|
|
||||
| 简单操作障碍 | 低 | 0.5-1天 | 1-2点 | 单一操作 |
|
||||
| 标准任务障碍 | 中 | 1-3天 | 3-5点 | 任务流程 |
|
||||
| 复杂体验障碍 | 高 | 3-5天 | 8点(需拆分) | 跨任务影响 |
|
||||
|
||||
### Story到Task拆解策略
|
||||
### Story到Task问题解决策略
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Story] --> B[前端Tasks]
|
||||
A --> C[后端Tasks]
|
||||
A --> D[测试Tasks]
|
||||
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[部署配置]
|
||||
B --> B1[界面优化]
|
||||
B --> B2[交互改善]
|
||||
C --> C1[性能优化]
|
||||
C --> C2[逻辑简化]
|
||||
D --> D1[流程优化]
|
||||
D --> D2[反馈改善]
|
||||
E --> E1[文档改善]
|
||||
E --> E2[监控添加]
|
||||
```
|
||||
</guideline>
|
||||
|
||||
<rule>
|
||||
1. **INVEST原则强制遵循**
|
||||
- Independent: Story间依赖最小化，可调整开发顺序
|
||||
- Negotiable: 保持描述灵活性，通过对话细化需求
|
||||
- Valuable: 每个Story都有明确用户价值
|
||||
- Estimable: 需求清晰，技术方案明确，可准确估算
|
||||
- Small: 1-2周内完成，单人可独立开发
|
||||
- Testable: 有具体验收标准，可验证完成状态
|
||||
- Independent: Story间障碍独立，可单独解决
|
||||
- Negotiable: 保持障碍描述灵活性，通过对话细化问题
|
||||
- Valuable: 每个Story解决的障碍都有明确用户价值
|
||||
- Estimable: 障碍清晰，解决方案明确，可准确估算
|
||||
- Small: 1-2周内解决，单人可独立处理
|
||||
- Testable: 有具体改善标准，可验证障碍消除
|
||||
|
||||
2. **Story格式强制要求**
|
||||
- 必须使用"作为...我想要...以便于..."标准格式
|
||||
- 必须使用"作为...我在...遇到...导致..."障碍描述格式
|
||||
- 用户角色必须具体明确，不能使用"用户"泛称
|
||||
- 功能描述从用户视角，避免技术实现术语
|
||||
- 价值目标必须明确表达用户获得的价值
|
||||
- 任务场景必须具体，避免抽象的目标描述
|
||||
- 障碍描述必须具体可观察，避免解决方案暗示
|
||||
- 影响后果必须明确，说明障碍造成的具体问题
|
||||
|
||||
3. **验收标准强制要求**
|
||||
- 必须使用Given-When-Then格式
|
||||
- 至少包含3个场景：正常、异常、边界
|
||||
3. **解决标准强制要求**
|
||||
- 必须使用Given-When-Then格式描述改善标准
|
||||
- 至少包含3个场景：正常改善、异常处理、边界优化
|
||||
- 标准必须具体可测，避免主观判断
|
||||
- 必须包含功能、质量、性能标准
|
||||
- 必须包含操作改善、体验改善、性能改善标准
|
||||
|
||||
4. **拆分触发条件**
|
||||
- 超过8 Story Points必须拆分
|
||||
- 开发时间超过1周必须拆分
|
||||
- 涉及多个用户角色需要拆分
|
||||
- 包含技术风险或不确定性需要拆分
|
||||
- 解决时间超过1周必须拆分
|
||||
- 涉及多个用户角色的障碍需要拆分
|
||||
- 包含技术复杂性或不确定性需要拆分
|
||||
</rule>
|
||||
|
||||
<constraint>
|
||||
1. **团队技能约束**
|
||||
- Story复杂度受团队技能水平限制
|
||||
- 新技术学习成本影响估算准确性
|
||||
- 跨技能Story需要多人协作
|
||||
1. **用户认知约束**
|
||||
- 用户对系统理解程度影响障碍识别
|
||||
- 用户技能水平影响障碍严重程度
|
||||
- 用户使用习惯影响障碍感知
|
||||
|
||||
2. **技术债务约束**
|
||||
- 现有代码质量影响新功能开发
|
||||
- 技术架构限制功能实现方式
|
||||
- 测试覆盖率影响Story验收
|
||||
2. **技术实现约束**
|
||||
- 现有架构限制障碍解决方案
|
||||
- 性能瓶颈影响体验改善程度
|
||||
- 兼容性要求限制改善范围
|
||||
|
||||
3. **业务约束**
|
||||
- 业务规则复杂度影响Story大小
|
||||
- 合规要求增加开发复杂度
|
||||
- 用户体验一致性要求约束实现
|
||||
3. **业务流程约束**
|
||||
- 业务规则限制流程优化
|
||||
- 合规要求影响操作简化
|
||||
- 数据安全约束体验改善
|
||||
|
||||
4. **项目约束**
|
||||
- 迭代时间盒限制Story数量
|
||||
- 测试资源限制验收能力
|
||||
- 发布窗口影响Story优先级
|
||||
4. **项目资源约束**
|
||||
- 迭代时间限制障碍解决数量
|
||||
- 测试资源影响改善验证
|
||||
- 人员技能影响障碍解决复杂度
|
||||
</constraint>
|
||||
|
||||
<criteria>
|
||||
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
||||
|---------|---------|---------|-----------|
|
||||
| INVEST符合度 | 完全符合6个INVEST原则 | 基本符合，个别项可改进 | 不符合多个INVEST原则 |
|
||||
| 格式规范性 | 严格按照标准格式，角色价值明确 | 基本符合格式要求 | 格式不规范或要素缺失 |
|
||||
| 验收标准质量 | GWT格式完整，场景覆盖全面 | 基本明确可测 | 标准模糊或不可测试 |
|
||||
| 用户价值 | 价值明确且用户强烈需要 | 有一定价值 | 价值不明确或技术导向 |
|
||||
| 估算准确性 | 估算准确，风险可控 | 估算基本合理 | 估算偏差大或风险高 |
|
||||
| 独立性 | 完全独立可单独开发交付 | 基本独立，少量依赖 | 严重依赖其他Story |
|
||||
| 可测试性 | 验收标准具体可重复执行 | 基本可测试 | 难以验证或标准主观 |
|
||||
| 大小合理性 | 1-2周完成，复杂度适中 | 大小基本合理 | 过大过小影响交付 |
|
||||
| 障碍描述质量 | 障碍具体可观察，场景明确 | 基本清晰可理解 | 障碍模糊或偏向功能需求 |
|
||||
| 格式规范性 | 严格按照障碍描述格式 | 基本符合格式要求 | 格式不规范或要素缺失 |
|
||||
| 用户视角 | 完全从用户困难角度描述 | 基本体现用户视角 | 偏向系统或解决方案视角 |
|
||||
| 影响量化 | 障碍影响具体可量化 | 影响基本明确 | 影响不明确或过于抽象 |
|
||||
| 独立性 | 障碍独立可单独解决 | 基本独立，少量依赖 | 严重依赖其他Story |
|
||||
| 可验证性 | 改善标准具体可重复执行 | 基本可测试验证 | 难以验证或标准主观 |
|
||||
| 复杂度合理性 | 1-2周解决，复杂度适中 | 大小基本合理 | 过大过小影响解决效果 |
|
||||
|
||||
**快速检查要点**：
|
||||
📝 **障碍导向**: 描述用户困难而非功能需求，避免"想要"、"需要"、"希望"等词汇
|
||||
🎯 **任务具体**: 从用户执行具体任务的障碍角度定义问题
|
||||
📊 **困难量化**: 障碍影响和后果必须具体可观察，有明确改善标准
|
||||
🔍 **场景明确**: 任务场景具体，障碍描述准确，可独立解决和验证
|
||||
</criteria>
|
||||
</execution>
|
||||
Reference in New Issue
Block a user