SDD + 敏捷混合工作流 — 长期项目的最优解

前 3 篇博客讲了 SDD 实战感悟、模板、决策清单。本文是 SDD 系列第 4 篇——**长期项目（1 月 - 1 年）**的最优解：SDD + 敏捷混合工作流。

写在前面：为什么需要混合

纯 SDD 和纯敏捷都有问题，长期项目需要混合。

【纯 SDD 的<!-- more -->
痛点】
- 前期慢
- 中后期变更成本高
- 不适合持续交付

【纯敏捷的痛点】
- 文档缺失
- 架构漂移
- 长期项目失控

【混合 = 取长补短】
- SDD 做骨架（spec / design / 总 tasks）
- 敏捷做血肉（每个 phase = 一个 sprint）
- 长期项目 = SDD 控盘
- 短期迭代 = 敏捷执行

---

一、总体架构（3 层结构）

┌──────────────────────────────────────┐
│         Layer 1：战略层（SDD）         │
│  ┌──────────────────────────────┐   │
│  │  spec.md（项目总需求）         │   │
│  │  design.md（项目总设计）       │   │
│  │  roadmap.md（路线图）          │   │
│  └──────────────────────────────┘   │
└──────────────┬───────────────────────┘
               │ 拆分
               ▼
┌──────────────────────────────────────┐
│      Layer 2：战术层（混合）          │
│  ┌──────────────────────────────┐   │
│  │  Phase 1 = 子 spec + 子 tasks │   │
│  │  Phase 2 = 子 spec + 子 tasks │   │
│  │  ...                          │   │
│  └──────────────────────────────┘   │
└──────────────┬───────────────────────┘
               │ 拆分
               ▼
┌──────────────────────────────────────┐
│         Layer 3：执行层（敏捷）        │
│  ┌──────────────────────────────┐   │
│  │  Sprint 1（1-2 周）           │   │
│  │  Sprint 2                     │   │
│  │  ...                          │   │
│  │  Demo + Retro                  │   │
│  └──────────────────────────────┘   │
└──────────────────────────────────────┘

3 层职责分工

层	文档	周期	稳定度	变更控制
战略层	spec / design / roadmap	1-2 月	高	大变更才更新
战术层	phase-N-spec / phase-N-tasks	2-4 周	中	phase 调整
执行层	sprint backlog	1-2 周	低	sprint 内灵活

---

二、4 大核心原则

1. 战略稳定，战术灵活

【战略层】
- spec / design / roadmap
- 1-2 月稳定一次
- 大变更才更新

【战术层】
- 每个 phase 的子 spec
- 2-4 周调整一次
- 跟随 sprint

【执行层】
- sprint 内容
- 1-2 周调整
- 灵活应对

2. 文档分层管理

【战略文档】
- 全员共享
- 1-2 月 review
- Git + Wiki

【战术文档】
- 团队共享
- 每 phase review
- Git + Notion

【执行文档】
- 个人持有
- daily 更新
- Jira / Linear / GitHub Issues

3. review 三层节奏

【战略层 review】
- 每月 1 次
- 全员 + 利益相关方
- 检查 spec / design / roadmap 是否需要调整

【战术层 review】
- 每 phase 1 次
- 团队 + tech lead
- 检查 phase spec / tasks 是否合理

【执行层 review】
- 每个 sprint 1 次
- 团队 demo + retro
- 检查 sprint 任务是否完成

4. 变更控制分层

【战略层变更】
- 影响范围大
- 需要充分讨论
- spec 改 → design 改 → 全部 phase 改

【战术层变更】
- 影响范围中
- 团队决策
- phase spec 改 + 当前 phase 调整

【执行层变更】
- 影响范围小
- 个人决策
- sprint 内任务调整

---

三、实战流程

Phase 0：项目启动（1 周）

【用 SDD】
- 写 spec.md（项目总需求）
- 写 design.md（项目总设计）
- 写 roadmap.md（拆 N 个 phase）
- 串讲 + 团队 review

