bmad 企业级敏捷开发

bmad 工作流概述

bmad（Business-driven Multi-Agent Development）是 PinableAgents 为企业级项目设计的敏捷开发工作流。它模拟了一个完整的 Scrum 团队，由六个专业角色的智能体组成，覆盖从产品需求定义到代码交付审查的全流程。

bmad 的核心理念是"用流程保证质量"。在企业环境中，代码质量不仅取决于开发者的个人能力，更取决于团队协作流程的完善程度。bmad 通过标准化的角色分工、量化的评审机制和严格的门禁制度，确保每个交付物都经过充分的需求分析、架构评估、编码实现、质量验证和代码审查。

与 do 工作流相比，bmad 更适合涉及多个模块、需要跨团队协作、对质量要求极高的大型任务。它的流程更重，执行时间更长，但产出的可靠性和完整性也显著更高。

bmad 不是为了让流程变慢，而是为了在复杂项目中避免返工。一个经过完整 bmad 流程的功能，其上线后的缺陷率通常比快速开发低 60% 以上。

六角色智能体团队

bmad 工作流的核心是六个角色分明的智能体，每个角色对应传统 Scrum 团队中的一个关键职位。

1. Product Owner（产品负责人）

负责需求的定义、优先级排序和验收标准制定。该智能体分析用户的业务需求描述，产出结构化的 PRD（Product Requirements Document），包含用户故事、验收标准和优先级矩阵。

职责	输出物
需求分析与结构化	PRD 文档（含用户故事和验收标准）
优先级排序	优先级矩阵（MoSCoW 分类）
范围控制	MVP 范围定义和后续迭代规划

2. Architect（架构师）

负责技术方案的设计和架构决策。基于 PRD 和现有代码库的分析，产出技术设计文档，包括系统架构图、API 设计、数据模型和技术选型论证。

3. Scrum Master（流程管理者）

负责协调各角色之间的信息流转和流程推进。监控各阶段的质量门禁状态，在门禁失败时协调回溯和修复。Scrum Master 不直接产出代码或文档，但确保整个流程的效率和质量。

4. Developer（开发者）

负责根据技术设计文档编写实现代码。遵循架构师制定的技术方案和编码规范，在隔离的 Git worktree 中完成开发，确保代码变更可追溯和可回滚。

5. QA Engineer（质量工程师）

负责测试策略制定和测试执行。产出测试计划、编写自动化测试、执行回归测试，并生成测试报告。测试覆盖率要求不低于 85%。

6. Reviewer（代码审查员）

负责最终的代码质量审查。使用五维评估框架（可维护性、性能、安全性、风格一致性、向后兼容性）对整个交付物进行全面审查，产出审查报告和改进建议。

PRD 百分制评分机制

bmad 的一个核心创新是对 PRD 文档实施百分制量化评分。PRD 必须达到 80 分以上才能通过门禁进入架构设计阶段。评分维度如下：

评分维度	分值	评分标准
需求完整性	20 分	所有功能点是否有明确描述，无遗漏
验收标准明确性	20 分	每个用户故事是否有可验证的验收条件
边界条件覆盖	15 分	异常场景、边界值、权限控制是否考虑周全
优先级合理性	10 分	MoSCoW 分类是否合理，MVP 范围是否恰当
技术可行性	15 分	需求是否在现有技术栈和时间约束内可实现
非功能性要求	10 分	性能、安全、可用性要求是否明确
文档规范性	10 分	格式标准、术语一致、无歧义表述

# PRD 评分输出示例
[bmad:po] PRD 评分结果：
  需求完整性:     18/20  ✓ (缺少错误码定义，扣 2 分)
  验收标准明确性: 20/20  ✓
  边界条件覆盖:   12/15  ✓ (未覆盖并发注册场景，扣 3 分)
  优先级合理性:   10/10  ✓
  技术可行性:     13/15  ✓ (第三方支付 SDK 兼容性待验证，扣 2 分)
  非功能性要求:    8/10  ✓ (未指定响应时间 SLA，扣 2 分)
  文档规范性:      9/10  ✓
  总分: 90/100 -> 通过门禁

架构评审门禁

架构设计完成后，需要通过架构评审门禁才能进入开发阶段。评审由 Architect 智能体自评和 Reviewer 智能体交叉评审两轮组成。

评审检查清单

一致性：技术方案是否与项目现有架构模式一致
可扩展性：设计是否预留了合理的扩展点，但不过度设计
依赖管理：新引入的依赖是否必要，是否有已知的安全漏洞
数据模型：数据库 schema 变更是否向后兼容，迁移脚本是否可逆
API 设计：接口是否遵循 RESTful 规范，版本策略是否合理
错误处理：异常路径是否有明确的处理策略

Sprint 规划流程

bmad 的 Sprint 规划由 Scrum Master 智能体主导，流程包括三个步骤：

Backlog 梳理：Product Owner 整理和排序待办事项，确定 Sprint 目标
容量评估：根据任务复杂度估算 Story Points，确定 Sprint 容量
任务拆解：将用户故事拆解为可独立完成的开发任务，分配给 Developer 智能体

