iriver/PromptX
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 完成DPML协议体系0～1阶段开发 - 三层协议架构100%实现，智能路径检测系统，@package://与package.json完美集成，用户项目集成方案，CLI框架完整实现，132/137核心测试通过(96.3%通过率)

Browse Source
This commit is contained in:
sean
2025-05-31 13:03:26 +08:00
parent 3338b7c21f
commit be285f55b8
89 changed files with 6071 additions and 467 deletions
Download Patch File Download Diff File Expand all files Collapse all files

192
prompt/domain/scrum/execution/epic-best-practice.execution.md Normal file
View File

@ -0,0 +1,192 @@
<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设计流程
```mermaid
flowchart TD
A[识别价值主题] --> B[定义Epic范围]
B --> C[设计Epic结构]
C --> D[制定验收标准]
D --> E[评估大小与依赖]
E --> F{质量检查}
F -->|通过| G[Epic就绪]
F -->|不通过| H[优化调整]
H --> B
A1[用户价值分析] --> A
A2[商业目标对齐] --> A
A3[技术价值识别] --> A
```
## 价值识别方法
```mermaid
mindmap
root((Epic价值))
用户价值
用户旅程痛点
核心使用场景
体验提升目标
商业价值
收入影响
成本优化
竞争优势
技术价值
架构改进
技术债还清
开发效率
```
## 📊 价值量化模板
```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数量 |
|---------|---------|---------|------------|
| 小型Epic | 20-40 SP | 2-3迭代 | 2-4个 |
| 中型Epic | 40-80 SP | 3-5迭代 | 4-8个 |
| 大型Epic | 80-120 SP | 5-6迭代 | 8-12个 |
### 验收标准设计
- **功能完整性**: 可测试的功能检查点
- **质量标准**: 性能、安全、可用性指标
- **商业指标**: 可量化的业务成功指标
</guideline>
<rule>
1. **INVEST原则必须遵循**
- Independent: Epic间依赖最小化
- Negotiable: 范围可协商调整
- Valuable: 有明确用户价值
- Estimable: 可进行工作量估算
- Small: 不超过6个迭代
- Testable: 有明确验收标准
2. **强制包含要素**
- 用户价值和商业价值必须明确
- 验收标准必须可测试和量化
- 依赖关系必须识别和记录
- 风险必须评估和应对
3. **范围控制规则**
- 单个Epic不超过120 Story Points
- 超过6迭代的必须拆分
- 不相关功能不得组合在同一Epic
</rule>
<constraint>
1. **团队能力约束**
- Epic大小受团队速度限制
- 技术复杂度受团队技能约束
- 并行开发Epic数量有限
2. **业务约束**
- 必须与产品路线图对齐
- 受预算和时间窗口限制
- 合规和安全要求约束
3. **技术约束**
- 现有架构和技术债务影响
- 第三方集成依赖限制
- 性能和扩展性要求约束
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 价值清晰度 | 用户价值和商业价值都明确量化 | 价值描述清晰但部分未量化 | 价值模糊或无法说清 |
| 范围合理性 | 边界清晰，大小适中，内聚性强 | 边界基本清晰，大小可控 | 范围模糊或过大过小 |
| 验收标准 | 标准具体可测，覆盖功能质量业务 | 标准基本明确可测试 | 标准模糊或不可测 |
| 依赖管理 | 依赖最小化，风险已识别应对 | 依赖已识别，风险可控 | 依赖复杂或风险未评估 |
| INVEST符合度 | 完全符合INVEST原则 | 基本符合，个别项有改进空间 | 不符合多个INVEST原则 |
**快速检查要点**：
📝 **问题导向**: 标题描述问题而非解决方案，避免"构建"、"开发"等技术词汇
💰 **价值量化**: 用户价值和商业价值必须量化，有清晰成功指标
🎯 **范围边界**: 包含/不包含列表清晰，单一问题域，6个迭代内完成
📊 **可执行性**: 验收标准具体可测，可拆分为独立Feature，风险已识别
</criteria>
</execution>

216
prompt/domain/scrum/execution/feature-best-practice.execution.md Normal file
View File

@ -0,0 +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[识别功能场景痛点]
B --> C[定义问题边界]
C --> D[分析用户困难]
D --> E[制定问题解决标准]
E --> F[Story问题拆解规划]
F --> G{问题完整性验证}
G -->|完整| H[Feature就绪]
G -->|不完整| I[补充问题分析]
I --> B
B1[用户旅程断点分析] --> B
B2[任务执行障碍识别] --> B
B3[体验缺失评估] --> B
```
## Feature问题识别方法
```mermaid
mindmap
root((问题识别))
用户体验断点
任务中断节点
操作困难环节
反馈缺失场景
功能缺失分析
必要能力缺失
信息获取障碍
操作效率低下
技术约束导致的用户问题
性能瓶颈影响
兼容性问题
稳定性缺陷
```
## 📊 问题影响量化模板
```markdown
### 用户痛点量化
- 具体困难: [用户遇到的具体问题，如"配置角色需要10个步骤"]
- 影响范围: [受影响用户比例，如"80%的新用户"]
- 困难成本: [时间/错误损失，如"平均失败3次才成功"]
- 当前缺失: [什么能力的缺失导致了这个问题]
### 功能缺失分析
- 缺失能力: [具体缺少什么功能支持]
- 导致后果: [缺失导致的用户困难]
- 替代方案: [用户当前如何绕过这个问题]
- 绕过成本: [替代方案的额外成本]
### 改善期望
- 期望体验: [解决问题后用户应该有什么体验]
- 成功指标: [如何衡量问题得到解决]
- 优先级: [相对其他问题的重要程度]
```
</process>
<guideline>
### Feature问题定义建议
- **问题完整性**: Feature应代表完整的问题域，用户困难有明确边界
- **技术边界对应**: 问题域对应技术模块边界，便于解决方案设计
- **用户可感知**: 问题是用户直接体验到的困难和障碍
- **中等粒度**: 1-3个迭代解决，包含3-8个具体问题点(Story)
### 问题复杂度分级
| 问题类型 | 复杂度 | 解决时间 | Story数量 | 影响范围 |
|---------|-------|---------|-----------|---------|
| 简单问题域 | 低 | 1迭代 | 2-4个Story | 单一场景 |
| 标准问题域 | 中 | 1-2迭代 | 4-6个Story | 多个相关场景 |
| 复杂问题域 | 高 | 2-3迭代 | 6-8个Story | 跨场景影响 |
### 问题边界定义
- **包含痛点**: 列出具体的用户困难和障碍点
- **不包含问题**: 防止范围扩散，明确排除的问题
- **问题依赖**: 此问题与其他问题的关联和依赖
- **影响接口**: 解决此问题对其他功能域的影响
### Story问题拆解策略
```mermaid
flowchart LR
A[Feature问题域] --> B[核心困难Story]
A --> C[操作障碍Story]
A --> D[信息缺失Story]
A --> E[反馈不足Story]
B --> B1[主要痛点]
C --> C1[操作困难]
D --> D1[信息获取问题]
E --> E1[状态不明确]
```
</guideline>
<rule>
1. **四个核心原则必须遵循**
- 问题完整性: Feature代表完整问题域
- 用户视角: 从用户困难角度定义问题
- 可观察性: 问题是用户直接感受到的
- 边界清晰: 问题域边界明确不重叠
2. **强制包含要素**
- 用户痛点必须具体可观察
- 问题边界必须明确定义（包含/不包含痛点）
- 解决标准必须具体可验证
- Story问题拆解必须覆盖核心困难
- 问题依赖必须识别和记录
3. **三层问题关系规则**
- Epic → Feature: 价值问题到功能域问题的分解
- Feature → Story: 功能域问题到具体用户困难的拆解
- 层级间问题粒度跨度合理，避免过度拆分或粗糙
4. **拆分触发条件**
- 问题域跨越3个以上技术模块需要拆分
- 包含不相关困难点需要重新组织
- 解决时间超过3个迭代需要拆分
</rule>
<constraint>
1. **技术架构约束**
- 问题域边界受现有架构模块限制
- 微服务边界影响问题解决方案
- 数据模型设计影响问题解决范围
2. **团队能力约束**
- 并行解决问题数量有限
- 团队技能影响问题解决复杂度
- 跨团队问题需要额外协调成本
3. **用户体验约束**
- 用户旅程完整性不可打断
- 渐进式改善对问题解决颗粒度的要求
- 问题优先级受用户影响程度限制
4. **项目约束**
- 迭代时间盒限制问题解决范围
- 测试资源影响问题验证
- 发布节奏影响问题解决优先级
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 问题清晰度 | 用户痛点具体可观察，困难描述准确 | 问题基本清晰可理解 | 问题模糊或偏向解决方案 |
| 边界合理性 | 问题域边界清晰，困难点内聚相关 | 边界基本清晰 | 边界模糊或问题分散 |
| 用户视角 | 完全从用户困难角度描述问题 | 基本体现用户视角 | 偏向系统或技术视角 |
| 影响量化 | 问题影响范围和程度量化清晰 | 影响基本明确 | 影响不明确或无量化 |
| 可解决性 | 问题有明确解决标准和验证方式 | 基本可解决验证 | 问题过于抽象或无法验证 |
| Story拆解质量 | 问题拆解全面，困难点粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
| 问题导向性 | 避免解决方案描述，纯问题导向 | 基本问题导向 | 混合解决方案或功能描述 |
**快速检查要点**：
📝 **问题导向**: 描述用户困难而非功能需求，避免"需要"、"提供"、"实现"等词汇
🎯 **用户视角**: 从用户遇到的具体障碍和痛点角度定义问题
📊 **困难量化**: 用户痛点影响范围和程度必须量化，有明确解决标准
🔍 **边界清晰**: 问题域边界明确，困难点内聚，可独立解决和验证
</criteria>
</execution>

