3.2 KiB
3.2 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| 为什么解决方案阶段很重要 | 理解为什么解决方案阶段对于多史诗项目至关重要 |
|
阶段 3（解决方案）将构建什么（来自规划）转化为如何构建（技术设计）。该阶段通过在实施开始前记录架构决策，防止多史诗项目中的智能体冲突。
没有解决方案阶段的问题
智能体 1 使用 REST API 实现史诗 1
智能体 2 使用 GraphQL 实现史诗 2
结果：API 设计不一致，集成噩梦
当多个智能体在没有共享架构指导的情况下实现系统的不同部分时，它们会做出可能冲突的独立技术决策。
有解决方案阶段的解决方案
架构工作流决定："所有 API 使用 GraphQL"
所有智能体遵循架构决策
结果：实现一致，无冲突
通过明确记录技术决策，所有智能体都能一致地实现，集成变得简单直接。
解决方案阶段 vs 规划阶段
| 方面 | 规划（阶段 2） | 解决方案（阶段 3） |
|---|---|---|
| 问题 | 做什么和为什么？ | 如何做？然后是什么工作单元？ |
| 输出 | FRs/NFRs（需求） | 架构 + 史诗/用户故事 |
| 智能体 | PM | 架构师 → PM |
| 受众 | 利益相关者 | 开发人员 |
| 文档 | PRD（FRs/NFRs） | 架构 + 史诗文件 |
| 层级 | 业务逻辑 | 技术设计 + 工作分解 |
核心原则
使技术决策明确且有文档记录，以便所有智能体一致地实现。
这可以防止：
- API 风格冲突（REST vs GraphQL）
- 数据库设计不一致
- 状态管理分歧
- 命名约定不匹配
- 安全方法差异
何时需要解决方案阶段
| 流程 | 需要解决方案阶段？ |
|---|---|
| Quick Flow | 否 - 完全跳过 |
| BMad Method Simple | 可选 |
| BMad Method Complex | 是 |
| Enterprise | 是 |
:::tip[经验法则] 如果你有多个可能由不同智能体实现的史诗，你需要解决方案阶段。 :::
跳过的代价
在复杂项目中跳过解决方案阶段会导致：
- 集成问题在冲刺中期发现
- 返工由于实现冲突
- 开发时间更长整体
- 技术债务来自不一致模式
:::caution[成本倍增] 在解决方案阶段发现对齐问题比在实施期间发现要快 10 倍。 :::
术语说明
- agent：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
- epic：史诗。在敏捷开发中，指一个大型的工作项，可分解为多个用户故事。
- REST API：表述性状态传递应用程序接口。一种基于 HTTP 协议的 Web API 设计风格。
- GraphQL：一种用于 API 的查询语言和运行时环境。
- FRs/NFRs：功能需求/非功能需求。Functional Requirements/Non-Functional Requirements 的缩写。
- PRD：产品需求文档。Product Requirements Document 的缩写。
- PM：产品经理。Product Manager 的缩写。
- sprint：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
- technical debt：技术债务。指为了短期目标而选择的不完美技术方案，未来需要付出额外成本来修复。