背景与困惑
做软件开发这些年，我见过太多团队在敏捷转型中迷茫。超过70%的软件团队声称自己在用敏捷方法，但问起具体用什么框架，很多人说不清楚Scrum和Kanban有什么区别，更不知道Lean和XP该怎么选。
这篇文章是我对几种主流敏捷框架的梳理，基于实际项目中的观察和经验，帮你理清楚每种方法的特点和适用场景。
Scrum：结构化迭代管理
Scrum的核心设计
Scrum把开发切成固定长度的迭代，通常2-4周一个Sprint。每个Sprint都有明确的节奏：规划、开发、测试、评审，循环往复。
Scrum的几个关键概念：
| 术语 | 实际含义 |
|---|---|
| 用户故事 | 从用户角度写的需求，格式是”作为XX，我希望XX，以便XX” |
| Backlog | 需求池，按优先级排好序 |
| Sprint Backlog | 当前迭代要做的需求 |
| 燃尽图 | 看还剩多少工作没做完 |
| 速度 | 团队每轮Sprint能完成多少工作量 |
三个角色怎么分工
开发团队（3-9人）
人数控制在个位数是有道理的。人多了沟通成本指数级上升，站会会变成报告会。如果超过9人，建议拆成多个小团队。
团队要自组织，共同对交付负责，而不是”我负责前端，他负责后端”这种各管一摊的模式。
Scrum Master
这个角色最容易被误解。Scrum Master不是项目经理，更像是团队的”流程保镖”：
- 保证站会、评审会、回顾会按时开
- 帮团队扫清外部障碍
- 一个Scrum Master可以带2-3个团队
产品负责人（PO）
PO是业务方的代言人，对需求优先级有最终决定权。好的PO会写清晰的用户故事，会在Sprint结束时验收成果。
实施Scrum的几个坑
- Sprint周期换来换去 —— 团队刚适应节奏又变了，没有形成肌肉记忆
- “完成”的定义不统一 —— 开发说写完了，测试说还有Bug，PO说不符合预期
- 站会超时 —— 本来是15分钟的同步会，开成了1小时的讨论会
- 回顾会没产出 —— 大家抱怨了一堆，下周还是老样子
Kanban：可视化流动管理
Kanban从哪来
Kanban最初是丰田的生产管理工具，核心理念很简单：把工作可视化出来，限制同时进行的任务数量，让工作流程起来。
三个基本原则：
- 可视化 —— 用看板把工作状态展示出来，谁在看什么一目了然
- 限制在制品 —— 每个阶段同时进行的任务要设上限，防止堆积
- 管理流动 —— 关注任务从开始到完成的流动速度
Kanban vs Scrum 对比
| 对比点 | Kanban | Scrum |
|---|---|---|
| 工作方式 | 持续流动 | 固定迭代 |
| 需求变更 | 随时能改 | 只能在Sprint边界改 |
| 角色分工 | 没有固定角色 | 三个明确角色 |
| 会议要求 | 按需进行 | 固定仪式 |
| 适合场景 | 计划外工作多的团队 | 需求相对稳定的团队 |
| 度量指标 | 周期时间、吞吐量 | 速度、燃尽图 |
什么时候选Kanban
- 运维支持团队 —— Bug、紧急需求随时来，没法按固定节奏排
- 持续交付环境 —— 需要随时响应市场变化
- 需求变化频繁 —— 无法承诺固定Sprint
- 成熟团队 —— 已经理解敏捷原则，不需要严格的框架约束
Lean：消除浪费，最大化价值
Lean的核心思想
Lean从Kanban发展而来，但更进一步强调”消除浪费”。软件开发中的七种浪费：
- 部分完成的工作 —— 开发完了没测试、没上线的代码
- 额外流程 —— 不必要的文档、审批
- 多余功能 —— 用户其实不需要的功能
- 任务切换 —— 同时开多个任务，来回切换的上下文成本
- 等待 —— 等需求、等测试、等部署
- 移动 —— 信息在不同系统间倒腾
- 缺陷 —— Bug修复的返工成本
Lean和Kanban的区别
| 维度 | Lean | Kanban |
|---|---|---|
| 工程实践 | 更严格（TDD、持续集成） | 相对灵活 |
| 交付时间 | 团队随时准备部署 | 按看板流动 |
| 核心循环 | 构建-度量-学习 | 可视化-限制WIP-管理流动 |
适合什么样的团队
- 追求极致效率的成熟团队
- 希望深入实践DevOps的组织
- 需要快速验证市场假设的创业公司
XP：工程实践驱动
XP不只是结对编程
很多人以为XP就是两个人共用一台电脑写代码，其实XP是一套完整的工程实践体系。
XP的12个实践：
- 计划游戏 —— 业务和技术一起估算、一起计划
- 测试驱动开发（TDD） —— 先写测试，再写实现
- 结对编程 —— 两个人一起写代码
- 现场客户 —— 客户常驻团队，随时回答问题
- 持续集成 —— 频繁提交代码到主干
- 重构 —— 持续改进代码设计
- 小版本发布 —— 频繁发布小版本
- 编码标准 —— 统一的代码风格
- 集体代码所有权 —— 任何人可以修改任何代码
- 简单设计 —— 只实现当前需要的功能
- 系统隐喻 —— 用大家都能理解的词汇描述系统
- 可持续节奏 —— 保持可长期维持的工作强度
XP对代码质量的提升
- TDD让Bug率降低40-90%
- 结对编程让知识在团队里传播
- 持续集成把集成问题发现时间从天缩短到小时
- 重构让代码库保持健康
XP实施的难点
- 文化阻力 —— 结对编程需要开发者克服心理障碍
- 客户配合 —— 需要客户深度参与开发过程
- 技能要求 —— TDD和重构需要较高的技术能力
- 初期效率下降 —— 新实践需要学习曲线
框架选择建议
简单的选择矩阵
| 团队情况 | 推荐框架 | 理由 |
|---|---|---|
| 初创团队，需求不明确 | Lean | 强调快速学习和验证 |
| 成熟产品，稳定迭代 | Scrum | 结构化框架，易于管理 |
| 运维/支持团队 | Kanban | 灵活响应计划外工作 |
| 追求代码质量 | XP | 工程实践最完善 |
| 大型企业转型 | Scrum + Kanban | 结构化与灵活性结合 |
Scrumban：混合使用
实际项目中，很多团队用”Scrumban”模式：
- 保留Scrum的Sprint节奏
- 使用Kanban的可视化看板
- 取消一些过于严格的Scrum仪式
- 保持WIP限制防止任务堆积
敏捷转型的常见坑
- 形式主义 —— 只学仪式，不理解背后的原则
- 忽视工程实践 —— 只改流程，不改代码质量
- 急于求成 —— 期望立即见效，忽视学习曲线
- 一刀切 —— 不同团队用相同方法，忽视团队差异
- 不度量 —— 没有数据支撑持续改进
敏捷成功的关键
管理层的支持
敏捷转型需要管理层的理解：
- 接受短期效率下降
- 授权团队自组织
- 移除组织层面的障碍
- 提供培训和指导资源
团队文化建设
敏捷不仅是流程，更是文化：
- 信任与透明 —— 信息透明，建立信任
- 持续学习 —— 从失败中学习，持续改进
- 客户导向 —— 始终关注客户价值
- 协作精神 —— 跨职能协作，共同成功
建立度量体系
- 交付周期 —— 需求从提出到上线的时间
- 部署频率 —— 多久发布一次
- 变更失败率 —— 发布后出现问题的比例
- 恢复时间 —— 出现问题后恢复服务的时间
写在最后
敏捷开发不是银弹。我见过太多团队盲目追求”敏捷”，结果陷入了更混乱的局面。
Scrum适合需要结构化管理的团队，提供了清晰的节奏和角色分工。Kanban适合工作流动态变化的团队，强调可视化和流程优化。Lean适合追求极致效率的成熟团队，注重消除浪费。XP适合重视代码质量的团队，提供了最完善的工程实践。
大多数成功的团队会根据自身情况混合使用这些方法，形成适合自己的”敏捷”。重要的是理解敏捷宣言背后的价值观：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。
最后分享一句话：敏捷是一种旅程，不是目的地。 持续改进，永无止境。