336
prompt/domain/scrum/execution/milestone-best-practice.execution.md Normal file
View File

@ -0,0 +1,336 @@
<execution domain="project-management">
# Milestone设计核心理念
## 🎯 Milestone = 价值交付确认节点
```markdown
Milestone的本质：确认阶段性问题解决和价值交付
核心思考：这个阶段的问题解决了吗？价值交付了吗？
问题导向框架：
📋 提问题层: Epic → Feature → Story (需求定义)
🛠️ 解决问题层: Task (技术实现)
✅ 验证层: TestCase (质量保证)
🎯 价值确认层: Milestone (交付确认) ← 我们在这里
```
**Milestone的职责边界**：
- ✅ 确认用户价值的实际交付
- ✅ 验证商业目标的达成状况
- ✅ 标记问题解决的重要节点
- ✅ 为后续问题解决提供决策依据
- ❌ 不重新定义问题或解决方案
- ❌ 不改变Epic/Feature/Story的目标
<process>
# Milestone管理流程
```mermaid
flowchart TD
A[产品愿景] --> B[Epic Milestone规划]
B --> C[Feature Milestone分解]
C --> D[Sprint目标对齐]
D --> E[Milestone执行]
E --> F[进度监控]
F --> G[风险评估]
G --> H{状态判断}
H -->|绿色| I[正常推进]
H -->|黄色| J[密切关注]
H -->|红色| K[立即调整]
I --> L[里程碑达成]
J --> L
K --> M[应急计划]
M --> L
L --> N[价值确认]
N --> O[经验总结]
```
## Milestone分层体系
```mermaid
mindmap
root((Milestone体系))
Epic级里程碑
战略价值节点
3-6个月周期
重大业务能力
市场发布节点
Feature级里程碑
功能完整性
4-8周周期
模块级交付
用户价值体现
Sprint级里程碑
迭代增量
1-2周周期
可演示功能
团队承诺
质量里程碑
代码完成
集成测试
用户验收
性能达标
```
</process>
<guideline>
### Milestone设定方法(SMART-M)
#### SMART-M原则应用
```markdown
Specific(具体的):
- 明确定义交付内容和范围边界
- 清晰的可交付物清单
- 避免模糊或抽象的描述
Measurable(可测量的):
- 定量的完成标准和质量指标
- 可验证的验收标准
- 明确的成功衡量方法
Achievable(可达成的):
- 基于团队能力的现实评估
- 考虑依赖和风险因素
- 合理的时间和资源分配
Relevant(相关的):
- 与业务目标和产品战略对齐
- 支持更高层级的里程碑
- 对利益相关者有明确价值
Time-bound(有时限的):
- 明确的完成日期
- 包含适当的时间缓冲
- 关键路径和依赖时间分析
Motivating(激励性的):
- 团队能看到价值和成就感
- 适度的挑战性
- 明确的庆祝和认可方式
```
#### Milestone模板结构
```markdown
## M{编号}: {里程碑名称}
**基本信息**:
- 类型: [业务/技术/交付/质量]
- 层级: [Epic/Feature/Sprint]
- 目标日期: [YYYY-MM-DD]
- 负责团队: [具体团队]
**里程碑目标**:
[一句话描述核心目标和价值]
**主要交付物**:
- [ ] 交付物1: 具体可验证的成果
- [ ] 交付物2: 具体可验证的成果
- [ ] 交付物3: 具体可验证的成果
**成功标准**:
- [ ] 定量指标1 (>=目标值)
- [ ] 质量要求2 (通过标准)
- [ ] 用户验证3 (满意度>=阈值)
**依赖关系**:
- 前置里程碑: [必须先完成的里程碑]
- 后续影响: [依赖本里程碑的后续工作]
- 外部依赖: [其他团队或外部条件]
**风险应对**:
- 主要风险: [描述] → [应对策略]
- 应急计划: [Plan B方案]
- 早期预警: [风险信号识别]
```
### Milestone分类管理
#### 按性质分类策略
| 类型 | 特征 | 周期 | 示例 |
|------|------|------|------|
| 业务里程碑 | 市场价值导向 | 季度级 | MVP发布、新功能上线 |
| 技术里程碑 | 技术能力建设 | 月度级 | 架构完成、性能达标 |
| 交付里程碑 | 阶段性成果 | 双周级 | Alpha版本、集成完成 |
| 质量里程碑 | 质量标准达成 | 持续 | 测试通过、审核认证 |
#### 按层级管理策略
```markdown
Epic Milestone (3-6个月):
- 每个Epic设置2-4个关键里程碑
- 重点关注业务价值和市场影响
- 跨团队协调和依赖管理
Feature Milestone (4-8周):
- 标记功能模块的完整性节点
- 用户可感知的价值交付
- 技术和业务目标平衡
Sprint Milestone (1-2周):
- 每个Sprint的具体承诺
- 可演示的功能增量
- 团队内部的节奏控制
```
### Milestone跟踪监控
#### 状态管理体系
```mermaid
stateDiagram-v2
[*] --> 计划中
计划中 --> 进行中: 开始执行
进行中 --> 风险中: 发现风险
进行中 --> 已完成: 达成目标
风险中 --> 进行中: 风险解决
风险中 --> 延迟: 确认延期
风险中 --> 已完成: 成功挽回
延迟 --> 已完成: 调整后完成
已完成 --> [*]
```
#### 监控指标体系
```markdown
进度指标:
- 里程碑完成率 = 已完成数 / 计划总数
- 按时完成率 = 按时完成数 / 已完成数
- 平均延迟天数 = 延迟总天数 / 延迟里程碑数
质量指标:
- 交付物完整度 = 实际交付 / 计划交付
- 一次通过率 = 一次验收通过 / 总里程碑数
- 返工率 = 需要返工数 / 已完成数
预测指标:
- 预计完成时间 (基于当前进度趋势)
- 资源消耗率 = 实际消耗 / 计划消耗
- 风险里程碑占比 = 风险状态数 / 总进行中数
```
#### 预警响应机制
| 预警级别 | 触发条件 | 响应行动 | 升级机制 |
|----------|----------|----------|----------|
| 🟢 绿色 | 进度正常，无重大风险 | 正常监控 | - |
| 🟡 黄色 | 轻微延期或存在风险 | 加强关注，调整资源 | 1周内升级 |
| 🔴 红色 | 严重延期或阻塞 | 立即干预，启动应急计划 | 立即升级 |
### Milestone与敏捷集成
#### 与Sprint的关系
```markdown
Sprint-Milestone映射策略:
1. 里程碑驱动Sprint Planning
- Sprint Goal与里程碑目标对齐
- 优先选择推进里程碑的Story
- 量化Sprint对里程碑的贡献度
2. Sprint Review中的里程碑检查
- 评估里程碑进展情况
- 识别里程碑风险和调整需求
- 基于里程碑调整Product Backlog
3. 里程碑贡献度跟踪
Sprint 1-2 → M1.1(试卷结构管理) 贡献40%
Sprint 3-4 → M1.1(试卷结构管理) 贡献60%
Sprint 5-6 → M1.2(内容管理) 贡献35%
```
#### 跨团队里程碑协调
```markdown
依赖里程碑管理:
1. 依赖识别和规划
- 建立跨团队里程碑依赖图
- 识别关键路径和瓶颈
- 设定依赖交付的缓冲时间
2. 协调同步机制
- 周度依赖状态同步
- 月度跨团队里程碑对齐
- 风险升级和决策流程
3. 共享里程碑管理
- 明确各团队责任分工
- 统一验收标准和流程
- 建立联合庆祝机制
```
</guideline>
<rule>
1. **里程碑设定强制要求**
- 每个Epic必须有2-4个关键里程碑
- 里程碑必须符合SMART-M原则
- 所有里程碑必须有明确责任人
- 里程碑间隔不超过3个月
2. **进度跟踪强制要求**
- 每周更新里程碑状态
- 风险里程碑必须有应对计划
- 延期里程碑必须重新规划
- 里程碑变更需要正式审批
3. **质量门禁强制要求**
- 里程碑完成必须通过质量验收
- 技术里程碑必须有量化指标
- 业务里程碑必须有用户验证
- 不达标里程碑不允许发布
4. **协调同步强制要求**
- 跨团队里程碑必须建立同步机制
- 依赖里程碑必须提前协调
- 共享里程碑必须明确分工
- 里程碑冲突必须升级决策
</rule>
<constraint>
1. **时间约束**
- 市场窗口时间限制
- 资源可用时间限制
- 依赖交付时间约束
- 法规合规时间要求
2. **资源约束**
- 团队人力资源限制
- 技术平台资源约束
- 预算和成本限制
- 外部供应商能力约束
3. **技术约束**
- 现有技术架构限制
- 技术债务影响
- 第三方系统依赖
- 性能和规模约束
4. **业务约束**
- 市场竞争压力
- 客户期望和承诺
- 合规和监管要求
- 商业模式限制
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 里程碑完成率 | >95%按时完成 | >80%按时完成 | <80%按时完成 |
| 价值交付质量 | 超出预期的价值 | 达到预期价值 | 价值交付不足 |
| 风险管控 | 风险前置有效预防 | 风险及时识别应对 | 风险管控不足 |
| 团队协调 | 跨团队协作顺畅 | 基本协调有效 | 协调困难频繁冲突 |
| 透明度 | 进度状态完全透明 | 基本信息透明 | 信息不透明 |
| 利益相关者满意度 | 高度满意获得认可 | 基本满意 | 不满意有抱怨 |
| 持续改进 | 里程碑执行不断优化 | 有基本改进 | 缺乏改进机制 |
| 庆祝文化 | 里程碑成就获得庆祝 | 有基本认可 | 缺乏成就感 |
</criteria>
</execution>

