更新多个执行最佳实践文档，增加Epic、Feature、Story、Task、TestCase和Milestone的核心理念、职责边界、常见陷阱及自检清单，强调问题导向的需求管理和障碍识别方法，提升文档的指导性和实用性。同时，更新产品负责人角色文档，增加Scrum最佳实践链接，确保文档内容的完整性和准确性。
This commit is contained in:
sean
@ -1,4 +1,49 @@
|
||||
<execution domain="product-management">
|
||||
|
||||
# Epic设计核心理念
|
||||
|
||||
## 🤔 Epic = 价值主题问题
|
||||
|
||||
```markdown
|
||||
Epic的本质：提出价值主题层面的问题
|
||||
核心思考：我们如何为用户创造这个价值域？
|
||||
|
||||
问题导向框架：
|
||||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||||
🛠️ 解决问题层: Task (技术实现)
|
||||
✅ 验证层: TestCase (质量保证)
|
||||
🎯 价值确认层: Milestone (交付确认)
|
||||
```
|
||||
|
||||
**Epic的职责边界**：
|
||||
- ✅ 提出战略价值问题和商业假设
|
||||
- ✅ 定义用户价值期望和成功标准
|
||||
- ✅ 识别市场机会和用户痛点
|
||||
- ❌ 不解决具体技术实现问题
|
||||
- ❌ 不定义详细功能设计方案
|
||||
|
||||
## ⚠️ 常见陷阱与避免方法
|
||||
|
||||
```markdown
|
||||
陷阱1: 写成技术方案书
|
||||
错误表述: "构建基于NPM的模块化架构，包含CLI工具和JSON API"
|
||||
正确表述: "降低AI助手角色加载的复杂度，提升开发者使用效率"
|
||||
|
||||
陷阱2: 混合问题与解决方案
|
||||
错误表述: "通过命令行工具实现快速角色配置以提升用户体验"
|
||||
正确表述: "当前角色配置流程复杂，需要简化用户获取AI能力的路径"
|
||||
|
||||
陷阱3: 功能需求清单化
|
||||
错误表述: "包含角色系统、快速初始化、内存可视化三个功能"
|
||||
正确表述: "AI助手获取专业能力的门槛过高，影响普通用户采用"
|
||||
```
|
||||
|
||||
**问题导向自检清单**：
|
||||
- [ ] Epic描述中是否包含"如何"、"通过"、"实现"等解决方案词汇？
|
||||
- [ ] 是否先描述用户痛点，再提出价值假设？
|
||||
- [ ] 能否用"什么问题"而非"什么功能"来概括Epic？
|
||||
- [ ] 利益相关者看到Epic能理解问题，而非实现方式？
|
||||
|
||||
<process>
|
||||
# Epic设计流程
|
||||
|
||||
@ -36,16 +81,46 @@
|
||||
技术债还清
|
||||
开发效率
|
||||
```
|
||||
|
||||
## 📊 价值量化模板
|
||||
|
||||
```markdown
|
||||
### 用户价值量化
|
||||
- 当前痛点: [具体描述用户遇到的问题]
|
||||
- 影响用户: [数量/类型，如"80%的新用户"、"所有开发者"]
|
||||
- 痛点成本: [时间/金钱损失，如"每次配置10分钟"、"60%放弃率"]
|
||||
- 期望改善: [具体目标，如"降低到30秒"、"提升到95%成功率"]
|
||||
|
||||
### 商业价值量化
|
||||
- 市场机会: [市场规模/竞争优势，如"AI开发者工具市场增长30%"]
|
||||
- 收入影响: [具体数字，如"预期提升用户转化20%"]
|
||||
- 成本节约: [具体节约，如"减少支持成本50%"]
|
||||
- 风险缓解: [避免的损失，如"防止用户流失到竞品"]
|
||||
|
||||
### 技术价值量化
|
||||
- 效率提升: [具体指标，如"开发效率提升3倍"]
|
||||
- 维护成本: [降低程度，如"技术债务减少40%"]
|
||||
- 扩展能力: [支撑能力，如"支持10倍用户增长"]
|
||||
```
|
||||
</process>
|
||||
|
||||
<guideline>
|
||||
### Epic定义建议
|
||||
|
||||
- **标题命名**: 使用"动词+对象"格式，如"构建用户工作区"
|
||||
- **标题命名**: 使用"问题+影响"格式，如"用户角色获取流程复杂度过高"，避免"构建XX"、"实现XX"等解决方案用词
|
||||
- **价值先行**: 每个Epic必须先定义用户价值，再描述功能
|
||||
- **边界明确**: 用包含/不包含列表明确Epic范围
|
||||
- **分阶段交付**: 大Epic按MVP→增强→完善分阶段
|
||||
|
||||
**命名对比示例**：
|
||||
```markdown
|
||||
❌ 解决方案导向: "构建NPM包管理系统"
|
||||
✅ 问题导向: "AI助手能力获取复杂度阻碍用户采用"
|
||||
|
||||
❌ 功能导向: "开发角色快速配置功能"
|
||||
✅ 价值导向: "新用户角色配置门槛影响产品推广"
|
||||
```
|
||||
|
||||
### 大小控制指南
|
||||
|
||||
| Epic类型 | 建议大小 | 完成周期 | Feature数量 |
|
||||
@ -107,5 +182,11 @@
|
||||
| 验收标准 | 标准具体可测，覆盖功能质量业务 | 标准基本明确可测试 | 标准模糊或不可测 |
|
||||
| 依赖管理 | 依赖最小化，风险已识别应对 | 依赖已识别，风险可控 | 依赖复杂或风险未评估 |
|
||||
| INVEST符合度 | 完全符合INVEST原则 | 基本符合，个别项有改进空间 | 不符合多个INVEST原则 |
|
||||
|
||||
**快速检查要点**：
|
||||
📝 **问题导向**: 标题描述问题而非解决方案，避免"构建"、"开发"等技术词汇
|
||||
💰 **价值量化**: 用户价值和商业价值必须量化，有清晰成功指标
|
||||
🎯 **范围边界**: 包含/不包含列表清晰，单一问题域，6个迭代内完成
|
||||
📊 **可执行性**: 验收标准具体可测，可拆分为独立Feature，风险已识别
|
||||
</criteria>
|
||||
</execution>
|
||||
@ -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>
|
||||
@ -1,4 +1,28 @@
|
||||
<execution domain="project-management">
|
||||
|
||||
# Milestone设计核心理念
|
||||
|
||||
## 🎯 Milestone = 价值交付确认节点
|
||||
|
||||
```markdown
|
||||
Milestone的本质：确认阶段性问题解决和价值交付
|
||||
核心思考：这个阶段的问题解决了吗？价值交付了吗？
|
||||
|
||||
问题导向框架：
|
||||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||||
🛠️ 解决问题层: Task (技术实现)
|
||||
✅ 验证层: TestCase (质量保证)
|
||||
🎯 价值确认层: Milestone (交付确认) ← 我们在这里
|
||||
```
|
||||
|
||||
**Milestone的职责边界**：
|
||||
- ✅ 确认用户价值的实际交付
|
||||
- ✅ 验证商业目标的达成状况
|
||||
- ✅ 标记问题解决的重要节点
|
||||
- ✅ 为后续问题解决提供决策依据
|
||||
- ❌ 不重新定义问题或解决方案
|
||||
- ❌ 不改变Epic/Feature/Story的目标
|
||||
|
||||
<process>
|
||||
# Milestone管理流程
|
||||
|
||||
|
||||
217
domain/scrum/execution/scrum-best-practice.execution.md
Normal file
217
domain/scrum/execution/scrum-best-practice.execution.md
Normal file
@ -0,0 +1,217 @@
|
||||
<execution domain="product-management">
|
||||
<process>
|
||||
# PromptX Scrum最佳实践执行流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[项目启动] --> B[障碍发现阶段]
|
||||
B --> C[需求聚合阶段]
|
||||
C --> D[迭代规划阶段]
|
||||
D --> E[Sprint执行阶段]
|
||||
E --> F[价值验证阶段]
|
||||
F --> G{是否达成目标}
|
||||
G -->|是| H[项目交付]
|
||||
G -->|否| I[反思改进]
|
||||
I --> B
|
||||
|
||||
%% 子流程详解
|
||||
B --> B1[用户深度访谈]
|
||||
B1 --> B2[障碍地图绘制]
|
||||
B2 --> B3[痛点价值评估]
|
||||
B3 --> B4[场景故事收集]
|
||||
|
||||
C --> C1[Story亲和图分析]
|
||||
C1 --> C2[Feature价值抽象]
|
||||
C2 --> C3[Epic战略对齐]
|
||||
C3 --> C4[优先级动态排序]
|
||||
|
||||
D --> D1[战略Epic校准]
|
||||
D1 --> D2[Feature迭代规划]
|
||||
D2 --> D3[Story精化确认]
|
||||
D3 --> D4[反馈循环设计]
|
||||
```
|
||||
|
||||
## 核心执行步骤
|
||||
|
||||
### 1. 障碍发现阶段 (1-2周)
|
||||
- **用户深度访谈**: 探索具体使用场景中的困难
|
||||
- **障碍地图绘制**: 可视化用户任务执行中的卡点
|
||||
- **痛点价值评估**: 评估解决每个障碍的业务影响
|
||||
- **场景故事收集**: 基于真实场景写障碍导向Story
|
||||
|
||||
### 2. Bottom-Up需求聚合 (1周)
|
||||
- **Story亲和图分析**: 将相似障碍的Story归类
|
||||
- **Feature价值抽象**: 从Story组合中提炼Feature价值
|
||||
- **Epic战略对齐**: 将Feature群组抽象为战略Epic
|
||||
- **优先级动态排序**: 基于用户反馈调整优先级
|
||||
|
||||
### 3. 混合模式迭代规划 (2-3天)
|
||||
- **战略Epic校准**: 确保Epic与商业目标一致
|
||||
- **Feature迭代规划**: 选择最高价值Feature进入Sprint
|
||||
- **Story精化确认**: 验证Story是否真正解决用户障碍
|
||||
- **反馈循环设计**: 建立快速用户验证机制
|
||||
|
||||
### 4. Sprint执行与验证 (2-4周)
|
||||
- **障碍解决进展跟踪**: 每日同步障碍解决状况
|
||||
- **创新方案探索**: 鼓励多种解决方案验证
|
||||
- **用户反馈快速收集**: 持续验证解决方案有效性
|
||||
- **价值交付确认**: 验证是否真正解决用户障碍
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
# PromptX Scrum核心规则
|
||||
|
||||
## 1. 障碍导向Story编写规则
|
||||
- Story必须使用障碍导向模板：
|
||||
"作为[用户角色]，我在[具体任务]时，遇到[具体障碍]，导致[负面影响]"
|
||||
- 严禁在Story中预设技术解决方案
|
||||
- 每个Story必须包含可验证的负面影响描述
|
||||
|
||||
## 2. AI决策优先级规则
|
||||
- 决策优先级顺序：内部创新方法论 > 用户验证假设 > 行业参考实践
|
||||
- AI助手必须优先应用PromptX已验证的方法
|
||||
- 质疑外部"标准"做法的适用性
|
||||
- 避免被主流惯性思维束缚
|
||||
|
||||
## 3. Bottom-Up需求聚合规则
|
||||
- 需求收集从散乱Story开始，而非预设Epic分解
|
||||
- Feature必须从Story群组中自然聚合产生
|
||||
- Epic必须基于Feature价值进行战略抽象
|
||||
- 禁止自上而下的功能驱动分解
|
||||
|
||||
## 4. 团队协作规则
|
||||
- Product Owner职责重定义为"障碍价值翻译师"
|
||||
- Scrum Master职责重定义为"创新流程守护者"
|
||||
- Development Team职责重定义为"解决方案创新者"
|
||||
- 所有角色必须以用户障碍解决为工作导向
|
||||
</rule>
|
||||
|
||||
<constraint>
|
||||
# 实施约束条件
|
||||
|
||||
## 1. 时间约束
|
||||
- 障碍发现阶段不超过2周
|
||||
- 需求聚合阶段限制在1周内完成
|
||||
- Sprint长度建议2-4周
|
||||
- 用户反馈收集周期不超过3天
|
||||
|
||||
## 2. 团队规模约束
|
||||
- 开发团队规模3-9人
|
||||
- 每个Sprint Story数量5-15个
|
||||
- 同时进行的Epic数量不超过3个
|
||||
- 用户访谈样本量至少5个用户
|
||||
|
||||
## 3. 质量约束
|
||||
- Story质量评估总分必须≥12分（满分20分）
|
||||
- 用户障碍解决满意度≥4.5/5
|
||||
- 功能使用率提升≥40%
|
||||
- Sprint目标达成率≥85%
|
||||
|
||||
## 4. 技术约束
|
||||
- 需要支持AI辅助决策的工具环境
|
||||
- 要求快速原型验证能力
|
||||
- 必须具备用户反馈收集渠道
|
||||
- 需要可视化障碍地图绘制工具
|
||||
</constraint>
|
||||
|
||||
<guideline>
|
||||
# 实施指导原则
|
||||
|
||||
## 1. 障碍导向Story编写指南
|
||||
|
||||
### 优秀案例对比
|
||||
```markdown
|
||||
❌ 传统写法：
|
||||
"作为产品经理，我想要需求管理工具，以便提高工作效率"
|
||||
|
||||
✅ PromptX写法：
|
||||
"作为产品经理，我在制定Sprint计划时无法快速评估需求优先级，经常延误规划导致团队等待"
|
||||
```
|
||||
|
||||
### Story质量提升技巧
|
||||
- 具体化任务场景，避免抽象描述
|
||||
- 明确障碍表现，确保可观察验证
|
||||
- 量化负面影响，建立价值测量基准
|
||||
- 为创新解决方案留白，避免技术预设
|
||||
|
||||
## 2. 团队转型实施指南
|
||||
|
||||
### 阶段性推进策略
|
||||
```markdown
|
||||
🎯 意识转变阶段（1-2周）：
|
||||
• 组织PromptX方法论培训
|
||||
• 对比传统方式的问题
|
||||
• 建立新的评估标准
|
||||
|
||||
🔄 实践适应阶段（2-4周）：
|
||||
• 小范围试点新方法
|
||||
• 收集团队使用反馈
|
||||
• 调整实践细节
|
||||
|
||||
📈 能力固化阶段（1-2月）：
|
||||
• 建立新的工作习惯
|
||||
• 形成创新思维惯性
|
||||
• 持续优化和改进
|
||||
```
|
||||
|
||||
## 3. 常见陷阱避免指南
|
||||
|
||||
### 关键陷阱识别
|
||||
- **功能需求伪装**: Story写成"我想要X功能" → 强制使用障碍导向模板
|
||||
- **外部标准盲从**: 不假思索采用"行业最佳实践" → 建立内部方法优先原则
|
||||
- **预设解决方案**: 在Story中暗示技术方案 → 专注障碍描述，避免方案预设
|
||||
- **Epic驱动分解**: 从Epic向下分解而非聚合 → 建立Bottom-Up聚合流程
|
||||
|
||||
## 4. AI增强实施指南
|
||||
|
||||
### 智能化需求分析应用
|
||||
- 用户访谈内容智能分析
|
||||
- 障碍模式自动识别
|
||||
- 相似场景关联推荐
|
||||
- 潜在障碍预测提醒
|
||||
- 多种解决方案生成
|
||||
- 技术可行性快速评估
|
||||
</guideline>
|
||||
|
||||
<criteria>
|
||||
# 成功评估标准
|
||||
|
||||
## Story质量评估维度
|
||||
|
||||
| 评估维度 | 优秀(5分) | 良好(4分) | 合格(3分) | 不合格(1-2分) |
|
||||
|---------|----------|----------|----------|--------------|
|
||||
| 障碍具体性 | 描述具体可观察的执行障碍 | 障碍描述较清晰 | 障碍描述基本明确 | 障碍描述模糊抽象 |
|
||||
| 场景真实性 | 基于真实用户场景，任务具体 | 场景较真实，任务明确 | 场景基本真实 | 场景虚假或过于抽象 |
|
||||
| 影响可测量 | 负面影响量化且可验证 | 影响描述相对明确 | 影响基本可识别 | 影响描述模糊或无法验证 |
|
||||
| 解决空间开放 | 完全避免预设方案，创新空间大 | 基本避免预设，有创新空间 | 轻微预设，仍有创新可能 | 严重预设方案，限制创新 |
|
||||
|
||||
**通过标准**: 每个维度≥3分，总分≥12分
|
||||
|
||||
## 团队创新能力指标
|
||||
|
||||
| 指标类别 | 优秀标准 | 合格标准 | 改进标准 |
|
||||
|---------|----------|----------|----------|
|
||||
| 障碍识别准确率 | ≥90% | ≥85% | <85% |
|
||||
| 创新解决方案比例 | ≥70% | ≥60% | <60% |
|
||||
| 内部方法优先应用率 | ≥90% | ≥80% | <80% |
|
||||
| 用户障碍解决满意度 | ≥4.8/5 | ≥4.5/5 | <4.5/5 |
|
||||
|
||||
## 产品价值交付指标
|
||||
|
||||
| 指标类别 | 优秀标准 | 合格标准 | 改进标准 |
|
||||
|---------|----------|----------|----------|
|
||||
| 用户问题解决率 | ≥95% | ≥90% | <90% |
|
||||
| 功能使用率提升 | ≥50% | ≥40% | <40% |
|
||||
| 用户反馈积极性 | ≥85% | ≥80% | <80% |
|
||||
| 意外价值发现次数 | ≥3次/Sprint | ≥2次/Sprint | <2次/Sprint |
|
||||
|
||||
## 敏捷流程效率指标
|
||||
|
||||
| 指标类别 | 优秀标准 | 合格标准 | 改进标准 |
|
||||
|---------|----------|----------|----------|
|
||||
| Sprint目标达成率 | ≥90% | ≥85% | <85% |
|
||||
| 需求变更适应速度 | ≤0.5天 | ≤1天 | >1天 |
|
||||
| 团队决策效率提升 | ≥40% | ≥30% | <30% |
|
||||
| 知识积累和应用率 | ≥80% | ≥70% | <70% |
|
||||
</criteria>
|
||||
</execution>
|
||||
@ -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>
|
||||
@ -1,4 +1,28 @@
|
||||
<execution domain="project-management">
|
||||
|
||||
# Task设计核心理念
|
||||
|
||||
## 🛠️ Task = 解决问题的实现
|
||||
|
||||
```markdown
|
||||
Task的本质：解决具体技术实现问题
|
||||
核心思考：如何具体实现这个功能？
|
||||
|
||||
问题导向框架：
|
||||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||||
🛠️ 解决问题层: Task (技术实现) ← 我们在这里
|
||||
✅ 验证层: TestCase (质量保证)
|
||||
🎯 价值确认层: Milestone (交付确认)
|
||||
```
|
||||
|
||||
**Task的职责边界**：
|
||||
- ✅ 解决具体技术实现问题
|
||||
- ✅ 定义技术方案和开发步骤
|
||||
- ✅ 分配技术资源和时间规划
|
||||
- ✅ **必须关联到对应Story**（明确解决哪个用户问题）
|
||||
- ❌ 不重新定义用户需求
|
||||
- ❌ 不改变Story的验收标准
|
||||
|
||||
<process>
|
||||
# Task拆解流程
|
||||
|
||||
@ -83,12 +107,53 @@
|
||||
H --> B
|
||||
```
|
||||
|
||||
#### 4. Task-Story关联最佳实践
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Story分析] --> B[识别实现需求]
|
||||
B --> C{Task类型判断}
|
||||
C -->|开发Task| D[必须关联Story]
|
||||
C -->|独立Task| E[可不关联Story]
|
||||
|
||||
D --> F[设置story_id字段]
|
||||
F --> G[验收标准对齐]
|
||||
G --> H[进度状态同步]
|
||||
|
||||
E --> I[技术债务]
|
||||
E --> J[环境维护]
|
||||
E --> K[工具优化]
|
||||
```
|
||||
|
||||
**关联策略选择**:
|
||||
|
||||
| Task类型 | 是否关联Story | 关联方式 | 备注 |
|
||||
|----------|--------------|---------|------|
|
||||
| 功能开发 | ✅ 必须关联 | story_id字段 | 直接支撑用户故事 |
|
||||
| Bug修复 | ✅ 建议关联 | 关联相关Story | 如果修复已有功能 |
|
||||
| 测试编写 | ✅ 必须关联 | story_id字段 | 验证Story验收标准 |
|
||||
| 重构优化 | ✅ 建议关联 | 关联受影响Story | 如果影响现有功能 |
|
||||
| 技术债务 | ❌ 可不关联 | 独立Task | 技术改进类工作 |
|
||||
| 环境配置 | ❌ 可不关联 | 独立Task | 基础设施工作 |
|
||||
| 文档更新 | ⚠️ 视情况而定 | 关联相关Story | 如果是功能文档 |
|
||||
|
||||
**关联质量检查点**:
|
||||
|
||||
```markdown
|
||||
✅ Task验收标准支撑Story验收标准
|
||||
✅ Task完成后Story进度得到更新
|
||||
✅ Task优先级与Story优先级一致
|
||||
✅ Task负责人了解Story背景和目标
|
||||
✅ 项目管理工具中关联关系正确显示
|
||||
```
|
||||
|
||||
### Task标准模板
|
||||
|
||||
```markdown
|
||||
## T-{StoryID}-{序号}: {任务标题}
|
||||
|
||||
**基本信息**:
|
||||
- 关联Story: [Story ID] - {Story标题}
|
||||
- 任务类型: [开发/测试/设计/部署]
|
||||
- 负责人: [具体团队成员]
|
||||
- 预估工时: [1-16小时]
|
||||
@ -179,14 +244,22 @@
|
||||
- 必须有具体验收标准
|
||||
- 必须有清晰任务描述
|
||||
- 必须评估技术风险
|
||||
- **必须关联到对应Story**（除非是独立维护任务）
|
||||
|
||||
3. **依赖管理强制要求**
|
||||
3. **Task-Story关联强制要求**
|
||||
- 每个开发Task必须关联到具体Story
|
||||
- 在项目管理工具中正确设置story_id字段
|
||||
- Task验收标准必须支撑Story验收标准
|
||||
- Task完成状态必须反映Story进度
|
||||
- 独立Task（如环境维护、技术债务）可例外
|
||||
|
||||
4. **依赖管理强制要求**
|
||||
- 识别所有前置依赖
|
||||
- 标明阻塞影响关系
|
||||
- 提供解耦替代方案
|
||||
- 建立风险预警机制
|
||||
|
||||
4. **进度跟踪强制要求**
|
||||
5. **进度跟踪强制要求**
|
||||
- 每日更新Task状态
|
||||
- 及时反馈阻塞问题
|
||||
- 记录实际工时偏差
|
||||
@ -224,6 +297,7 @@
|
||||
|---------|---------|---------|-----------|
|
||||
| 拆解粒度 | 1-16h工作量精准控制 | 基本符合大小要求 | 过大过小影响执行 |
|
||||
| 任务定义 | 描述清晰标准具体 | 基本明确可执行 | 定义模糊难理解 |
|
||||
| Story关联性 | 所有Task正确关联Story | 大部分Task已关联 | 关联缺失或错误 |
|
||||
| 依赖管理 | 依赖识别完整有预案 | 主要依赖已识别 | 依赖遗漏频繁阻塞 |
|
||||
| 责任分工 | 责任明确负载均衡 | 基本分工合理 | 分工不明或负载失衡 |
|
||||
| 估算准确性 | 估算偏差<20% | 估算偏差<50% | 估算偏差>50% |
|
||||
|
||||
@ -1,4 +1,28 @@
|
||||
<execution domain="quality-assurance">
|
||||
|
||||
# TestCase设计核心理念
|
||||
|
||||
## ✅ TestCase = 验证问题解决得对不对
|
||||
|
||||
```markdown
|
||||
TestCase的本质：验证问题解决方案的正确性
|
||||
核心思考：这个问题真的被正确解决了吗？
|
||||
|
||||
问题导向框架：
|
||||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||||
🛠️ 解决问题层: Task (技术实现)
|
||||
✅ 验证层: TestCase (质量保证) ← 我们在这里
|
||||
🎯 价值确认层: Milestone (交付确认)
|
||||
```
|
||||
|
||||
**TestCase的职责边界**：
|
||||
- ✅ 验证Story的验收标准是否达成
|
||||
- ✅ 确保Task的实现符合预期
|
||||
- ✅ 保证用户问题得到正确解决
|
||||
- ✅ 防止新问题的引入（回归测试）
|
||||
- ❌ 不重新定义需求或实现方案
|
||||
- ❌ 不改变Story的验收标准
|
||||
|
||||
<process>
|
||||
# 测试用例设计流程
|
||||
|
||||
|
||||
@ -57,6 +57,11 @@
|
||||
- 确认里程碑的价值交付和市场反馈整合
|
||||
- 基于里程碑结果进行产品方向调整决策
|
||||
|
||||
- **Scrum最佳实践**：@!execution://scrum-best-practice
|
||||
- 掌握PromptX创新Scrum框架，超越传统敏捷实践
|
||||
- 应用障碍导向需求管理和Bottom-Up聚合方法
|
||||
- 建立AI增强的敏捷决策优先级体系
|
||||
|
||||
## 产品管理核心原则
|
||||
|
||||
1. **价值驱动**：所有决策以创造用户价值和商业价值为核心
|
||||
@ -113,17 +118,18 @@
|
||||
10. Sprint最佳实践: @!execution://sprint-best-practice
|
||||
11. Milestone最佳实践: @!execution://milestone-best-practice
|
||||
12. 工作项命名规范: @!execution://workitem-title-best-practice
|
||||
13. Scrum最佳实践: @!execution://scrum-best-practice
|
||||
## 🚨 完整性验证机制 🚨
|
||||
|
||||
**加载完成后必须进行三重检查：**
|
||||
|
||||
### Step 1: 数量检查
|
||||
确认已加载 **14个资源**，缺一不可！
|
||||
确认已加载 **15个资源**，缺一不可！
|
||||
|
||||
### Step 2: 分类检查
|
||||
- ✅ 核心系统: 4个资源全部加载
|
||||
- ✅ 角色能力: 2个资源全部加载
|
||||
- ✅ 最佳实践: 8个资源全部加载
|
||||
- ✅ 最佳实践: 9个资源全部加载
|
||||
|
||||
### Step 3: 能力确认
|
||||
**只有通过以下三个确认，才能宣布角色就绪：**
|
||||
|
||||
Reference in New Issue
Block a user