# 02-敏捷开发与迭代管理工作流

## 一、工作流总览

```
┌─────────────────────────────────────────────────────────────────────┐
│                   敏捷开发与迭代管理工作流全景图                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │              持续的产品Backlog管理                             │  │
│  │  Epic/Feature/Story → 优先级排序 → 估算 → 多迭代规划           │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │1.Sprint   │──>│2.每日站会 │──>│3.持续集成 │──>│4.Sprint   │        │
│  │ 规划      │   │ 与协作    │   │ 与开发    │   │ 评审      │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│       │                                              │              │
│       v                                              v              │
│  ┌──────────┐                                  ┌──────────┐        │
│  │5.回顾与   │<─────────────────────────────────│ (下一个   │        │
│  │ 持续改进  │                                  │  Sprint) │        │
│  └──────────┘                                  └──────────┘        │
│                                                                     │
│  Sprint周期: 2周（推荐）| Scrum仪式: 4个 | 工具: JIRA/Trello/禅道     │
└─────────────────────────────────────────────────────────────────────┘
```

## 二、适用场景

本工作流适用于智慧交通软件的敏捷开发管理。考虑到交通行业的公共部门国企客户特点，建议采用"敏捷开发+里程碑交付"的混合模式。

## 三、混合敏捷模式说明

### 3.1 为什么交通项目需要混合敏捷？

| 交通项目特点 | 纯敏捷挑战 | 混合做法 |
|-------------|-----------|---------|
| 固定工期+预算的合同 | Sprint范围不能无限变化 | 固定范围基线+受控变更 |
| 公共部门验收要求完整文档 | 重代码轻文档 | Sprint成果同步更新文档 |
| 多系统集成需要整体规划 | Sprint关注局部 | 架构Sprint先行的SAFe模式 |
| 客户不习惯频繁参与 | Sprint Review没观众 | 合并为月度演示 |
| 等保密评需最终版本 | 持续交付无法备案 | 阶段性发布+最终版本 |

### 3.2 推荐混合模式

```
推荐: Scrum + 里程碑管理

每2周一个Sprint（内部节奏）
每4周一个版本发布（内部里程碑）
每2-3个月一个客户验收里程碑（客户节点）

┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│Sprint│→│Sprint│→│Sprint│→│Sprint│→│Sprint│→│Sprint│→...
│  1   │ │  2   │ │  3   │ │  4   │ │  5   │ │  6   │
└──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
   │        │        │        │        │        │
   └────────┼────────┘        └────────┼────────┘
            │                          │
            v                          v
     ┌─────────────┐          ┌─────────────┐
     │  里程碑M1   │          │  里程碑M2   │
     │ (客户验收)   │          │ (客户验收)   │
     └─────────────┘          └─────────────┘
```

---

## 四、详细步骤说明

---

### 步骤1：Sprint规划

**目标**：规划每个Sprint（2周）的工作内容和目标。

**输入**：产品Backlog、上一个Sprint的Velocity
**输出**：Sprint Backlog、Sprint目标

**操作指南**：

**1.1 Sprint规划会议**（2-3小时，Sprint首日上午）

| 环节 | 内容 | 时长 |
|------|------|:---:|
| Sprint目标设定 | PO介绍本次Sprint的业务目标 | 15min |
| 容量确认 | 团队确认本Sprint可用人天 | 10min |
| Story选择 | 按优先级从Backlog顶部选取Story | 45min |
| 任务分解 | 每个Story分解为技术任务（≤1天/任务） | 60min |
| 风险识别 | 识别本Sprint的风险和依赖 | 15min |

**1.2 容量规划**

```
Sprint容量计算:

团队人数: N
Sprint工作日: 10天(2周)
有效工作时间: 6小时/天（扣除会议、沟通等）
Sprint容量: N × 10 × 6 = ___ 小时

预留缓冲:
  - 紧急支持和Bug修复: 20%
  - 技术债务/重构: 10%
  - 可用开发容量: 容量 × 70%

Story Points规划:
  基于上3个Sprint的平均Velocity
  设定本Sprint目标Velocity = 平均Velocity × 90%（保守估算）
```

---

### 步骤2：每日站会与协作

**目标**：每日同步进度、发现问题、协调协作。

**操作指南**：

**2.1 站会标准流程**（15分钟，每日固定时间）

每人回答三个问题：
1. 昨天完成了什么？
2. 今天计划做什么？
3. 有什么阻塞？

**2.2 交通项目远程协作要点**

- 客户现场+远程混合团队常见
- 使用Teams/企业微信/钉钉做日常沟通
- 客户侧需要对接人（最好驻场）
- 重要沟通留书面记录（避免口头冲突）

---

### 步骤3：持续集成与开发

**目标**：保证代码质量和持续可交付。

**操作指南**：