199
prompt/domain/scrum/execution/product-owner.execution.md Normal file
View File

@ -0,0 +1,199 @@
<execution domain="scrum-role">
<process>
# 产品负责人角色流程
```mermaid
flowchart TD
A[产品愿景制定] --> B[战略优先级决策]
B --> C[跨实践角色协调]
C --> D[Epic规划决策]
C --> E[Sprint规划参与]
C --> F[里程碑价值确认]
D --> G[价值验证评估]
E --> G
F --> G
G --> H{价值目标达成?}
H -->|是| I[利益相关者沟通]
H -->|否| J[策略调整决策]
I --> K[持续市场监控]
J --> B
K --> L{需要战略调整?}
L -->|是| B
L -->|否| C
```
## PO在最佳实践中的角色
```mermaid
mindmap
root((Product Owner))
Epic管理
战略价值定义
业务目标对齐
投资回报决策
Feature管理
功能模块设计
技术边界定义
架构可行性评估
Story管理
用户价值验证
验收标准确认
优先级决策
Sprint执行
目标价值澄清
范围变更决策
演示价值确认
Milestone管理
价值交付确认
市场反馈整合
方向调整决策
```
</process>
<guideline>
### PO核心职责边界
#### 决策权限范围
```markdown
✅ PO负责决策的领域:
- 产品愿景和战略方向
- Epic和Story的业务优先级
- Feature的功能边界和技术架构选择
- 用户需求的价值判断
- Sprint Goal的业务价值定义
- 产品功能的取舍决策
- 市场反馈的产品调整
❌ PO不应干预的领域:
- 具体代码实现细节
- 团队内部Task分配和执行方式
- 开发工具和框架的具体选择
- 团队绩效管理和人员安排
- 基础设施的运维操作
```
#### 跨实践协调策略
| Best Practice | 核心贡献 | 决策权限 |
|---------------|----------|----------|
| Epic Best Practice | 价值定义、优先级排序 | 完全决策权 |
| Feature Best Practice | 功能设计、技术边界定义 | 完全决策权 |
| Story Best Practice | 验收标准确认、价值澄清 | 完全决策权 |
| Sprint Best Practice | Goal价值澄清、演示确认 | 范围调整决策权 |
| Milestone Best Practice | 价值交付确认、方向调整 | 里程碑价值决策权 |
### 价值衡量与决策
#### 价值评估框架
```mermaid
graph TD
A[业务需求] --> B{价值评估}
B --> C[用户价值分析]
B --> D[商业价值分析]
B --> E[技术价值分析]
C --> F[优先级矩阵]
D --> F
E --> F
F --> G{资源约束下的选择}
G --> H[高价值低成本: 立即执行]
G --> I[高价值高成本: 计划执行]
G --> J[低价值低成本: 考虑执行]
G --> K[低价值高成本: 暂缓执行]
```
#### 数据驱动决策
```markdown
关键指标跟踪:
- 用户活跃度和留存率
- 功能使用率和满意度
- 业务转化率和收入影响
- 市场份额和竞争地位
反馈收集渠道:
- 用户访谈和问卷调研
- 产品使用数据分析
- 客户支持反馈整理
- 市场和竞争对手分析
决策调整机制:
- 每Sprint Review收集反馈
- 每月数据分析和趋势评估
- 每季度战略方向评估
- 年度产品愿景回顾
```
</guideline>
<rule>
1. **价值责任制**
- PO对产品业务价值负最终责任
- 所有产品决策必须基于用户和商业价值
- 拒绝没有明确价值的功能请求
- 定期评估和调整产品价值假设
2. **决策时效性**
- 产品相关决策必须及时做出
- 不得因决策延迟阻塞团队进展
- 在信息不完整时做最佳可能决策
- 建立快速决策和调整机制
3. **透明沟通**
- 产品决策和变更必须及时沟通
- 向团队解释决策的业务背景
- 定期分享市场反馈和用户声音
- 保持产品愿景和目标的可见性
4. **数据驱动**
- 重要决策必须有数据支撑
- 定期检查产品假设和实际结果
- 基于用户反馈调整产品方向
- 避免基于个人偏好的决策
</rule>
<constraint>
1. **组织约束**
- 企业战略和政策限制
- 跨部门协作复杂性
- 预算和资源分配限制
- 法规合规要求约束
2. **市场约束**
- 竞争环境和时间窗口
- 用户采纳周期和习惯
- 技术成熟度和可行性
- 商业模式和盈利压力
3. **团队约束**
- 开发团队技能和容量
- 技术债务和架构限制
- 团队自治和决策边界
- 沟通协调成本和效率
4. **信息约束**
- 市场信息的不完整性
- 用户需求的不确定性
- 技术可行性的不确定性
- 竞争对手行为的不可预测性
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 价值交付 | 持续交付超预期价值 | 基本达成价值目标 | 价值交付不足 |
| 决策效率 | 决策及时推动项目 | 基本及时决策 | 决策延迟阻塞进展 |
| 利益相关者满意度 | 各方高度认可 | 基本满意 | 存在明显不满 |
| 市场响应 | 敏捷应对变化 | 跟上市场节奏 | 反应迟缓错失机会 |
| 团队协作 | 团队高度信任协作 | 基本协作顺畅 | 协作存在摩擦 |
| 数据驱动程度 | 决策完全基于数据 | 主要决策有数据支撑 | 多凭直觉决策 |
| 产品愿景清晰度 | 愿景明确全员认同 | 愿景基本清晰 | 愿景模糊多变 |
| 业务成果 | 显著推动业务增长 | 对业务有正面影响 | 业务影响不明显 |
</criteria>
</execution>