【产出】
- 战略层文档稳定
- phase 划分清晰
- 团队对齐

Phase 1：第一阶段（2-4 周）

【第 1 周：mini-SDD】
- 写 phase-1-spec.md（细化 Phase 1 需求）
- 写 phase-1-tasks.md（Phase 1 任务拆分）
- 串讲 + 团队对齐

【第 2-3 周：Sprint 1-2】
- 每周 1 个 sprint
- 每日 standup
- 每周五 demo + retro

【第 4 周：Phase 1 收尾】
- Phase 1 验收
- 更新战略层（如需要）
- 启动 Phase 2

Phase 2 起：重复 Phase 1 流程

- mini-SDD（第 1 周）
- Sprint 3-4（第 2-3 周）
- Phase N 收尾（第 4 周）

---

roadmap.md（路线图）

# [项目名] - Roadmap

> 项目 N 个阶段的总路线图。每个 phase 是一个 mini-SDD。

## 项目里程碑

| Phase | 名称 | 周期 | 关键产出 | 负责人 | 状态 |
|-------|------|------|---------|--------|------|
| P0 | 项目脚手架 | 1 周 | 项目能跑 | [...] | ✅ |
| P1 | [阶段 1] | 3 周 | [产出 1] | [...] | 🚧 |
| P2 | [阶段 2] | 3 周 | [产出 2] | [...] | 📋 |
| P3 | [阶段 3] | 4 周 | [产出 3] | [...] | 📋 |
| P4 | 上线 + 优化 | 2 周 | 生产可用 | [...] | 📋 |

## Phase 详细拆分

### Phase 1: [名称]
- 周期：3 周（1 周 mini-SDD + 2 周 sprint）
- 关键产出：[...]
- 验收标准：[...]
- 依赖：[...]

### Phase 2: [名称]
（同 Phase 1 结构）

## 风险跟踪

| 风险 | 状态 | 处理 |
|------|------|------|
| Phase 1 延期 | 待观察 | 预留 buffer |

## 修订历史

| 版本 | 日期 | 作者 | 变更 |
|------|------|------|------|
| v1.0 | ... | ... | 初稿 |

---

phase-N-spec.md

# [项目名] - Phase [N] Spec

> 本文档是 Phase [N] 的细化 spec，是从项目总 spec 拆出来的。

## 1. 本阶段目标

### 1.1 业务目标
[本阶段要解决什么业务问题？]

### 1.2 验收标准
- [ ] 标准 1
- [ ] 标准 2

## 2. 功能需求（从总 spec 拆出）

### 2.1 本阶段必须
- [ ] F1.1: [...]
- [ ] F1.2: [...]

### 2.2 本阶段可选（如时间允许）
- [ ] F1.3: [...]

## 3. 非功能需求

- 性能：[...]
- 安全：[...]
- 兼容：[...]

## 4. 与项目总 spec 的关系

[本阶段对应总 spec 的哪几节？]

## 5. 范围之外（Out of Scope）

- [本阶段不做，但后续 phase 可能做的]

## 6. 风险

| 风险 | 概率 | 影响 | 对冲 |
|------|------|------|------|
| [...] | [...] | [...] | [...] |

## 7. 修订历史

| 版本 | 日期 | 作者 | 变更 |
|------|------|------|------|
| v1.0 | ... | ... | 初稿 |

---

phase-N-tasks.md

# [项目名] - Phase [N] Tasks

> 本阶段任务拆分，按 sprint 划分。

## Sprint 总览

| Sprint | 周期 | 目标 | 状态 |
|--------|------|------|------|
| Sprint N.1 | 2 周 | [目标 1] | 🚧 |
| Sprint N.2 | 2 周 | [目标 2] | 📋 |

## Sprint N.1: [名称]

### 目标
[sprint 目标]

