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