217
prompt/domain/scrum/execution/scrum-best-practice.execution.md Normal file
View 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>

283
prompt/domain/scrum/execution/sprint-best-practice.execution.md Normal file
View File

@ -0,0 +1,283 @@
<execution domain="agile-management">
<process>
# Sprint执行流程
```mermaid
flowchart TD
A[Product Backlog] --> B[Sprint Planning]
B --> C[Sprint Backlog + Goal]
C --> D[Sprint执行]
D --> E[Daily Standup]
D --> F[开发活动]
D --> G[监控调整]
E --> H[Sprint Review]
F --> H
G --> H
H --> I[Sprint Retrospective]
I --> J[持续改进]
H --> K[Product Increment]
K --> L[下一个Sprint]
J --> L
```
## Sprint核心活动
```mermaid
mindmap
root((Sprint执行))
Sprint Planning
Part1: 做什么
Part2: 怎么做
容量规划
Goal制定
Daily Standup
三个问题
阻塞识别
进度同步
时间控制
Sprint Review
产品演示
反馈收集
Backlog调整
价值确认
Sprint Retrospective
经验总结
问题识别
改进行动
持续优化
```
</process>
<guideline>
### Sprint Planning执行
#### Part 1: 做什么 (4小时/2周Sprint)
```markdown
主导: Product Owner
1. Sprint Goal阐述 (30分钟)
- 一句话描述核心价值
- 明确成功标准
- 确认业务优先级
2. Product Backlog梳理 (2小时)
- 选择Sprint候选Story
- 澄清需求和验收标准
- 识别Story间依赖关系
3. 容量规划 (1小时)
- 评估团队可用工时
- 基于历史速度估算
- 考虑风险和缓冲时间
4. 初步承诺 (30分钟)
- 团队确认Story选择
- 验证Goal可达成性
```
#### Part 2: 怎么做 (4小时/2周Sprint)
```markdown
主导: Development Team
1. Story拆解为Task (2小时)
- 按技能领域分工
- 识别技术依赖
- 估算Task工时
2. 技术方案设计 (1.5小时)
- API接口设计
- 架构决策
- 风险识别和应对
3. 最终承诺 (30分钟)
- 基于详细分析调整
- 确认Sprint Backlog
- 建立团队共识
```
### Daily Standup执行 (15分钟)
```markdown
标准三问题格式:
每个团队成员 (90秒/人):
1. 昨天完成了什么？(对Goal的贡献)
2. 今天计划做什么？(如何推进Goal)
3. 遇到什么阻碍？(影响Goal达成的障碍)
Scrum Master关注:
- Goal达成风险评估
- 阻塞问题跟进计划
- 团队协作需求
效率提升技巧:
- 面向看板讨论
- 推迟技术细节到会后
- 设置15分钟计时器
- 聚焦Sprint Goal相关性
```
### Sprint Review执行 (2小时/2周Sprint)
#### 演示结构模板
```markdown
1. 开场回顾 (15分钟)
- Sprint Goal和承诺回顾
- 完成情况概览
- 演示重点介绍
2. 产品演示 (60分钟)
- 按用户场景演示功能
- 展示业务价值实现
- 邀请利益相关者操作
3. 反馈收集 (30分钟)
- 开放式问题讨论
- 记录改进建议
- 确认价值交付
4. Backlog调整 (15分钟)
- 基于反馈调整优先级
- 添加新发现需求
- 估算影响范围
```
#### 演示最佳实践
| 原则 | 实践方法 | 注意事项 |
|------|---------|---------|
| 用户视角 | 真实用户场景演示 | 避免技术细节展示 |
| 价值导向 | 强调解决的实际问题 | 量化改进效果 |
| 互动参与 | 邀请利益相关者操作 | 收集即时反馈 |
| 完整体验 | 展示端到端工作流程 | 使用真实数据 |
### Sprint Retrospective执行 (90分钟/2周Sprint)
#### Start/Stop/Continue模式
```markdown
1. 设定基调 (10分钟)
- 强调安全环境
- 重申改进目标
2. 信息收集 (30分钟)
Start(开始做): 新的有效实践
Stop(停止做): 无效的活动或流程
Continue(继续做): 已证明有效的实践
3. 生成洞察 (20分钟)
- 识别问题根本原因
- 分析改进优先级
4. 行动计划 (20分钟)
- 选择1-3个改进项
- 分配责任人和时间点
- 制定成功衡量标准
5. 总结收尾 (10分钟)
- 确认行动项共识
- 安排跟进机制
```
### Sprint监控与调整
#### 关键监控指标
```mermaid
graph TD
A[燃尽图趋势] --> B{进度预警}
C[Story完成率] --> B
D[质量指标] --> B
E[团队协作] --> B
B -->|绿色| F[正常执行]
B -->|黄色| G[密切关注]
B -->|红色| H[立即调整]
H --> I[容量调整]
H --> J[范围调整]
H --> K[质量保障]
```
#### 调整策略矩阵
| 问题类型 | 立即行动 | 预防措施 |
|----------|----------|----------|
| 容量过载 | 重新评估Story优先级 | 更保守的容量估算 |
| 质量问题 | 暂停新功能开发 | 强化TDD和代码审查 |
| 依赖阻塞 | 启用Mock方案 | 前置依赖识别 |
| 需求变更 | 评估对Goal影响 | 建立变更决策矩阵 |
</guideline>
<rule>
1. **Sprint时间盒强制要求**
- Sprint长度固定不可延长
- 所有活动严格控制时间
- Planning不超过8小时(2周Sprint)
- Daily Standup不超过15分钟
2. **Sprint Goal强制要求**
- 每个Sprint必须有明确Goal
- Goal使用SMART原则制定
- 所有Story必须支撑Goal
- Goal达成情况必须可衡量
3. **团队承诺强制要求**
- 基于历史数据做容量规划
- 团队自主选择Sprint Backlog
- 承诺后的Scope变更需全员同意
- 未完成Story自动返回Backlog
4. **持续改进强制要求**
- 每个Sprint必须执行Retrospective
- 识别的问题必须制定行动计划
- 改进行动必须有责任人和时间点
- 下个Sprint开始时检查改进执行
</rule>
<constraint>
1. **时间约束**
- Sprint固定时间盒(1-4周)
- 团队可用工时有限
- 会议时间占比控制
- 发布窗口时间限制
2. **团队约束**
- 团队技能组合限制
- 人员可用性变化
- 学习曲线时间成本
- 协作沟通开销
3. **技术约束**
- 现有技术架构限制
- 第三方服务依赖
- 环境和工具限制
- 技术债务影响
4. **业务约束**
- 需求变更频率
- 利益相关者可用性
- 合规和安全要求
- 市场时间窗口
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| Goal达成度 | 100%达成且超出预期 | 基本达成主要目标 | Goal达成度<80% |
| 承诺兑现率 | Story完成率>90% | Story完成率>70% | Story完成率<70% |
| 质量标准 | 零质量问题交付 | 少量非关键问题 | 质量问题影响使用 |
| 团队协作 | 高效协作无阻塞 | 基本协作顺畅 | 频繁阻塞和等待 |
| 持续改进 | 每Sprint有效改进 | 基本改进执行 | 改进措施不落地 |
| 利益相关者满意度 | 高度满意超预期 | 基本满意 | 不满意需要调整 |
| 团队速度稳定性 | 速度稳定可预测 | 速度基本稳定 | 速度波动太大 |
| 技术债务管理 | 债务控制良好 | 债务基本可控 | 债务积累影响效率 |
</criteria>
</execution>