### 任务（按 backlog 排序）
- [ ] T1: [任务] | 估时 2 天 | 状态 🚧
- [ ] T2: [任务] | 估时 1 天 | 状态 📋
- [ ] T3: [任务] | 估时 3 天 | 状态 📋

### 验收
- [ ] 标准 1
- [ ] 标准 2

### 风险
- [ ] 风险 1

## Sprint N.2: [名称]

（同 Sprint N.1 结构）

## 跨 Sprint 跟踪

| 任务 | Sprint | 状态 |
|------|--------|------|
| T1 | N.1 | 🚧 |
| T2 | N.1 | 📋 |

---

七、Sprint 节奏（敏捷部分）

每日 standup（15 分钟）

【3 个问题】
1. 昨天做了什么？
2. 今天做什么？
3. 有什么阻碍？

【原则】
- 不解决问题，只同步
- 阻碍 → 会后单独解决

每周 demo（30 分钟）

【内容】
- 本周完成的 phase 子任务
- 演示给团队 + 利益相关方
- 收集反馈

【原则】
- 必须可演示
- 不演示 = 没完成

每两周 retro（1 小时）

【3 个问题】
1. 什么做得好？
2. 什么做得不好？
3. 下次怎么改进？

【产出】
- 1-3 个改进行动
- 下次 retro 跟进

---

八、混合工作流的 5 大优势

1. 战略清晰

- 总 spec / design = 项目骨架
- 团队对齐不漂移
- 长期项目不失控

2. 战术灵活

- 每个 phase = mini-SDD
- 跟随 sprint 调整
- 不被前期设计绑架

3. 执行敏捷

- Sprint 短迭代
- 每日 standup
- 每周 demo

4. 文档分层

- 战略文档 = 稳定
- 战术文档 = 半稳定
- 执行文档 = 灵活
- 各层互不干扰

5. 风险可控

- 战略层风险 = 1-2 月发现
- 战术层风险 = 2-4 周发现
- 执行层风险 = 每天发现
= 早发现早处理

---

九、混合 vs 纯 SDD vs 纯敏捷

维度	纯 SDD	纯敏捷	混合
前期投入	高	低	中
中后期灵活	低	高	高
文档完整度	高	低	中高
团队对齐	强	弱	强
适用项目	1-4 周	任意	1 月 - 1 年
变更成本	高	低	中
失败风险	设计错	架构漂移	可控

---

十、适用 vs 不适用

✅ 适用场景

1. 长期项目（1 月 - 1 年）
2. 持续交付（产品 + 迭代）
3. 团队规模 3-10 人
4. 需求基本清晰但允许变化
5. 失败成本中等
6. 团队愿意写文档

❌ 不适用场景

1. 1 周小项目（直接 SDD）
2. 紧急上线（直接干）
3. 完全模糊需求（先调研）
4. 强依赖其他团队（等稳定）
5. 1 人小项目（纯 SDD 即可）

---

十一、实战案例（数字员工 AI 产品化）

项目背景

- 周期：3 月
- 团队：3 人
- 失败成本：中
- 目标：从 MVP 到生产可用

混合工作流实施

Month 1：
- Week 1: SDD（spec + design + roadmap）
- Week 2-3: Sprint 1-2（Phase 1: MVP 核心）
- Week 4: demo + retro + 启动 Phase 2

Month 2：
- Week 5-6: Sprint 3-4（Phase 2: 功能完善）
- Week 7-8: Sprint 5-6（Phase 2 收尾）

Month 3：
- Week 9-10: Sprint 7-8（Phase 3: 性能 + 安全）
- Week 11-12: 上线 + 优化

产出清单

【战略层】
- spec.md（项目总需求）
- design.md（项目总设计）
- roadmap.md（路线图）

【战术层】
- phase-1-spec.md / phase-1-tasks.md
- phase-2-spec.md / phase-2-tasks.md
- phase-3-spec.md / phase-3-tasks.md

【执行层】
- 每个 sprint 的 backlog
- 每周 demo 视频
- 每两周 retro 记录

