PromptX/domain/scrum/execution/scrum-best-practice.execution.md

# 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周)
- **障碍解决进展跟踪**: 每日同步障碍解决状况
- **创新方案探索**: 鼓励多种解决方案验证
- **用户反馈快速收集**: 持续验证解决方案有效性
- **价值交付确认**: 验证是否真正解决用户障碍

# 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职责重定义为"解决方案创新者"
- 所有角色必须以用户障碍解决为工作导向

# 实施约束条件

## 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辅助决策的工具环境
- 要求快速原型验证能力
- 必须具备用户反馈收集渠道
- 需要可视化障碍地图绘制工具

# 实施指导原则

## 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增强实施指南

### 智能化需求分析应用
- 用户访谈内容智能分析
- 障碍模式自动识别
- 相似场景关联推荐
- 潜在障碍预测提醒
- 多种解决方案生成
- 技术可行性快速评估

# 成功评估标准

## 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% |