350
prompt/domain/scrum/execution/story-best-practice.execution.md Normal file
View File

@ -0,0 +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[分析任务执行障碍]
C --> D[编写障碍描述格式]
D --> E[INVEST原则验证]
E --> F[编写问题解决标准]
F --> G{障碍完整性检查}
G -->|完整| H[Story就绪]
G -->|不完整| I[补充障碍分析]
I --> C
B1[主要任务路径] --> B
B2[异常处理路径] --> B
B3[边界操作场景] --> B
```
## Story障碍识别方法
```mermaid
mindmap
root((障碍识别))
操作困难
步骤繁琐复杂
操作容易出错
学习成本高
信息缺失
状态不明确
反馈不及时
结果不可见
流程中断
等待时间长
依赖不可用
错误恢复困难
体验痛点
操作重复冗余
界面不友好
响应速度慢
```
## 📊 任务障碍量化模板
```markdown
### 具体障碍描述
- 任务场景: [用户尝试完成什么具体任务]
- 遇到困难: [在哪个步骤遇到什么障碍]
- 困难表现: [障碍如何具体表现，如错误、延时、复杂]
- 当前处理: [用户如何绕过或处理这个障碍]
### 障碍影响分析
- 影响频率: [多少比例的用户会遇到此障碍]
- 困难程度: [障碍对任务完成的阻碍程度]
- 时间成本: [障碍导致的额外时间损失]
- 错误风险: [障碍可能导致的错误概率]
### 解决期望
- 理想体验: [障碍消除后用户应该有什么体验]
- 成功标准: [如何验证障碍得到解决]
- 性能指标: [时间、错误率等具体改善目标]
```
</process>
<guideline>
### Story障碍描述标准格式
```
作为 [具体用户角色]
我在 [执行具体任务时]
遇到 [具体障碍和困难]
导致 [任务中断或效率低下的后果]
```
- **用户角色**: 具体明确，避免"用户"这样的泛化表达
- **任务场景**: 具体的任务执行情境，不是抽象目标
- **障碍描述**: 详细说明遇到的具体困难和阻碍
- **影响后果**: 明确障碍对任务完成造成的具体影响
### 障碍解决标准编写(GWT格式)
```
给定 [用户执行任务的初始状态]
当 [用户遇到特定障碍情况时]
那么 [障碍应该如何被消除或减轻]
```
- **覆盖障碍场景**: 主要障碍、边界情况、异常处理
- **解决标准具体**: 避免主观词汇，使用可验证的改善标准
- **完整性**: 操作改善、信息改善、体验改善
### Story障碍复杂度分级
| 障碍类型 | 复杂度 | 解决时间 | Story Points | 影响范围 |
|---------|-------|---------|-------------|---------|
| 简单操作障碍 | 低 | 0.5-1天 | 1-2点 | 单一操作 |
| 标准任务障碍 | 中 | 1-3天 | 3-5点 | 任务流程 |
| 复杂体验障碍 | 高 | 3-5天 | 8点(需拆分) | 跨任务影响 |
### Story到Task问题解决策略
```mermaid
flowchart LR
A[Story障碍] --> B[前端改善Tasks]
A --> C[后端改善Tasks]
A --> D[体验优化Tasks]
A --> E[其他Tasks]
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: 有具体改善标准，可验证障碍消除
2. **Story格式强制要求**
- 必须使用"作为...我在...遇到...导致..."障碍描述格式
- 用户角色必须具体明确，不能使用"用户"泛称
- 任务场景必须具体，避免抽象的目标描述
- 障碍描述必须具体可观察，避免解决方案暗示
- 影响后果必须明确，说明障碍造成的具体问题
3. **解决标准强制要求**
- 必须使用Given-When-Then格式描述改善标准
- 至少包含3个场景：正常改善、异常处理、边界优化
- 标准必须具体可测，避免主观判断
- 必须包含操作改善、体验改善、性能改善标准
4. **拆分触发条件**
- 超过8 Story Points必须拆分
- 解决时间超过1周必须拆分
- 涉及多个用户角色的障碍需要拆分
- 包含技术复杂性或不确定性需要拆分
</rule>
<constraint>
1. **用户认知约束**
- 用户对系统理解程度影响障碍识别
- 用户技能水平影响障碍严重程度
- 用户使用习惯影响障碍感知
2. **技术实现约束**
- 现有架构限制障碍解决方案
- 性能瓶颈影响体验改善程度
- 兼容性要求限制改善范围
3. **业务流程约束**
- 业务规则限制流程优化
- 合规要求影响操作简化
- 数据安全约束体验改善
4. **项目资源约束**
- 迭代时间限制障碍解决数量
- 测试资源影响改善验证
- 人员技能影响障碍解决复杂度
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| INVEST符合度 | 完全符合6个INVEST原则 | 基本符合，个别项可改进 | 不符合多个INVEST原则 |
| 障碍描述质量 | 障碍具体可观察，场景明确 | 基本清晰可理解 | 障碍模糊或偏向功能需求 |
| 格式规范性 | 严格按照障碍描述格式 | 基本符合格式要求 | 格式不规范或要素缺失 |
| 用户视角 | 完全从用户困难角度描述 | 基本体现用户视角 | 偏向系统或解决方案视角 |
| 影响量化 | 障碍影响具体可量化 | 影响基本明确 | 影响不明确或过于抽象 |
| 独立性 | 障碍独立可单独解决 | 基本独立，少量依赖 | 严重依赖其他Story |
| 可验证性 | 改善标准具体可重复执行 | 基本可测试验证 | 难以验证或标准主观 |
| 复杂度合理性 | 1-2周解决，复杂度适中 | 大小基本合理 | 过大过小影响解决效果 |
**快速检查要点**：
📝 **障碍导向**: 描述用户困难而非功能需求，避免"想要"、"需要"、"希望"等词汇
🎯 **任务具体**: 从用户执行具体任务的障碍角度定义问题
📊 **困难量化**: 障碍影响和后果必须具体可观察，有明确改善标准
🔍 **场景明确**: 任务场景具体，障碍描述准确，可独立解决和验证
</criteria>
</execution>

