<!-- 由 BMAD™ Core 驱动 -->

# 变更导航清单

**目的：** 在BMad工作流中识别出重大变更（转向、技术问题、需求缺失、故事失败）时，系统地引导选定的代理和用户进行分析和规划。

**说明：** 与用户一起审阅每个项目。标记 `[x]` 表示已完成/已确认，`[N/A]` 表示不适用，或为讨论点添加备注。

[[LLM: 初始化说明 - 变更导航

开发过程中的变更是不可避免的，但我们如何处理它们决定了项目的成败。

在继续之前，请理解：

1.  此清单适用于影响项目方向的重大变更。
2.  故事内的微小调整不需要此流程。
3.  目标是在适应新现实的同时，最大限度地减少工作浪费。
4.  用户认同至关重要 - 他们必须理解并批准变更。

所需背景：

-   触发问题的具体故事或问题。
-   当前项目状态（已完成的故事、当前史诗）。
-   访问PRD、架构和其他关键文档。
-   了解剩余的计划工作。

方法：
这是一个与用户的互动过程。一起逐节审阅，讨论影响和选项。用户做最终决定，但您需要提供关于技术可行性和影响的专业指导。

切记：变更是改进的机会，而不是失败。请专业、建设性地处理它们。]]

---

## 1. 理解触发器和背景

[[LLM: 首先要完全理解哪里出了问题以及原因。不要急于寻找解决方案。提出探究性问题：

-   究竟发生了什么触发了这次审查？
-   这是一个一次性问题还是更大问题的症状？
-   这能更早地预见到吗？
-   哪些假设是错误的？

要具体、实事求是，不要指责。]]

- [ ] **识别触发故事：** 清楚地识别出揭示问题的故事。
- [ ] **定义问题：** 精确地阐明核心问题。
    - [ ] 是技术限制/死胡同吗？
    - [ ] 是新发现的需求吗？
    - [ ] 是对现有需求的根本性误解吗？
    - [ ] 是基于反馈或新信息而必须的转向吗？
    - [ ] 是一个需要新方法的失败/废弃的故事吗？
- [ ] **评估初步影响：** 描述直接观察到的后果（例如，进度受阻、功能不正确、技术不可行）。
- [ ] **收集证据：** 记录支持问题定义的任何具体日志、错误消息、用户反馈或分析。

## 2. 史诗影响评估

[[LLM: 变更会在整个项目结构中产生连锁反应。系统地评估：

1.  我们能通过修改来挽救当前的史诗吗？
2.  考虑到这个变更，未来的史诗还有意义吗？
3.  我们是在创造还是消除了依赖关系？
4.  史诗的顺序需要重新排列吗？

考虑直接和下游的影响。]]

- [ ] **分析当前史诗：**
    - [ ] 包含触发故事的当前史诗还能完成吗？
    - [ ] 当前史诗需要修改吗（故事变更、增加、删除）？
    - [ ] 当前史诗应该被放弃还是从根本上重新定义？
- [ ] **分析未来史诗：**
    - [ ] 审查所有剩余的计划史诗。
    - [ ] 该问题是否需要更改未来史诗中的计划故事？
    - [ ] 该问题是否使任何未来的史诗无效？
    - [ ] 该问题是否需要创建全新的史诗？
    - [ ] 是否应该更改未来史诗的顺序/优先级？
- [ ] **总结史诗影响：** 简要记录对项目史诗结构和流程的总体影响。

## 3. 工件冲突与影响分析

[[LLM: 文档驱动着BMad的开发。检查每个工件：

1.  这个变更是否使已记录的决策无效？
2.  架构假设是否仍然有效？
3.  用户流程是否需要重新思考？
4.  技术约束是否与文档记录的不同？

要彻底——遗漏的冲突会导致未来的问题。]]

- [ ] **审查PRD：**
    - [ ] 该问题是否与PRD中陈述的核心目标或要求冲突？
    - [ ] PRD是否需要根据新的理解进行澄清或更新？