# 启动 Sprint 规划
pinable-agents run bmad --phase sprint-planning \
  --backlog ./backlog.md \
  --sprint-capacity 40  # Story Points 上限

# Sprint 规划输出
[bmad:sm] Sprint #12 规划完成
  Sprint 目标: 完成商品搜索和购物车核心功能
  总 Story Points: 38/40
  用户故事数: 5
  预计开发任务数: 14

实战：电商功能 Sprint 周期

以下演示使用 bmad 工作流完成一个电商项目中"商品搜索与筛选"功能的完整 Sprint 周期。

Phase 1：需求定义

pinable-agents run bmad \
  --task "实现商品搜索与筛选功能，支持关键词搜索、分类筛选、价格区间、排序" \
  --context "项目使用 Go + Gin + PostgreSQL，已有商品表 products"

Product Owner 智能体产出 PRD，包含 4 个用户故事：关键词搜索、分类筛选、价格区间过滤、结果排序。每个故事附带 3-5 条验收标准。PRD 评分 92 分，通过门禁。

Phase 2：架构设计

Architect 智能体分析现有代码后，设计了搜索服务的技术方案：使用 PostgreSQL 全文搜索而非引入 Elasticsearch（遵循 KISS 原则），新增 handlers/search.go 和 services/search.go，复用现有的分页中间件和响应格式。

Phase 3：开发实现

Developer 智能体在 Git worktree 中依次完成搜索服务层、HTTP 处理器、路由注册和数据库索引迁移。每完成一个文件，Scrum Master 检查是否符合架构设计的规定。

Phase 4：质量验证

QA Engineer 产出 22 个测试用例，覆盖所有验收标准和边界条件。测试覆盖率 91%，所有测试通过。

Phase 5：代码审查

Reviewer 使用五维评估框架审查全部变更，提出两个改进建议（增加搜索关键词的 XSS 过滤、优化分页查询的索引策略），Developer 修复后二次审查通过。

角色交互与信息流

bmad 的六个角色之间存在严格定义的信息流转规则。每个角色只接收来自其上游角色的产出，并将自己的产出传递给下游角色。Scrum Master 作为中枢，可以与所有角色交互。

Product Owner -> Architect -> Developer -> QA Engineer -> Reviewer
      |               |            |             |             |
      +----------- Scrum Master（全局协调）-----------+

信息流向：
  PO 产出 PRD -> Architect 接收 PRD，产出技术设计
  Architect 产出设计 -> Developer 接收设计，产出代码
  Developer 产出代码 -> QA 接收代码，产出测试报告
  QA 产出报告 -> Reviewer 接收全部产出，进行最终审查

Jira / Linear 集成

bmad 支持与主流项目管理工具的双向集成，将 Sprint 规划和任务状态同步到团队的 Jira 或 Linear 看板。

配置集成

# 在 config.json 中配置 Jira 集成
{
  "integrations": {
    "jira": {
      "url": "https://your-team.atlassian.net",
      "project": "PROJ",
      "api_token": "${JIRA_API_TOKEN}",
      "sync_mode": "bidirectional"
    }
  }
}

# 或配置 Linear 集成
{
  "integrations": {
    "linear": {
      "api_key": "${LINEAR_API_KEY}",
      "team_id": "TEAM-001",
      "sync_mode": "push"
    }
  }
}

同步内容

Sprint 创建：bmad 启动新 Sprint 时，自动在 Jira/Linear 中创建对应的 Sprint
任务创建：每个拆解的开发任务自动创建为 Issue/Task
状态同步：任务在 bmad 中的状态变更实时同步到看板
验收报告：Sprint 完成后的报告自动附加到对应的 Epic

CLI 命令参考

# 完整 Sprint 流程
pinable-agents run bmad --task "任务描述"

# 仅执行特定阶段
pinable-agents run bmad --phase prd --task "任务描述"
pinable-agents run bmad --phase architecture --prd ./prd.md
pinable-agents run bmad --phase development --design ./design.md

# 配置 Sprint 参数
pinable-agents run bmad --task "任务描述" \
  --sprint-capacity 40 \
  --sprint-duration 2w \
  --quality-threshold 80

# 启用集成
pinable-agents run bmad --task "任务描述" --sync jira

最佳实践

在 PRD 中尽可能详细地描述验收标准，这直接影响后续所有阶段的质量
对于 MVP 版本，主动使用 MoSCoW 分类将非核心需求标记为 "Won't have"
架构设计阶段不要引入不必要的复杂性，优先复用项目中已有的模式
利用 Jira/Linear 集成保持团队对 AI 辅助开发进度的可见性
Sprint 容量不要设置过满，预留 15-20% 的缓冲应对返工和意外情况

bmad 工作流最大的价值不是速度，而是可预测性。当你的项目需要向利益相关者保证交付质量和时间线时，bmad 提供的结构化流程和量化评估是最有力的支撑。

目录