(chapter02)=
# 第二章：敏捷革命 — 从计划驱动到价值驱动

```{mermaid}
mindmap
  root((敏捷革命))
    敏捷宣言
      2001年雪鸟会议
      四条价值观
      十二条原则
    主流方法论
      Scrum
      极限编程XP
      Kanban
    核心实践
      用户故事
      Sprint
      站会
      回顾会
    CI/CD
      持续集成
      持续交付
      持续部署
    困境与反思
      假敏捷
      规模化挑战
      敏捷工业复合体
    Post-Agile
      回归原则
      AI时代挑战
```

> "个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。" — 敏捷宣言（2001）

## 2.1 敏捷宣言的诞生

2001 年 2 月，17 位软件开发领域的思想领袖聚集在美国犹他州雪鸟滑雪度假村。他们来自不同的方法论阵营——极限编程（XP）、Scrum、DSDM、自适应软件开发、Crystal、特征驱动开发（FDD）、实用编程等——但他们有一个共同的不满：**传统的重量级开发流程正在扼杀软件开发的创造力和效率**。

经过两天的激烈讨论，他们达成了共识，发布了《敏捷软件开发宣言》（Agile Manifesto），提出了四条核心价值观和十二条原则。

### 四条核心价值观

```{list-table}
:header-rows: 1
:widths: 45 10 45

* - 我们更看重
  - 胜过
  - 虽然右边也有价值
* - **个体和互动**
  - >
  - 流程和工具
* - **工作的软件**
  - >
  - 详尽的文档
* - **客户合作**
  - >
  - 合同谈判
* - **响应变化**
  - >
  - 遵循计划
```

### 十二条原则（精选）

1. 最高优先级是通过**持续交付有价值的软件**来满足客户
2. 欢迎需求变化，即使在开发后期
3. 经常交付可工作的软件，周期从几周到几个月，越短越好
4. 业务人员和开发人员必须每天一起工作
5. 以**受激励的个体**为核心构建项目
6. 面对面交谈是最有效的沟通方式
7. **可工作的软件**是进度的首要度量标准

## 2.2 主流敏捷方法论对比

### Scrum

Scrum 是最广泛采用的敏捷框架，由 Ken Schwaber 和 Jeff Sutherland 于 1995 年正式提出。

**核心角色：**
- **Product Owner（产品负责人）**：定义产品待办列表，确定优先级
- **Scrum Master**：服务型领导，移除障碍，守护流程
- **Development Team（开发团队）**：自组织的跨职能团队（5-9 人）

**核心事件：**

```
Sprint（冲刺，通常 2-4 周）
├── Sprint Planning（冲刺规划会）
│   └── 选择本轮要完成的用户故事
├── Daily Standup（每日站会，15 分钟）
│   ├── 昨天做了什么？
│   ├── 今天计划做什么？
│   └── 有什么障碍？
├── Sprint Review（冲刺评审会）
│   └── 向利益相关者演示成果
└── Sprint Retrospective（冲刺回顾会）
    └── 团队反思改进
```

**核心工件：**
- **Product Backlog**：产品待办列表
- **Sprint Backlog**：冲刺待办列表
- **Increment**：可交付的产品增量

### 极限编程（XP）

XP 由 Kent Beck 于 1996 年提出，强调工程实践：

| 实践 | 说明 |
|------|------|
| **结对编程** | 两人一台电脑，一人编码一人审查 |
| **测试驱动开发（TDD）** | 先写测试，再写实现 |
| **持续集成** | 频繁合并代码，自动化构建和测试 |
| **重构** | 持续改善代码结构 |
| **简单设计** | 只实现当前需要的功能 |
| **集体代码所有权** | 任何人可以修改任何代码 |
| **编码规范** | 统一的代码风格 |
| **可持续节奏** | 不加班，保持长期生产力 |

### Kanban

Kanban 源自丰田生产方式，由 David Anderson 引入软件开发：

```
┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ 待办(To  │ 分析     │ 开发     │ 测试     │ 完成     │
│  Do)     │ (WIP:2)  │ (WIP:3)  │ (WIP:2)  │ (Done)   │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ [Story5] │ [Story4] │ [Story3] │ [Story1] │ [StoryA] │
│ [Story6] │          │ [Story2] │          │ [StoryB] │
│ [Story7] │          │          │          │ [StoryC] │
└──────────┴──────────┴──────────┴──────────┴──────────┘
```

Kanban 的核心原则：
- **可视化工作流**：用看板展示所有工作项
- **限制在制品（WIP）**：每个阶段限制并行任务数
- **管理流动**：关注工作项从开始到完成的流动速度
- **持续改进**：通过度量和反馈不断优化

### 三种方法论对比

| 维度 | Scrum | XP | Kanban |
|------|-------|-----|--------|
| 迭代 | 固定时间盒（Sprint） | 固定时间盒 | 连续流动 |
| 角色 | PO、SM、Team | Coach、Customer、Team | 无固定角色 |
| 变更 | Sprint 内不变更 | 随时可变更 | 随时可变更 |
| 度量 | 速度（Velocity） | 速度 | 前置时间、吞吐量 |
| 适用 | 产品开发 | 工程实践 | 运维、支持 |