308
prompt/domain/scrum/execution/task-best-practice.execution.md Normal file
View File

@ -0,0 +1,308 @@
<execution domain="project-management">
# Task设计核心理念
## 🛠️ Task = 解决问题的实现
```markdown
Task的本质：解决具体技术实现问题
核心思考：如何具体实现这个功能？
问题导向框架：
📋 提问题层: Epic → Feature → Story (需求定义)
🛠️ 解决问题层: Task (技术实现) ← 我们在这里
✅ 验证层: TestCase (质量保证)
🎯 价值确认层: Milestone (交付确认)
```
**Task的职责边界**：
- ✅ 解决具体技术实现问题
- ✅ 定义技术方案和开发步骤
- ✅ 分配技术资源和时间规划
- ✅ **必须关联到对应Story**（明确解决哪个用户问题）
- ❌ 不重新定义用户需求
- ❌ 不改变Story的验收标准
<process>
# Task拆解流程
```mermaid
flowchart TD
A[Story分析] --> B[确定拆解策略]
B --> C[识别Task边界]
C --> D[分配责任人]
D --> E[评估依赖关系]
E --> F[时间估算]
F --> G{质量检查}
G -->|通过| H[Task就绪]
G -->|不通过| I[重新拆解]
I --> C
B --> B1[技能领域拆解]
B --> B2[开发阶段拆解]
B --> B3[垂直切片拆解]
B --> B4[依赖关系拆解]
```
## Task协作模式
```mermaid
mindmap
root((Task协作))
前后端协作
API优先模式
Mock数据并行
接口联调集成
测试驱动协作
TDD红绿重构
持续集成验证
自动化部署
跨技能协作
专业分工模式
功能团队模式
全栈协调模式
进度跟踪
每日站会更新
看板状态管理
燃尽图监控
```
</process>
<guideline>
### Task拆解策略
#### 1. 技能领域拆解法
```markdown
Story → 按技能分工：
- 前端Tasks: UI组件、交互逻辑、状态管理
- 后端Tasks: API接口、业务逻辑、数据处理
- 测试Tasks: 单元测试、集成测试、E2E测试
- DevOps Tasks: 部署配置、监控告警、文档更新
```
#### 2. 依赖关系分析
| 依赖类型 | 处理策略 | 解耦方法 |
|----------|---------|---------|
| 顺序依赖 | 确定关键路径 | 识别最小可行产品 |
| 并行依赖 | 接口Mock解耦 | Contract Testing |
| 阻塞依赖 | 重新调整边界 | Feature Flag控制 |
| 技术依赖 | 垂直切片策略 | 端到端最小功能 |
#### 3. Task大小控制
```mermaid
flowchart LR
A[Task识别] --> B{工作量评估}
B -->|< 1h| C[合并Task]
B -->|1-16h| D[标准Task]
B -->|> 16h| E[拆分Task]
C --> F[重新组合边界]
D --> G[Task就绪]
E --> H[进一步细分]
F --> B
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小时]
- 优先级: [P0-P3]
**验收标准**:
- [ ] 功能完整实现
- [ ] 代码质量达标
- [ ] 测试覆盖充分
- [ ] 文档更新完成
**依赖关系**:
- 前置Task: [必须先完成的任务]
- 阻塞Task: [被此任务阻塞的任务]
- 相关资源: [设计稿、API文档等]
**风险评估**:
- 技术风险: [新技术、复杂度]
- 时间风险: [依赖等待、资源冲突]
- 质量风险: [测试覆盖、代码审查]
```
### 跟踪与管理
#### 看板状态流转
```mermaid
stateDiagram-v2
[*] --> 待办
待办 --> 进行中: 开始工作
进行中 --> 代码审查: 开发完成
代码审查 --> 测试中: 审查通过
代码审查 --> 进行中: 需要修改
测试中 --> 已完成: 测试通过
测试中 --> 进行中: 发现问题
已完成 --> [*]
```
#### 每日站会汇报格式
```markdown
**昨天完成**:
- Task T-001: 树形组件基础结构 ✅
**今天计划**:
- Task T-002: 实现点击导航功能
**遇到阻塞**:
- 等待API接口联调
**需要帮助**:
- UX交互细节确认
```
### 估算方法
#### 历史数据参考标准
| Task类型 | 简单(2-4h) | 标准(4-8h) | 复杂(8-16h) |
|----------|------------|------------|-------------|
| 前端组件 | 简单UI组件 | 复杂交互组件 | 大型页面开发 |
| 后端API | 简单CRUD | 复杂业务逻辑 | 系统集成 |
| 数据库 | 表结构调整 | 查询优化 | 数据迁移 |
| 测试 | 单元测试 | 集成测试 | E2E自动化 |
#### 三点估算法
```
估算时间 = (最乐观 + 4×最可能 + 最悲观) / 6
示例: API开发任务
- 最乐观: 4小时
- 最可能: 8小时
- 最悲观: 16小时
- 估算结果: 8.7小时
```
</guideline>
<rule>
1. **Task大小强制要求**
- 单个Task工作量1-16小时
- 超过16小时必须拆分
- 少于1小时考虑合并
- 可在1-2天内完成
2. **Task定义强制要求**
- 必须有明确负责人
- 必须有具体验收标准
- 必须有清晰任务描述
- 必须评估技术风险
- **必须关联到对应Story**（除非是独立维护任务）
3. **Task-Story关联强制要求**
- 每个开发Task必须关联到具体Story
- 在项目管理工具中正确设置story_id字段
- Task验收标准必须支撑Story验收标准
- Task完成状态必须反映Story进度
- 独立Task（如环境维护、技术债务）可例外
4. **依赖管理强制要求**
- 识别所有前置依赖
- 标明阻塞影响关系
- 提供解耦替代方案
- 建立风险预警机制
5. **进度跟踪强制要求**
- 每日更新Task状态
- 及时反馈阻塞问题
- 记录实际工时偏差
- 定期回顾改进估算
</rule>
<constraint>
1. **团队技能约束**
- 专业技能分工限制
- 学习曲线时间成本
- 人员可用时间限制
- 关键人员依赖风险
2. **技术环境约束**
- 开发环境资源限制
- 第三方服务依赖
- 网络和硬件限制
- 工具和平台限制
3. **时间盒约束**
- Sprint时间限制
- 里程碑交付要求
- 发布窗口限制
- 客户期望时间
4. **质量约束**
- 代码覆盖率要求
- 性能指标要求
- 安全合规要求
- 用户体验标准
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 拆解粒度 | 1-16h工作量精准控制 | 基本符合大小要求 | 过大过小影响执行 |
| 任务定义 | 描述清晰标准具体 | 基本明确可执行 | 定义模糊难理解 |
| Story关联性 | 所有Task正确关联Story | 大部分Task已关联 | 关联缺失或错误 |
| 依赖管理 | 依赖识别完整有预案 | 主要依赖已识别 | 依赖遗漏频繁阻塞 |
| 责任分工 | 责任明确负载均衡 | 基本分工合理 | 分工不明或负载失衡 |
| 估算准确性 | 估算偏差<20% | 估算偏差<50% | 估算偏差>50% |
| 跟踪及时性 | 实时状态更新 | 每日更新状态 | 状态更新滞后 |
| 协作效率 | 协作顺畅无等待 | 基本协作顺利 | 频繁等待阻塞 |
| 交付质量 | 一次性通过验收 | 少量修改后通过 | 多次返工修改 |
</criteria>
</execution>

