From 3338b7c21faf30ffaf44550201b319cd33dfbd15 Mon Sep 17 00:00:00 2001 From: sean Date: Fri, 30 May 2025 19:47:39 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E5=A4=9A=E4=B8=AA=E6=89=A7?= =?UTF-8?q?=E8=A1=8C=E6=9C=80=E4=BD=B3=E5=AE=9E=E8=B7=B5=E6=96=87=E6=A1=A3?= =?UTF-8?q?=EF=BC=8C=E5=A2=9E=E5=8A=A0Epic=E3=80=81Feature=E3=80=81Story?= =?UTF-8?q?=E3=80=81Task=E3=80=81TestCase=E5=92=8CMilestone=E7=9A=84?= =?UTF-8?q?=E6=A0=B8=E5=BF=83=E7=90=86=E5=BF=B5=E3=80=81=E8=81=8C=E8=B4=A3?= =?UTF-8?q?=E8=BE=B9=E7=95=8C=E3=80=81=E5=B8=B8=E8=A7=81=E9=99=B7=E9=98=B1?= =?UTF-8?q?=E5=8F=8A=E8=87=AA=E6=A3=80=E6=B8=85=E5=8D=95=EF=BC=8C=E5=BC=BA?= =?UTF-8?q?=E8=B0=83=E9=97=AE=E9=A2=98=E5=AF=BC=E5=90=91=E7=9A=84=E9=9C=80?= =?UTF-8?q?=E6=B1=82=E7=AE=A1=E7=90=86=E5=92=8C=E9=9A=9C=E7=A2=8D=E8=AF=86?= =?UTF-8?q?=E5=88=AB=E6=96=B9=E6=B3=95=EF=BC=8C=E6=8F=90=E5=8D=87=E6=96=87?= =?UTF-8?q?=E6=A1=A3=E7=9A=84=E6=8C=87=E5=AF=BC=E6=80=A7=E5=92=8C=E5=AE=9E?= =?UTF-8?q?=E7=94=A8=E6=80=A7=E3=80=82=E5=90=8C=E6=97=B6=EF=BC=8C=E6=9B=B4?= =?UTF-8?q?=E6=96=B0=E4=BA=A7=E5=93=81=E8=B4=9F=E8=B4=A3=E4=BA=BA=E8=A7=92?= =?UTF-8?q?=E8=89=B2=E6=96=87=E6=A1=A3=EF=BC=8C=E5=A2=9E=E5=8A=A0Scrum?= =?UTF-8?q?=E6=9C=80=E4=BD=B3=E5=AE=9E=E8=B7=B5=E9=93=BE=E6=8E=A5=EF=BC=8C?= =?UTF-8?q?=E7=A1=AE=E4=BF=9D=E6=96=87=E6=A1=A3=E5=86=85=E5=AE=B9=E7=9A=84?= =?UTF-8?q?=E5=AE=8C=E6=95=B4=E6=80=A7=E5=92=8C=E5=87=86=E7=A1=AE=E6=80=A7?= =?UTF-8?q?=E3=80=82?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../execution/epic-best-practice.execution.md | 83 +++- .../feature-best-practice.execution.md | 248 +++++++---- .../milestone-best-practice.execution.md | 24 ++ .../scrum-best-practice.execution.md | 217 ++++++++++ .../story-best-practice.execution.md | 388 +++++++++++++----- .../execution/task-best-practice.execution.md | 78 +++- .../testcase-best-practice.execution.md | 24 ++ domain/scrum/role/product-owner.role.md | 10 +- resource/execution.resource.md | 1 + 9 files changed, 883 insertions(+), 190 deletions(-) create mode 100644 domain/scrum/execution/scrum-best-practice.execution.md diff --git a/domain/scrum/execution/epic-best-practice.execution.md b/domain/scrum/execution/epic-best-practice.execution.md index d456c89..9f7a97b 100644 --- a/domain/scrum/execution/epic-best-practice.execution.md +++ b/domain/scrum/execution/epic-best-practice.execution.md @@ -1,4 +1,49 @@ + + # 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能理解问题，而非实现方式？ + # Epic设计流程 @@ -36,16 +81,46 @@ 技术债还清 开发效率 ``` + + ## 📊 价值量化模板 + + ```markdown + ### 用户价值量化 + - 当前痛点: [具体描述用户遇到的问题] + - 影响用户: [数量/类型，如"80%的新用户"、"所有开发者"] + - 痛点成本: [时间/金钱损失，如"每次配置10分钟"、"60%放弃率"] + - 期望改善: [具体目标，如"降低到30秒"、"提升到95%成功率"] + + ### 商业价值量化 + - 市场机会: [市场规模/竞争优势，如"AI开发者工具市场增长30%"] + - 收入影响: [具体数字，如"预期提升用户转化20%"] + - 成本节约: [具体节约，如"减少支持成本50%"] + - 风险缓解: [避免的损失，如"防止用户流失到竞品"] + + ### 技术价值量化 + - 效率提升: [具体指标，如"开发效率提升3倍"] + - 维护成本: [降低程度，如"技术债务减少40%"] + - 扩展能力: [支撑能力，如"支持10倍用户增长"] + ``` ### Epic定义建议 - - **标题命名**: 使用"动词+对象"格式，如"构建用户工作区" + - **标题命名**: 使用"问题+影响"格式，如"用户角色获取流程复杂度过高"，避免"构建XX"、"实现XX"等解决方案用词 - **价值先行**: 每个Epic必须先定义用户价值，再描述功能 - **边界明确**: 用包含/不包含列表明确Epic范围 - **分阶段交付**: 大Epic按MVP→增强→完善分阶段 + **命名对比示例**： + ```markdown + ❌ 解决方案导向: "构建NPM包管理系统" + ✅ 问题导向: "AI助手能力获取复杂度阻碍用户采用" + + ❌ 功能导向: "开发角色快速配置功能" + ✅ 价值导向: "新用户角色配置门槛影响产品推广" + ``` + ### 大小控制指南 | Epic类型 | 建议大小 | 完成周期 | Feature数量 | @@ -107,5 +182,11 @@ | 验收标准 | 标准具体可测，覆盖功能质量业务 | 标准基本明确可测试 | 标准模糊或不可测 | | 依赖管理 | 依赖最小化，风险已识别应对 | 依赖已识别，风险可控 | 依赖复杂或风险未评估 | | INVEST符合度 | 完全符合INVEST原则 | 基本符合，个别项有改进空间 | 不符合多个INVEST原则 | + + **快速检查要点**： + 📝 **问题导向**: 标题描述问题而非解决方案，避免"构建"、"开发"等技术词汇 + 💰 **价值量化**: 用户价值和商业价值必须量化，有清晰成功指标 + 🎯 **范围边界**: 包含/不包含列表清晰，单一问题域，6个迭代内完成 + 📊 **可执行性**: 验收标准具体可测，可拆分为独立Feature，风险已识别 \ No newline at end of file diff --git a/domain/scrum/execution/feature-best-practice.execution.md b/domain/scrum/execution/feature-best-practice.execution.md index 1d10aed..7eb46ae 100644 --- a/domain/scrum/execution/feature-best-practice.execution.md +++ b/domain/scrum/execution/feature-best-practice.execution.md @@ -1,138 +1,216 @@ + + # Feature设计核心理念 + + ## 🤔 Feature = 功能域问题发现 + + ```markdown + Feature的本质：发现用户在特定功能域遇到的问题 + 核心思考：用户在这个功能域被什么困难阻碍了？ + + 问题导向框架： + 📋 提问题层: Epic → Feature → Story (需求定义) + 🛠️ 解决问题层: Task (技术实现) + ✅ 验证层: TestCase (质量保证) + 🎯 价值确认层: Milestone (交付确认) + ``` + + **Feature的职责边界**： + - ✅ 发现用户在功能域的具体痛点和障碍 + - ✅ 识别功能缺失导致的用户任务中断 + - ✅ 定义用户在特定场景下的困难体验 + - ❌ 不设计具体功能模块实现方案 + - ❌ 不定义技术架构和接口细节 + - ❌ 不描述"用户需要什么能力" + + ## ⚠️ 常见陷阱与避免方法 + + ```markdown + 陷阱1: 写成功能设计书 + 错误表述: "用户角色管理功能模块，包含角色选择、配置生成、状态展示" + 正确表述: "用户无法快速识别和切换可用的AI角色，配置过程繁琐易错" + + 陷阱2: 定义解决方案而非问题 + 错误表述: "提供命令行工具让用户一键生成角色配置文件" + 正确表述: "当前角色配置需要手动操作多个步骤，新用户配置失败率高" + + 陷阱3: 关注能力需求而非缺失痛点 + 错误表述: "用户需要可视化的记忆状态监控能力" + 正确表述: "用户对记忆系统运行状态缺乏感知，无法确认功能是否正常" + + 陷阱4: 混合问题与功能清单 + 错误表述: "角色初始化复杂，需要包含别名解析、文件生成、状态反馈功能" + 正确表述: "角色初始化过程用户不知道进度，经常不确定是否成功完成" + ``` + + **问题导向自检清单**： + - [ ] Feature描述中是否包含"功能"、"模块"、"提供"等解决方案词汇？ + - [ ] 是否先描述用户遇到的困难，再描述期望改善？ + - [ ] 能否用"什么问题阻碍了用户"而非"用户需要什么"来概括Feature？ + - [ ] 开发团队看到Feature能理解要解决的痛点，而非要开发的功能？ + # 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次才成功"] + - 当前缺失: [什么能力的缺失导致了这个问题] + + ### 功能缺失分析 + - 缺失能力: [具体缺少什么功能支持] + - 导致后果: [缺失导致的用户困难] + - 替代方案: [用户当前如何绕过这个问题] + - 绕过成本: [替代方案的额外成本] + + ### 改善期望 + - 期望体验: [解决问题后用户应该有什么体验] + - 成功指标: [如何衡量问题得到解决] + - 优先级: [相对其他问题的重要程度] ``` - ### 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[状态不明确] ``` 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个迭代需要拆分 1. **技术架构约束** - - Feature边界受现有架构模块限制 - - 微服务边界影响Feature划分 - - 数据模型设计影响功能范围 + - 问题域边界受现有架构模块限制 + - 微服务边界影响问题解决方案 + - 数据模型设计影响问题解决范围 2. **团队能力约束** - - 并行开发Feature数量有限 - - 团队技能影响Feature复杂度 - - 跨团队Feature需要额外协调成本 + - 并行解决问题数量有限 + - 团队技能影响问题解决复杂度 + - 跨团队问题需要额外协调成本 3. **用户体验约束** - - UI一致性要求影响Feature边界 - - 用户流程完整性不可打断 - - 渐进式发布对Feature颗粒度的要求 + - 用户旅程完整性不可打断 + - 渐进式改善对问题解决颗粒度的要求 + - 问题优先级受用户影响程度限制 4. **项目约束** - - 迭代时间盒限制Feature大小 - - 测试资源影响Feature验收 - - 发布节奏影响Feature优先级 + - 迭代时间盒限制问题解决范围 + - 测试资源影响问题验证 + - 发布节奏影响问题解决优先级 | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 | |---------|---------|---------|-----------| - | 功能完整性 | 用户能独立完成完整任务 | 基本功能完整，少量依赖 | 功能不完整或过度依赖 | - | 边界清晰度 | 技术和功能边界都明确 | 边界基本清晰 | 边界模糊或重叠 | - | 大小合理性 | 符合20-60SP范围，Story数量适中 | 大小基本合理 | 过大过小或拆分不当 | - | 用户价值 | 独立交付价值，用户可感知 | 有一定价值 | 价值不明确或用户无感知 | - | 技术可行性 | 技术实现边界清晰可行 | 基本可行 | 技术难度过高或边界不清 | - | Story拆解质量 | Story覆盖全面，粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 | - | 验收标准 | 标准具体可测，覆盖全面 | 标准基本明确 | 标准模糊或不可测 | + | 问题清晰度 | 用户痛点具体可观察，困难描述准确 | 问题基本清晰可理解 | 问题模糊或偏向解决方案 | + | 边界合理性 | 问题域边界清晰，困难点内聚相关 | 边界基本清晰 | 边界模糊或问题分散 | + | 用户视角 | 完全从用户困难角度描述问题 | 基本体现用户视角 | 偏向系统或技术视角 | + | 影响量化 | 问题影响范围和程度量化清晰 | 影响基本明确 | 影响不明确或无量化 | + | 可解决性 | 问题有明确解决标准和验证方式 | 基本可解决验证 | 问题过于抽象或无法验证 | + | Story拆解质量 | 问题拆解全面，困难点粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 | + | 问题导向性 | 避免解决方案描述，纯问题导向 | 基本问题导向 | 混合解决方案或功能描述 | + + **快速检查要点**： + 📝 **问题导向**: 描述用户困难而非功能需求，避免"需要"、"提供"、"实现"等词汇 + 🎯 **用户视角**: 从用户遇到的具体障碍和痛点角度定义问题 + 📊 **困难量化**: 用户痛点影响范围和程度必须量化，有明确解决标准 + 🔍 **边界清晰**: 问题域边界明确，困难点内聚，可独立解决和验证 \ No newline at end of file diff --git a/domain/scrum/execution/milestone-best-practice.execution.md b/domain/scrum/execution/milestone-best-practice.execution.md index 89829c4..f04d546 100644 --- a/domain/scrum/execution/milestone-best-practice.execution.md +++ b/domain/scrum/execution/milestone-best-practice.execution.md @@ -1,4 +1,28 @@ + + # Milestone设计核心理念 + + ## 🎯 Milestone = 价值交付确认节点 + + ```markdown + Milestone的本质：确认阶段性问题解决和价值交付 + 核心思考：这个阶段的问题解决了吗？价值交付了吗？ + + 问题导向框架： + 📋 提问题层: Epic → Feature → Story (需求定义) + 🛠️ 解决问题层: Task (技术实现) + ✅ 验证层: TestCase (质量保证) + 🎯 价值确认层: Milestone (交付确认) ← 我们在这里 + ``` + + **Milestone的职责边界**： + - ✅ 确认用户价值的实际交付 + - ✅ 验证商业目标的达成状况 + - ✅ 标记问题解决的重要节点 + - ✅ 为后续问题解决提供决策依据 + - ❌ 不重新定义问题或解决方案 + - ❌ 不改变Epic/Feature/Story的目标 + # Milestone管理流程 diff --git a/domain/scrum/execution/scrum-best-practice.execution.md b/domain/scrum/execution/scrum-best-practice.execution.md new file mode 100644 index 0000000..d69f4ba --- /dev/null +++ b/domain/scrum/execution/scrum-best-practice.execution.md @@ -0,0 +1,217 @@ + + + # 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% | + + \ No newline at end of file diff --git a/domain/scrum/execution/story-best-practice.execution.md b/domain/scrum/execution/story-best-practice.execution.md index d931694..55db06e 100644 --- a/domain/scrum/execution/story-best-practice.execution.md +++ b/domain/scrum/execution/story-best-practice.execution.md @@ -1,162 +1,350 @@ + + # 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能理解要解决的具体障碍？ + # 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 + ### 具体障碍描述 + - 任务场景: [用户尝试完成什么具体任务] + - 遇到困难: [在哪个步骤遇到什么障碍] + - 困难表现: [障碍如何具体表现，如错误、延时、复杂] + - 当前处理: [用户如何绕过或处理这个障碍] + + ### 障碍影响分析 + - 影响频率: [多少比例的用户会遇到此障碍] + - 困难程度: [障碍对任务完成的阻碍程度] + - 时间成本: [障碍导致的额外时间损失] + - 错误风险: [障碍可能导致的错误概率] + + ### 解决期望 + - 理想体验: [障碍消除后用户应该有什么体验] + - 成功标准: [如何验证障碍得到解决] + - 性能指标: [时间、错误率等具体改善目标] ``` - ### 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[监控添加] ``` 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周必须拆分 + - 涉及多个用户角色的障碍需要拆分 + - 包含技术复杂性或不确定性需要拆分 - 1. **团队技能约束** - - Story复杂度受团队技能水平限制 - - 新技术学习成本影响估算准确性 - - 跨技能Story需要多人协作 + 1. **用户认知约束** + - 用户对系统理解程度影响障碍识别 + - 用户技能水平影响障碍严重程度 + - 用户使用习惯影响障碍感知 - 2. **技术债务约束** - - 现有代码质量影响新功能开发 - - 技术架构限制功能实现方式 - - 测试覆盖率影响Story验收 + 2. **技术实现约束** + - 现有架构限制障碍解决方案 + - 性能瓶颈影响体验改善程度 + - 兼容性要求限制改善范围 - 3. **业务约束** - - 业务规则复杂度影响Story大小 - - 合规要求增加开发复杂度 - - 用户体验一致性要求约束实现 + 3. **业务流程约束** + - 业务规则限制流程优化 + - 合规要求影响操作简化 + - 数据安全约束体验改善 - 4. **项目约束** - - 迭代时间盒限制Story数量 - - 测试资源限制验收能力 - - 发布窗口影响Story优先级 + 4. **项目资源约束** + - 迭代时间限制障碍解决数量 + - 测试资源影响改善验证 + - 人员技能影响障碍解决复杂度 | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 | |---------|---------|---------|-----------| | INVEST符合度 | 完全符合6个INVEST原则 | 基本符合，个别项可改进 | 不符合多个INVEST原则 | - | 格式规范性 | 严格按照标准格式，角色价值明确 | 基本符合格式要求 | 格式不规范或要素缺失 | - | 验收标准质量 | GWT格式完整，场景覆盖全面 | 基本明确可测 | 标准模糊或不可测试 | - | 用户价值 | 价值明确且用户强烈需要 | 有一定价值 | 价值不明确或技术导向 | - | 估算准确性 | 估算准确，风险可控 | 估算基本合理 | 估算偏差大或风险高 | - | 独立性 | 完全独立可单独开发交付 | 基本独立，少量依赖 | 严重依赖其他Story | - | 可测试性 | 验收标准具体可重复执行 | 基本可测试 | 难以验证或标准主观 | - | 大小合理性 | 1-2周完成，复杂度适中 | 大小基本合理 | 过大过小影响交付 | + | 障碍描述质量 | 障碍具体可观察，场景明确 | 基本清晰可理解 | 障碍模糊或偏向功能需求 | + | 格式规范性 | 严格按照障碍描述格式 | 基本符合格式要求 | 格式不规范或要素缺失 | + | 用户视角 | 完全从用户困难角度描述 | 基本体现用户视角 | 偏向系统或解决方案视角 | + | 影响量化 | 障碍影响具体可量化 | 影响基本明确 | 影响不明确或过于抽象 | + | 独立性 | 障碍独立可单独解决 | 基本独立，少量依赖 | 严重依赖其他Story | + | 可验证性 | 改善标准具体可重复执行 | 基本可测试验证 | 难以验证或标准主观 | + | 复杂度合理性 | 1-2周解决，复杂度适中 | 大小基本合理 | 过大过小影响解决效果 | + + **快速检查要点**： + 📝 **障碍导向**: 描述用户困难而非功能需求，避免"想要"、"需要"、"希望"等词汇 + 🎯 **任务具体**: 从用户执行具体任务的障碍角度定义问题 + 📊 **困难量化**: 障碍影响和后果必须具体可观察，有明确改善标准 + 🔍 **场景明确**: 任务场景具体，障碍描述准确，可独立解决和验证 \ No newline at end of file diff --git a/domain/scrum/execution/task-best-practice.execution.md b/domain/scrum/execution/task-best-practice.execution.md index 9ef5db0..7b6c8c7 100644 --- a/domain/scrum/execution/task-best-practice.execution.md +++ b/domain/scrum/execution/task-best-practice.execution.md @@ -1,4 +1,28 @@ + + # Task设计核心理念 + + ## 🛠️ Task = 解决问题的实现 + + ```markdown + Task的本质：解决具体技术实现问题 + 核心思考：如何具体实现这个功能？ + + 问题导向框架： + 📋 提问题层: Epic → Feature → Story (需求定义) + 🛠️ 解决问题层: Task (技术实现) ← 我们在这里 + ✅ 验证层: TestCase (质量保证) + 🎯 价值确认层: Milestone (交付确认) + ``` + + **Task的职责边界**： + - ✅ 解决具体技术实现问题 + - ✅ 定义技术方案和开发步骤 + - ✅ 分配技术资源和时间规划 + - ✅ **必须关联到对应Story**（明确解决哪个用户问题） + - ❌ 不重新定义用户需求 + - ❌ 不改变Story的验收标准 + # 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% | diff --git a/domain/scrum/execution/testcase-best-practice.execution.md b/domain/scrum/execution/testcase-best-practice.execution.md index 722da34..23c10de 100644 --- a/domain/scrum/execution/testcase-best-practice.execution.md +++ b/domain/scrum/execution/testcase-best-practice.execution.md @@ -1,4 +1,28 @@ + + # TestCase设计核心理念 + + ## ✅ TestCase = 验证问题解决得对不对 + + ```markdown + TestCase的本质：验证问题解决方案的正确性 + 核心思考：这个问题真的被正确解决了吗？ + + 问题导向框架： + 📋 提问题层: Epic → Feature → Story (需求定义) + 🛠️ 解决问题层: Task (技术实现) + ✅ 验证层: TestCase (质量保证) ← 我们在这里 + 🎯 价值确认层: Milestone (交付确认) + ``` + + **TestCase的职责边界**： + - ✅ 验证Story的验收标准是否达成 + - ✅ 确保Task的实现符合预期 + - ✅ 保证用户问题得到正确解决 + - ✅ 防止新问题的引入（回归测试） + - ❌ 不重新定义需求或实现方案 + - ❌ 不改变Story的验收标准 + # 测试用例设计流程 diff --git a/domain/scrum/role/product-owner.role.md b/domain/scrum/role/product-owner.role.md index bc35f09..451ba42 100644 --- a/domain/scrum/role/product-owner.role.md +++ b/domain/scrum/role/product-owner.role.md @@ -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: 能力确认 **只有通过以下三个确认，才能宣布角色就绪：** diff --git a/resource/execution.resource.md b/resource/execution.resource.md index 9ded46f..df503f0 100644 --- a/resource/execution.resource.md +++ b/resource/execution.resource.md @@ -32,5 +32,6 @@ | task-best-practice | @file://PromptX/domain/scrum/execution/task-best-practice.execution.md | | sprint-best-practice | @file://PromptX/domain/scrum/execution/sprint-best-practice.execution.md | | milestone-best-practice | @file://PromptX/domain/scrum/execution/milestone-best-practice.execution.md | + | scrum-best-practice | @file://PromptX/domain/scrum/execution/scrum-best-practice.execution.md | \ No newline at end of file