## 2.3 用户故事与估算

### 用户故事

用户故事是敏捷中描述需求的标准格式：

```
作为 <角色>，
我想要 <功能>，
以便 <价值>。

示例：
作为一个注册用户，
我想要能够重置密码，
以便在忘记密码时恢复账户访问。
```

**INVEST 原则**：好的用户故事应该是：
- **I**ndependent（独立的）
- **N**egotiable（可协商的）
- **V**aluable（有价值的）
- **E**stimable（可估算的）
- **S**mall（小的）
- **T**estable（可测试的）

### 估算方法

**故事点（Story Points）** 使用斐波那契数列：1, 2, 3, 5, 8, 13, 21...

```
Planning Poker 流程：
1. PO 讲解用户故事
2. 团队成员提问澄清
3. 每人独立选择一张估算卡
4. 同时亮牌
5. 讨论差异最大的估算
6. 重新估算直到达成共识
```

## 2.4 持续集成与持续交付

### CI/CD 的兴起

持续集成（CI）由 Martin Fowler 和 Kent Beck 推广，核心理念是**频繁地将代码集成到主干**：

```yaml
# 一个典型的 CI/CD 流水线（GitHub Actions）
name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run linting
        run: ruff check .
      - name: Run tests
        run: pytest --cov=src tests/
      - name: Build
        run: python -m build

  deploy:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh
```

### CI/CD 的演进

```
手动构建 → 夜间构建 → 持续集成 → 持续交付 → 持续部署
(1990s)    (2000s)    (2006)     (2010)     (2015)
```

- **持续集成（CI）**：每次提交自动构建和测试
- **持续交付（CD）**：随时可以部署到生产环境（但需要手动触发）
- **持续部署（CD）**：每次通过测试的变更自动部署到生产环境

## 2.5 敏捷的成功与困境

### 成功之处

- ✅ 缩短了交付周期，从月/年级别到周级别
- ✅ 提高了客户满意度，通过频繁反馈
- ✅ 改善了团队士气，通过自组织和赋权
- ✅ 降低了项目失败率

### 困境与反思

然而，敏捷在实践中也暴露了很多问题：

**1. "假敏捷"（Agile in Name Only）**

```
常见的假敏捷现象：
❌ 有站会但没有真正的沟通
❌ 有 Sprint 但没有可交付的增量
❌ 有 Scrum Master 但只是项目经理换了个头衔
❌ 有看板但没有 WIP 限制
❌ 有回顾会但从不改进
```

**2. 敏捷工业复合体**

敏捷认证（CSM、SAFe 等）变成了一门生意，很多组织花大价钱获取认证，却没有真正理解敏捷的精神。

**3. 规模化的挑战**

敏捷最初是为小团队设计的（5-9 人），当组织试图将其扩展到数百人时，出现了 SAFe、LeSS、Nexus 等规模化框架，但这些框架本身又变得很"重量级"。

## 2.6 从 Agile 到 Post-Agile

### Post-Agile 的反思

2020 年代，越来越多的声音开始反思敏捷：

> "敏捷已经赢了，但也因此失去了它的灵魂。" — Dave Thomas（敏捷宣言签署者之一）

Post-Agile 的核心观点：
- 不要教条地遵循任何框架
- 关注**原则**而非**实践**
- 根据团队和项目的具体情况灵活调整
- 工程实践（CI/CD、自动化测试）比流程仪式更重要

### AI 时代的新挑战

敏捷的核心假设正在被 AI 动摇：

| 敏捷假设 | AI 时代的挑战 |
|----------|--------------|
| 需要跨职能团队 | AI 让一个人可以做全栈 |
| 结对编程提高质量 | 人机结对可能更高效 |
| 2 周 Sprint 是合理节奏 | AI 辅助下可能 2 天就够 |
| 用户故事是好的需求格式 | 自然语言 Prompt 可能更直接 |
| 估算帮助规划 | AI 可以辅助更精确的估算 |

## 2.7 本章小结

敏捷革命是软件工程史上最重要的变革之一。它将软件开发从僵化的计划驱动模式解放出来，转向以人为本、以价值为导向的开发方式。

但敏捷不是终点。正如敏捷宣言本身所倡导的——**响应变化高于遵循计划**——我们也需要对敏捷本身保持开放和批判的态度。在 AI 时代，很多敏捷实践需要重新审视和调整。

下一章，我们将看到 DevOps 如何进一步打破开发与运维之间的壁垒，以及云原生技术如何改变了软件的交付方式。

```{admonition} 思考题
:class: hint
1. 你的团队在实践敏捷时遇到了哪些困境？
2. 如果 AI 可以在 2 小时内完成一个 Sprint 的工作量，Sprint 还有意义吗？
3. 敏捷宣言的四条价值观在 AI 时代是否需要更新？
```