214
prompt/domain/scrum/execution/testcase-best-practice.execution.md Normal file
View File

@ -0,0 +1,214 @@
<execution domain="quality-assurance">
# TestCase设计核心理念
## ✅ TestCase = 验证问题解决得对不对
```markdown
TestCase的本质：验证问题解决方案的正确性
核心思考：这个问题真的被正确解决了吗？
问题导向框架：
📋 提问题层: Epic → Feature → Story (需求定义)
🛠️ 解决问题层: Task (技术实现)
✅ 验证层: TestCase (质量保证) ← 我们在这里
🎯 价值确认层: Milestone (交付确认)
```
**TestCase的职责边界**：
- ✅ 验证Story的验收标准是否达成
- ✅ 确保Task的实现符合预期
- ✅ 保证用户问题得到正确解决
- ✅ 防止新问题的引入（回归测试）
- ❌ 不重新定义需求或实现方案
- ❌ 不改变Story的验收标准
<process>
# 测试用例设计流程
```mermaid
flowchart TD
A[Story验收标准] --> B[确定测试层级]
B --> C[设计测试用例]
C --> D[准备测试数据]
D --> E[执行测试验证]
E --> F{测试结果}
F -->|通过| G[Story验收]
F -->|失败| H[缺陷修复]
H --> E
B --> B1[验收测试]
B --> B2[集成测试]
B --> B3[单元测试]
```
## 测试金字塔分层
```mermaid
graph TD
A[手工探索测试 1%] --> B[UI自动化测试 9%]
B --> C[集成测试 20%]
C --> D[单元测试 70%]
style D fill:#90EE90
style C fill:#FFE4B5
style B fill:#FFA07A
style A fill:#FFB6C1
```
</process>
<guideline>
### 测试用例设计方法
#### 1. 基于验收标准设计
```
验收标准 → 测试用例转换规则：
Given [前置条件] → 测试前置条件
When [用户操作] → 测试执行步骤
Then [预期结果] → 测试预期结果
```
#### 2. 等价类划分策略
| 等价类类型 | 设计策略 | 示例场景 |
|----------|---------|---------|
| 有效等价类 | 正常业务流程 | 标准输入数据 |
| 无效等价类 | 异常处理验证 | 空值、超长、特殊字符 |
| 边界等价类 | 临界值测试 | 最大值±1、最小值±1 |
#### 3. 场景覆盖矩阵
```mermaid
mindmap
root((测试覆盖))
功能覆盖
正常流程
异常流程
边界条件
用户覆盖
主要角色
次要角色
系统角色
环境覆盖
不同浏览器
不同设备
不同网络
数据覆盖
标准数据
边界数据
异常数据
```
### 测试用例标准模板
```markdown
## TC-{StoryID}-{序号}: {测试目标}
**前置条件**:
- 环境状态
- 测试数据
- 用户权限
**执行步骤**:
1. [操作步骤] → [预期结果]
2. [操作步骤] → [预期结果]
**验证点**:
- [ ] 功能验证
- [ ] 界面验证
- [ ] 性能验证
- [ ] 异常处理
**后置清理**: 清理测试数据
```
### 自动化测试策略
#### 自动化优先级排序
| 优先级 | 测试类型 | 自动化建议 | 维护成本 |
|--------|---------|----------|---------|
| 高 | 回归测试 | 必须自动化 | 低 |
| 高 | API接口测试 | 必须自动化 | 低 |
| 中 | 核心用户流程 | 推荐自动化 | 中 |
| 低 | UI细节测试 | 手工测试 | 高 |
| 低 | 探索性测试 | 手工测试 | - |
#### 自动化工具选型
```mermaid
flowchart LR
A[测试需求] --> B{测试层级}
B -->|单元测试| C[Jest/JUnit/PyTest]
B -->|API测试| D[Postman/RestAssured/Cypress]
B -->|E2E测试| E[Cypress/Playwright/Selenium]
B -->|性能测试| F[JMeter/K6/Artillery]
```
</guideline>
<rule>
1. **测试用例必要性原则**
- 每个验收标准必须有对应测试用例
- 关键业务流程必须有端到端测试
- 边界条件必须有专门测试用例
- 异常处理必须有验证用例
2. **测试分层强制要求**
- 单元测试覆盖率 > 80%
- 集成测试覆盖关键API
- UI测试仅覆盖核心用户流程
- 手工测试聚焦探索和边界场景
3. **自动化测试规范**
- 回归测试必须100%自动化
- 自动化用例必须稳定可重复
- 执行时间控制在合理范围
- 失败时提供清晰错误信息
4. **测试数据管理规范**
- 使用独立测试数据集
- 实现自动化数据准备和清理
- 避免测试用例间数据污染
- 敏感数据必须脱敏处理
</rule>
<constraint>
1. **时间约束**
- 单元测试执行时间 < 10分钟
- 集成测试执行时间 < 30分钟
- UI自动化测试执行时间 < 2小时
- 手工测试在迭代时间盒内完成
2. **资源约束**
- 测试环境资源有限
- 自动化维护人力约束
- 测试工具许可证成本
- 测试数据存储空间限制
3. **技能约束**
- 团队自动化技能水平
- 测试工具熟练程度
- 编程能力限制
- 领域知识深度
4. **技术约束**
- 被测系统架构限制
- 第三方服务依赖
- 网络环境稳定性
- 浏览器兼容性要求
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 覆盖完整性 | 覆盖所有验收标准和边界条件 | 覆盖主要功能场景 | 覆盖不足缺少关键场景 |
| 用例设计质量 | 步骤清晰预期明确可重复 | 基本可执行有明确结果 | 步骤模糊或结果不明确 |
| 自动化比例 | 关键流程90%+自动化 | 回归测试基本自动化 | 自动化比例过低 |
| 执行效率 | 测试套件执行快速稳定 | 基本满足时间要求 | 执行缓慢或不稳定 |
| 缺陷发现能力 | 能及时发现各类缺陷 | 能发现主要功能缺陷 | 缺陷遗漏率高 |
| 维护成本 | 测试维护成本低更新及时 | 维护成本可接受 | 维护成本过高 |
| 数据管理 | 数据独立清理完整 | 基本数据管理 | 数据污染或泄露 |
| 报告质量 | 测试结果清晰可追溯 | 基本测试报告 | 结果不明确难追溯 |
</criteria>
</execution>