---

十二、5 大常见坑 + 解决

坑 1：战略层频繁改动

【症状】
- 每月改 spec
- 每月改 design
- 团队无所适从

【解决】
- 战略层稳定窗口 = 至少 2 月
- 大变更才触发 review
- 区分"小调整"vs"战略变更"

坑 2：战术层不收敛

【症状】
- phase 一直延期
- tasks 一直加
- 越做越乱

【解决】
- 强制 phase 截止日
- 范围内 = 必做
- 范围外 = 下个 phase

坑 3：执行层 sprint 不规律

【症状】
- sprint 长度混乱（1 周 / 3 周）
- standup 时有时无
- demo 跳票

【解决】
- sprint 长度固定（2 周最佳）
- standup 强制
- demo 强制

坑 4：文档维护脱节

【症状】
- sprint 完成但 tasks.md 没更新
- phase 完成但 phase-spec.md 没更新
- 战略层文档过期

【解决】
- sprint 完成 = 自动更新 tasks.md
- phase 完成 = 自动更新 roadmap.md
- 每月 review 战略层

坑 5：角色混乱

【症状】
- 谁都写 spec
- 谁都改 design
- 没有 owner

【解决】
- 战略层：1 个 owner
- 战术层：每个 phase 1 个 lead
- 执行层：sprint 内灵活

---

十三、工具栈推荐

战略层

- Git + Markdown（spec / design / roadmap）
- Wiki（Confluence / Notion）
- 版本控制：Git

战术层

- Git + Markdown（phase-N-spec / phase-N-tasks）
- Notion（团队协作）
- 文档评论 + 串讲

执行层

- Jira / Linear / GitHub Issues（backlog）
- Slack / 飞书（standup）
- Miro / FigJam（demo 可视化）

---

十四、如何选择工作流

决策表

【项目 < 1 周】
  → 纯 SDD（或直接干）

【项目 1-4 周】
  → 标准 SDD

【项目 1 月 - 1 年】
  → SDD + 敏捷混合 ✅

【项目 > 1 年】
  → 混合 + 多 team

团队规模适配

【1 人】→ 纯 SDD
【2-3 人】→ SDD + 轻敏捷
【3-10 人】→ 混合工作流
【10+ 人】→ 混合 + 多 team

---

十五、SDD 系列总结

【第 1 篇】SDD 模式 AI Coding 实战感悟（流程 + 踩坑）
【第 2 篇】SDD 模式实战指南（决策清单 + 三份模板）
【第 3 篇】（本文）SDD + 敏捷混合工作流（长期项目）
【第 4 篇】（待写）SDD 与 AI Coding 的未来

---

写在最后：混合是常态

【工作流选择的真相】
- 没有"最好的"工作流
- 只有"最适合的"工作流

【SDD 的本质】
- 不是"写文档"
- 是"在变化中找到稳定"

【敏捷的本质】
- 不是"快速迭代"
- 是"在稳定中拥抱变化"

【混合的本质】
- 战略稳定 + 战术灵活 + 执行敏捷
- 长期项目的不二之选

---

思维模型附录

1. 分层思维：3 层结构 = 战略 + 战术 + 执行
2. 节奏思维：3 层 review 节奏不同
3. 变更控制：分层变更 = 不同风险等级
4. 文档分层：稳定 / 半稳定 / 灵活
5. 决策矩阵：根据项目时长 + 团队规模选择

---

给读者的 3 个问题

1. 你目前项目用纯 SDD 还是纯敏捷？
   我：1 周内 SDD，1 月 + 混合
2. 你的战略层文档多久 review 一次？
   我：每月 1 次
3. 你的 sprint 长度固定吗？
   我：固定 2 周

---

SDD 不是工具，是纪律。敏捷不是混乱，是节奏。混合不是妥协，是最优。

长期项目 = SDD 控盘 + 敏捷执行 = 战略清晰 + 战术灵活。