217 lines
8.1 KiB
Markdown
217 lines
8.1 KiB
Markdown
<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> |