141
prompt/domain/scrum/execution/workitem-title-best-practice.execution.md Normal file
View File

@ -0,0 +1,141 @@
<execution domain="product-management">
<process>
# 工作项标题命名流程
```mermaid
flowchart TD
A[确定工作项层级] --> B[选择命名模式]
B --> C[应用命名规则]
C --> D[检查命名质量]
D --> E{质量检查}
E -->|通过| F[标题确认]
E -->|不通过| G[优化调整]
G --> C
A --> A1[Epic层级]
A --> A2[Feature层级]
A --> A3[Story层级]
A --> A4[Task层级]
```
## 分层命名体系
```mermaid
mindmap
root((工作项命名))
Epic命名
"Epic X: 主题名称"
功能域描述
价值主题表达
Feature命名
"Feature X.Y: 功能模块"
能力描述
模块边界
Story命名
"Story X.Y.Z: 用户能够..."
用户视角
具体行为
Task命名
"Task X.Y.Z.N: 实现..."
技术视角
具体实现
```
</process>
<guideline>
### 层级编号规则
- **Epic层级**: `Epic X: 主题名称`
- X为数字序号（1,2,3...）
- 主题名称简洁概括核心价值域
- 示例：`Epic 1: 核心工作区`、`Epic 2: 文件系统`
- **Feature层级**: `Feature X.Y: 功能模块名`
- X为所属Epic编号，Y为Feature序号
- 功能模块名描述具体能力边界
- 示例：`Feature 1.1: 全局结构`、`Feature 1.2: 内容预览区`
- **Story层级**: `Story X.Y.Z: 角色+能够+动作+对象`
- X.Y为所属Feature编号，Z为Story序号
- 严格按照用户故事格式："XXX能够..."
- 示例：`Story 1.1.1: 教师能够查看和管理试题结构`
- **Task层级**: `Task X.Y.Z.N: 实现/开发/设计+具体内容`
- X.Y.Z为所属Story编号，N为Task序号
- 技术实现视角，动词+具体任务
- 示例：`Task 1.1.1.1: 实现试题结构树组件`
### 命名语言规范
- **动词选择精准**：避免模糊动词，使用具体行为词
- ✅ 查看、编辑、创建、删除、导出
- ❌ 处理、操作、管理（过于宽泛）
- **对象描述具体**：明确操作对象和范围
- ✅ 试题结构、用户权限、数据报表
- ❌ 内容、信息、数据（过于抽象）
- **角色明确标识**：Story必须明确用户角色
- ✅ 教师能够、学生能够、管理员能够
- ❌ 用户能够（角色不明确）
### 特殊情况处理
- **跨Feature Story**: 使用主Feature编号，标注依赖
- **技术性Story**: 标注"系统能够"而非用户角色
- **Bug修复Task**: 使用"修复+具体问题"格式
- **重构Task**: 使用"重构+模块名+原因"格式
</guideline>
<rule>
1. **编号连续性强制**
- 同层级编号必须连续，不允许跳号
- 删除工作项时编号不重用，保持历史追溯
- 新增工作项使用下一个可用编号
2. **命名格式强制**
- Epic/Feature/Story/Task前缀必须使用
- 编号格式严格按照X.Y.Z.N模式
- Story必须包含"能够"关键词
- Task必须包含动作动词
3. **长度限制规则**
- Epic标题不超过20个字符
- Feature标题不超过30个字符
- Story标题不超过50个字符
- Task标题不超过40个字符
4. **语义一致性规则**
- 同Epic下Feature语义边界清晰不重叠
- 同Feature下Story粒度一致
- 标题与工作项实际内容保持一致
</rule>
<constraint>
1. **工具平台限制**
- 不同项目管理工具对标题长度有限制
- 某些平台不支持特殊字符或表情符号
- 编号格式需兼容排序和筛选功能
2. **团队认知限制**
- 新成员对编号体系的学习成本
- 跨团队协作时的理解一致性
- 国际化团队的语言统一性
3. **历史遗留约束**
- 已有项目的编号体系兼容性
- 迁移过程中的重复编号处理
- 历史数据的追溯完整性
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 编号规范性 | 完全符合X.Y.Z.N格式，无跳号 | 基本符合格式，偶有不规范 | 编号混乱或格式错误 |
| 语义清晰度 | 标题一目了然，无歧义 | 标题基本清楚，少量模糊 | 标题含糊或表达不准确 |
| 层级一致性 | 同层级粒度和表达方式统一 | 基本一致，个别项例外 | 层级混乱或不一致 |
| 用户视角 | Story严格按用户故事格式 | Story基本符合用户视角 | Story缺少用户视角 |
| 可搜索性 | 关键词明确，便于搜索筛选 | 关键词基本明确 | 关键词缺失或不明确 |
| 长度适当性 | 符合长度限制且信息充分 | 长度可控，信息基本充分 | 过长或过短影响理解 |
</criteria>
</execution>