第二章：敏捷革命 — 从计划驱动到价值驱动

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

        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），提出了四条核心价值观和十二条原则。

四条核心价值观#

我们更看重

胜过

虽然右边也有价值

个体和互动

流程和工具

工作的软件

详尽的文档

客户合作

合同谈判

响应变化

遵循计划

十二条原则（精选）#

  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 原则：好的用户故事应该是：

  • Independent（独立的）

  • Negotiable（可协商的）

  • Valuable（有价值的）

  • Estimable（可估算的）

  • Small（小的）

  • Testable（可测试的）

估算方法#

故事点（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 推广，核心理念是频繁地将代码集成到主干：

# 一个典型的 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 如何进一步打破开发与运维之间的壁垒，以及云原生技术如何改变了软件的交付方式。

思考题

  1. 你的团队在实践敏捷时遇到了哪些困境？

  2. 如果 AI 可以在 2 小时内完成一个 Sprint 的工作量，Sprint 还有意义吗？

  3. 敏捷宣言的四条价值观在 AI 时代是否需要更新？

目录