**3.1 开发分支策略**

```
推荐: Git Flow (简化版)

  master (生产)
    │
    └── develop (开发主线)
          │
          ├── feature/story-001
          ├── feature/story-002
          ├── bugfix/xxx
          └── release/v1.2.0

规则:
  · feature分支从develop拉出，合并回develop
  · release分支从develop拉出，合并到master和develop
  · master每次合并=一次发布
  · feature分支生命周期≤1个Sprint
```

**3.2 CI/CD流水线**

```
代码提交 → 代码扫描(SonarQube) → 单元测试 → 构建 → 
  自动化测试 → 部署到测试环境 → (手动)部署到生产
```

**3.3 质量门禁**

| 门禁 | 标准 | 不通过后果 |
|------|------|-----------|
| 代码覆盖率 | >70% | 打回重写测试 |
| 代码扫描 | 0 Critical/Blocker | 打回修复 |
| 单元测试 | 全部通过 | 打回修复 |
| 安全扫描 | 0高危漏洞 | 打回修复 |

---

### 步骤4：Sprint评审

**目标**：向干系人演示Sprint成果，收集反馈。

**操作指南**：

**4.1 Sprint Review流程**（1小时，Sprint最后一日下午）

| 环节 | 内容 | 时长 |
|------|------|:---:|
| Sprint目标回顾 | 回顾本Sprint目标及完成情况 | 5min |
| 功能演示 | 逐个演示完成的Story（重点） | 30min |
| 干系人反馈 | 收集问题和改进建议 | 15min |
| Backlog调整 | 根据反馈调整后续Backlog | 10min |

**4.2 交通客户Review要点**

- 客户可能不习惯每2周参加，可改为月度演示
- 演示环境要稳定（用测试环境，不要Live Demo）
- 准备好"如果客户说和想象的不一样"的预案

---

### 步骤5：回顾与持续改进

**目标**：回顾Sprint过程，识别改进机会。

**操作指南**：

**5.1 Sprint回顾**（1小时，Sprint最后一日）

```
回顾三问:

1. Start（开始做什么？）
   - 哪些好的实践应该开始做？

2. Stop（停止做什么？）
   - 哪些行为阻碍了效率应该停止？

3. Continue（继续做什么？）
   - 哪些好的做法应该继续保持？

每个Sprint选出1-2个改进项，下个Sprint验证
```

**5.2 团队速率(Velocity)跟踪**

```
Velocity趋势:

 Sprint │ Planned │ Actual │ 趋势
────────┼─────────┼────────┼─────
 S1     │ 25 SP   │ 22 SP  │ -
 S2     │ 24 SP   │ 24 SP  │ ↗
 S3     │ 26 SP   │ 28 SP  │ ↗↗
 S4     │ 28 SP   │ 26 SP  │ ↘
 
 4-Sprint平均Velocity: 25 SP
 后续Sprint规划参考: 25 SP × 90% = 22.5 SP
```

---

## 五、角色与职责（RACI矩阵）

| 活动 | Scrum Master | Product Owner | 开发团队 | 客户PO(业务方) |
|------|:---:|:---:|:---:|:---:|
| Backlog管理 | C | **R/A** | C | C |
| Sprint规划 | **R** | **A** | C | I |
| 每日站会 | **R** | C | C | I |
| 开发与测试 | I | I | **R/A** | I |
| Sprint Review | C | **R** | C | **C** |
| 回顾改进 | **R/A** | C | C | I |

---

## 六、关键检查点

| # | 检查点 | 通过标准 |
|---|--------|---------|
| CP1 | Sprint Backlog就绪 | 每个Story有任务分解和估算 |
| CP2 | CI/CD运行 | 每日构建成功率>90% |
| CP3 | Sprint目标达成 | 承诺的Story 100%完成 |
| CP4 | 质量门禁 | 代码覆盖率和扫描达标 |
| CP5 | Velocity稳定 | 连续3个Sprint的Velocity波动<20% |

---

## 七、估计时长

| 活动 | 频次 | 每次时长 |
|------|:---:|:---:|
| Sprint规划 | 双周 | 2-3小时 |
| 每日站会 | 每日 | 15分钟 |
| Sprint Review | 双周 | 1小时 |
| Sprint回顾 | 双周 | 1小时 |
| Backlog梳理 | 每周 | 1小时 |

---

## 八、输出物清单

1. **产品Backlog**（JIRA/禅道）
2. **Sprint Backlog**（JIRA/禅道）
3. **Sprint燃尽图**（JIRA自动）
4. **Sprint Review演示视频/截图**（归档）
5. **Sprint回顾纪要**（.docx）
6. **Velocity趋势报告**（JIRA自动）

---

> **版本**: V1.0 | **撰写日期**: 2025-07 | **方法论**: Scrum + SAFe
