73 lines
6.3 KiB
Markdown
73 lines
6.3 KiB
Markdown
<!-- 由 BMAD™ Core 驱动 -->
|
||
|
||
# 纠正航向任务
|
||
|
||
## 目的
|
||
|
||
- 使用 `{root}/checklists/change-checklist` 指导对变更触发器的结构化响应。
|
||
- 在清单结构的指导下，分析变更对史诗、项目工件和MVP的影响。
|
||
- 按照清单的提示，探索潜在的解决方案（例如，调整范围、回滚元素、重新界定功能范围）。
|
||
- 根据分析，为任何受影响的项目工件（例如，史诗、用户故事、PRD部分、架构文档部分）起草具体的、可操作的拟议更新。
|
||
- 生成一份整合的“冲刺变更提案”文档，其中包含影响分析和清晰起草的拟议编辑，供用户审查和批准。
|
||
- 如果变更的性质需要其他核心代理（如PM或架构师）进行根本性的重新规划，确保有清晰的交接路径。
|
||
|
||
## 说明
|
||
|
||
### 1. 初始设置和模式选择
|
||
|
||
- **确认任务和输入：**
|
||
- 向用户确认正在启动“纠正航向任务”（变更导航与集成）。
|
||
- 验证变更触发器，并确保您已获得用户对问题及其感知影响的初步解释。
|
||
- 确认可以访问所有相关的项目工件（例如，PRD、史诗/故事、架构文档、UI/UX规范），以及至关重要的`{root}/checklists/change-checklist`。
|
||
- **建立交互模式：**
|
||
- 询问用户他们对此任务的首选交互模式：
|
||
- **“增量模式（默认和推荐）：** 我们是否应逐节审阅变更清单，讨论发现并协作起草每个相关部分的拟议变更，然后再进行下一部分？这允许进行详细的、逐步的完善。”
|
||
- **“YOLO模式（批量处理）：** 或者，您是否希望我根据清单进行更批量的分析，然后提交一份整合的发现和拟议变更集，以进行更广泛的审查？这对于初步评估可能更快，但可能需要对合并的提案进行更广泛的审查。”
|
||
- 一旦用户选择，确认所选模式，然后通知用户：“我们现在将使用变更清单来分析变更并起草拟议的更新。我将根据我们选择的交互模式引导您完成清单项目。”
|
||
|
||
### 2. 执行清单分析（根据交互模式，迭代或批量进行）
|
||
|
||
- 系统地完成变更清单的第1-4节（通常涵盖变更背景、史诗/故事影响分析、工件冲突解决和路径评估/建议）。
|
||
- 对于每个清单项目或逻辑项目组（取决于交互模式）：
|
||
- 向用户呈现清单中的相关提示或考虑因素。
|
||
- 请求必要的信息，并积极分析相关的项目工件（PRD、史诗、架构文档、故事历史等）以评估影响。
|
||
- 与用户讨论您对每个项目的发现。
|
||
- 记录每个清单项目的状态（例如，`[x] 已处理`，`[N/A]`，`[!] 需要进一步行动`）以及任何相关的说明或决定。
|
||
- 按照清单第4节的提示，协作商定“推荐的前进路径”。
|
||
|
||
### 3. 起草拟议的变更（迭代或批量）
|
||
|
||
- 基于完成的清单分析（第1-4节）和商定的“推荐的前进路径”（不包括需要立即交接给PM/架构师进行根本性重新规划的场景）：
|
||
- 确定需要更新的具体项目工件（例如，特定的史诗、用户故事、PRD部分、架构文档组件、图表）。
|
||
- **为每个已识别的工件直接且明确地起草拟议的变更。** 示例包括：
|
||
- 修改用户故事文本、验收标准或优先级。
|
||
- 在史诗中添加、删除、重新排序或拆分用户故事。
|
||
- 提出修改后的架构图片段（例如，提供更新的Mermaid图块或对现有图表的清晰文字描述）。
|
||
- 更新技术列表、配置细节或PRD或架构文档中的特定部分。
|
||
- 如果需要，起草新的、小的支持性工件（例如，针对特定决策的简要附录）。
|
||
- 如果在“增量模式”下，在起草每个工件或相关工件小组的拟议编辑时，与用户讨论和完善它们。
|
||
- 如果在“YOLO模式”下，编译所有起草的编辑，以便在下一步中呈现。
|
||
|
||
### 4. 生成包含编辑的“冲刺变更提案”
|
||
|
||
- 将完整的变更清单分析（涵盖第1-4节的发现）和所有商定的拟议编辑（来自说明3）综合成一份名为“冲刺变更提案”的单一文档。此提案应与变更清单第5节建议的结构保持一致。
|
||
- 提案必须清晰地呈现：
|
||
- **分析摘要：** 对原始问题、其分析的影响（对史诗、工件、MVP范围）以及所选前进路径的理由的简明概述。
|
||
- **具体的拟议编辑：** 对于每个受影响的工件，清晰地显示或描述确切的变更（例如，“将故事X.Y从：[旧文本] 更改为：[新文本]”，“向故事A.B添加新的验收标准：[新AC]”，“按如下方式更新架构文档的第3.2节：[新的/修改的文本或图表描述]”）。
|
||
- 将“冲刺变更提案”的完整草稿呈现给用户进行最终审查和反馈。采纳用户要求的任何最终调整。
|
||
|
||
### 5. 最终确定并确定下一步
|
||
|
||
- 获得用户对“冲刺变更提案”的明确批准，包括其中记录的所有具体编辑。
|
||
- 向用户提供最终确定的“冲刺变更提案”文档。
|
||
- **根据批准的变更的性质：**
|
||
- **如果批准的编辑足以解决变更，并且可以直接实施或由PO/SM组织：** 说明“纠正航向任务”在分析和变更提案方面已完成，用户现在可以继续实施或记录这些变更（例如，更新实际的项目文档、待办事项）。如果合适，建议交接给PO/SM代理进行待办事项组织。
|
||
- **如果分析和拟议路径（根据清单第4节和可能第6节）表明变更需要更根本的重新规划（例如，重大的范围变更、主要的架构重做）：** 清晰地陈述此结论。建议用户下一步是让主要的PM或架构师代理参与进来，使用“冲刺变更提案”作为该更深层次重新规划工作的关键输入和背景。
|
||
|
||
## 输出交付物
|
||
|
||
- **主要：** 一份“冲刺变更提案”文档（markdown格式）。该文档将包含：
|
||
- 变更清单分析的摘要（问题、影响、所选路径的理由）。
|
||
- 为所有受影响的项目工件起草的具体的、清晰的拟议编辑。
|
||
- **隐含：** 一份带注释的变更清单（或其完成记录），反映了在此过程中进行的讨论、发现和决定。
|