- [ ] **审查架构文档：**
    - [ ] 该问题是否与文档化的架构（组件、模式、技术选择）冲突？
    - [ ] 是否影响了特定的组件/图表/部分？
    - [ ] 技术清单是否需要更新？
    - [ ] 数据模型或模式是否需要修订？
    - [ ] 是否影响了外部API集成？
- [ ] **审查前端规范（如果适用）：**
    - [ ] 该问题是否与前端架构、组件库选择或UI/UX设计冲突？
    - [ ] 是否影响了特定的前端组件或用户流程？
- [ ] **审查其他工件（如果适用）：**
    - [ ] 考虑对部署脚本、IaC、监控设置等的影响。
- [ ] **总结工件影响：** 列出所有需要更新的工件以及所需的变更性质。

## 4. 前进路径评估

[[LLM: 清晰地展示选项及其优缺点。对于每条路径：

1.  需要多少工作量？
2.  哪些工作会被丢弃？
3.  我们承担了哪些风险？
4.  这对时间表有何影响？
5.  这在长期内是否可持续？

要诚实地对待权衡。很少有完美的解决方案。]]

- [ ] **选项1：直接调整/集成：**
    - [ ] 能否通过在现有计划内修改/添加未来的故事来解决问题？
    - [ ] 定义这些调整的范围和性质。
    - [ ] 评估此路径的可行性、工作量和风险。
- [ ] **选项2：潜在回滚：**
    - [ ] 恢复已完成的故事是否会显著简化问题处理？
    - [ ] 确定要考虑回滚的具体故事/提交。
    - [ ] 评估回滚所需的工作量。
    - [ ] 评估回滚的影响（丢失的工作、数据影响）。
    - [ ] 比较与直接调整的净收益/成本。
- [ ] **选项3：PRD MVP审查与潜在范围重定：**
    - [ ] 考虑到问题和约束，最初的PRD MVP是否仍可实现？
    - [ ] MVP范围是否需要缩减（移除功能/史诗）？
    - [ ] 核心MVP目标是否需要修改？
    - [ ] 是否需要替代方法来满足最初的MVP意图？
    - [ ] **极端情况：** 该问题是否需要根本性的重新规划或可能需要一个新的PRD V2（由PM处理）？
- [ ] **选择推荐路径：** 基于评估，就最可行的前进路径达成一致。

## 5. 冲刺变更提案组件

[[LLM: 提案必须是可操作且清晰的。确保：

1.  问题用通俗易懂的语言解释。
2.  影响在可能的情况下被量化。
3.  推荐的路径有明确的理由。
4.  下一步是具体且已分配的。
5.  定义了变更的成功标准。

该提案指导所有后续工作。]]

（确保所有先前章节中达成一致的要点都已在提案中体现）

- [ ] **已识别问题摘要：** 清晰、简洁的问题陈述。
- [ ] **史诗影响摘要：** 史诗受影响的方式。
- [ ] **工件调整需求：** 需要更改的文档列表。
- [ ] **推荐的前进路径：** 选择的解决方案及理由。
- [ ] **PRD MVP影响：** 范围/目标的变更（如有）。
- [ ] **高层行动计划：** 故事/更新的下一步。
- [ ] **代理交接计划：** 确定所需的角色（PM、架构师、设计架构师、PO）。

## 6. 最终审查与交接

[[LLM: 变更需要协调。在结束之前：

1.  用户是否完全同意该计划？
2.  所有利益相关者是否都理解其影响？
3.  向其他代理的交接是否清晰？
4.  如果变更失败，是否有回滚计划？
5.  我们将如何验证变更是否成功？

获得明确的批准——默许的同意会导致问题。

最终报告：
完成清单后，提供一份简明的摘要：

-   什么变了，为什么变。
-   我们对此采取什么措施。
-   谁需要做什么。
-   我们何时能知道它是否奏效。

保持行动导向和前瞻性。]]

- [ ] **审查清单：** 确认所有相关项目都已讨论。
- [ ] **审查冲刺变更提案：** 确保其准确反映了讨论和决定。
- [ ] **用户批准：** 获得用户对提案的明确批准。
- [ ] **确认下一步：** 重申交接计划和特定代理将要采取的下一步行动。

---