DarkM

# 敏捷开发模式

本文档介绍敏捷开发模式，适用于需求变化频繁、需要快速迭代的项目。

# 📋 什么是敏捷开发

敏捷开发（Agile Development） 是一种以人为核心、迭代、循序渐进的开发方法。它强调快速响应变化，持续交付有价值的软件。

# 敏捷宣言

个体和互动 > 流程和工具
工作的软件 > 详尽的文档
客户合作   > 合同谈判
响应变化   > 遵循计划
1
2
3
4

# 🔄 Scrum 框架

# 核心流程

graph LR
    A[产品 Backlog] --> B[Sprint 计划]
    B --> C[Sprint 开发]
    C --> D[Sprint 评审]
    D --> E[Sprint 回顾]
    E --> A
1
2
3
4
5
6

# 迭代周期

活动 频率 时长 参与者
Sprint 计划会 每迭代 1 次 2-4 小时 PO+ 团队
每日站会 每天 15 分钟 团队
Sprint 评审会 每迭代 1 次 1-2 小时 PO+ 团队 + 利益相关者
Sprint 回顾会 每迭代 1 次 1 小时 团队

# 👥 核心角色

# 产品负责人 (Product Owner)

职责：

  • 管理产品 Backlog
  • 确定需求优先级
  • 定义验收标准
  • 验收完成的功能

关键活动：

  • 需求收集和整理
  • 用户故事编写
  • 优先级排序
  • 迭代验收

# Scrum Master

职责：

  • 确保 Scrum 流程执行
  • 清除团队障碍
  • 保护团队免受干扰
  • 促进团队持续改进

关键活动：

  • 组织敏捷会议
  • 识别和清除障碍
  • 团队辅导和培训
  • 促进持续改进

# 开发团队

特点：

  • 跨职能（开发 + 测试 + 设计）
  • 自组织
  • 5-9 人为宜
  • 共同对迭代目标负责

职责：

  • 估算工作量
  • 承诺迭代目标
  • 完成开发任务
  • 保证交付质量

# 📝 核心工件

# 产品 Backlog

定义： 按优先级排序的需求列表

内容：

  • 功能需求
  • 缺陷修复
  • 技术债务
  • 改进建议

示例：

## 用户故事格式

作为 [角色]
我想要 [功能]
以便于 [价值]

验收标准：
1. [标准 1]
2. [标准 2]
3. [标准 3]
1
2
3
4
5
6
7
8
9
10

# Sprint Backlog

定义： 当前迭代承诺完成的任务列表

内容：

  • 从产品 Backlog 选择的用户故事
  • 任务分解
  • 工作量估算
  • 负责人分配

# 增量 (Increment)

定义： 迭代结束时完成的可交付功能

要求：

  • 完成定义（DoD）达标
  • 可演示
  • 可发布（如果需要）

# 📊 敏捷实践

# 用户故事

# 用户故事示例

## 故事标题：批量导入用户

### 故事描述
作为 系统管理员
我想要 批量导入用户功能
以便于 快速初始化用户数据

### 验收标准
- [ ] 支持 Excel 格式导入
- [ ] 单次最多导入 1000 条
- [ ] 导入失败显示详细错误信息
- [ ] 导入完成发送通知

### 估算点数：5

### 优先级：P1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 任务看板

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│  待办    │  进行中  │  代码审查 │  测试中  │  已完成  │
│  (WIP=5) │  (WIP=3) │  (WIP=2) │  (WIP=3) │          │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ 用户登录 │ 用户注册 │ 订单管理 │ 支付功能 │ 商品列表 │
│ 商品搜索 │ 购物车   │          │ 短信通知 │ 用户信息 │
│ 订单列表 │          │          │          │          │
└──────────┴──────────┴──────────┴──────────┴──────────┘
1
2
3
4
5
6
7
8

# 燃尽图

剩余工作量
  │
20│●
  │  ●
15│    ●
  │      ●
10│        ●
  │          ●
 5│            ●
  │              ●
 0└───────────────────────→ 时间
   D1 D2 D3 D4 D5 D6 D7 D8 D9 D10
1
2
3
4
5
6
7
8
9
10
11
12

# ✅ 优点

优点 说明
快速交付 每 2-4 周交付可用功能
灵活应变 欢迎需求变更
客户参与 客户全程参与，及时反馈
风险可控 早期暴露风险，快速调整
质量内建 持续测试，持续集成

# ❌ 缺点

缺点 说明
文档较少 可能影响知识传承
对团队要求高 需要自律和协作
客户参与度要求高 需要客户代表全程参与
范围不易控制 可能导致范围蔓延
不适合所有项目 安全关键系统需谨慎

# 📊 适用场景

场景 原因
需求不明确 如互联网产品、创新项目
快速市场响应 需要快速试错和迭代
客户可全程参与 客户代表可参与每个迭代评审
中小型项目 团队规模 5-15 人
SaaS/互联网产品 需要持续迭代优化

# 📝 最佳实践

# 1. 迭代计划

  • ✅ 选择合理数量的用户故事
  • ✅ 任务分解到 1-2 天
  • ✅ 团队共同承诺

# 2. 每日站会

  • ✅ 固定时间和地点
  • ✅ 控制在 15 分钟内
  • ✅ 聚焦三件事：昨天、今天、障碍

# 3. 持续集成

  • ✅ 每日多次提交代码
  • ✅ 自动化构建和测试
  • ✅ 快速反馈

# 4. 代码审查

  • ✅ 小批量审查
  • ✅ 及时反馈
  • ✅ 知识共享

# 5. 回顾改进

  • ✅ 坦诚开放
  • ✅ 聚焦改进
  • ✅ 落实行动项

# 🔗 相关文档

最后更新： 2022-12-15

← 方法论选择 →