3、敏捷开发核心概念：Scrum框架、看板方法、极限编程，以及它们如何提升交付效率
聊到敏捷开发，很多朋友第一反应就是「Scrum」。其实敏捷是个大家族，Scrum、看板、极限编程（XP）是其中三个最主流的流派。它们各有侧重，但目标一致——让软件交付更快、更稳、更灵活。
我个人习惯把这三种方法比作「三把刀」：Scrum是切分时间的刀，看板是可视化流程的刀，XP是打磨代码质量的刀。你想想看，如果三把刀配合使用，效果绝对1+1+1>3。
3.1 Scrum框架：时间盒里的节奏感
Scrum的核心思想，就是把开发过程切成一个个固定长度的时间盒——Sprint。每个Sprint通常2到4周，团队在这个周期内完成一个可交付的增量。
我在项目中遇到过不少团队，一开始对Sprint计划会特别抵触，觉得「计划赶不上变化」。但跑过两三个Sprint后，大家会发现：有了节奏感，反而更从容。
Scrum的三大角色：
- 产品负责人（PO）：负责定义需求优先级，说白了就是「决定做什么」
- Scrum Master：流程守护者，帮团队扫清障碍，不是「项目经理」
- 开发团队：自组织的执行者，通常5-9人
Scrum的五个事件，我建议你记牢：
- Sprint计划会：确定本轮要完成哪些用户故事
- 每日站会：15分钟，回答三个问题——昨天做了什么、今天做什么、有什么阻碍
- Sprint评审会：展示成果，收集反馈
- Sprint回顾会：复盘过程，找出改进点
- 待办事项梳理：持续优化Backlog
我的经验：每日站会最容易变成「汇报会」。我曾经带过一个团队，站会能开40分钟。后来我强制要求：站会只讲阻碍，不讨论解决方案。讨论留到会后，效率立刻翻倍。
3.2 看板方法：让工作流可视化
看板方法起源于丰田的「精益生产」，后来被David Anderson引入软件开发。它的核心就四个字：可视化流程。
你想想看，一个看板通常分几列：待办、进行中、测试中、已完成。每张卡片代表一个任务。团队每天看一眼看板，就知道哪里堵住了。
看板方法有几个关键原则：
- 限制在制品（WIP）：每个状态列的任务数量有上限，防止「多任务并行」导致的效率低下
- 管理流动：关注任务从「待办」到「完成」的周期时间
- 明确流程规则：比如「测试中」的任务必须通过代码审查才能进入「已完成」
- 持续改进：通过度量数据找到瓶颈
避坑指南：我曾经见过一个团队，看板上贴了50多张卡片，WIP限制形同虚设。结果呢？每张卡片的平均完成时间从3天拖到了2周。记住：看板不是「任务墙」，它是「流动管理系统」。WIP限制必须严格执行。
看板方法特别适合运维团队或支持类工作，因为这类工作往往有突发性，不适合固定Sprint。说白了，Scrum是「时间驱动」，看板是「事件驱动」。
3.3 极限编程（XP）：把代码质量做到极致
极限编程（XP）是Kent Beck在90年代末提出的。它的名字很形象——把好的实践做到「极限」。比如代码审查好，那就做结对编程；测试重要，那就写测试驱动开发（TDD）。
XP的核心实践包括：
| 实践 | 说明 | 我的体会 |
|---|---|---|
| 结对编程 | 两人共用一台电脑，一人写代码，一人审查 | 刚开始觉得效率低，但Bug率下降明显 |
| 测试驱动开发 | 先写测试，再写实现代码 | 强制你思考接口设计，代码更清晰 |
| 持续集成 | 每天多次合并代码到主干 | 避免「集成地狱」，我吃过这个亏 |
| 简单设计 | 只做当前需要的，不做过度设计 | 「你不需要它」是XP的名言 |
| 重构 | 持续改进代码结构，不改变外部行为 | 代码像花园，不修剪就会荒废 |
XP的价值观：沟通、简单、反馈、勇气、尊重。这五个词，我每次带团队都会贴在墙上。尤其是「勇气」——敢于重构、敢于删除无用代码、敢于说「不」。
3.4 三者如何提升交付效率？
好了，三个框架都讲完了。那它们到底怎么提升效率？我总结三点：
第一，减少浪费。Scrum通过Sprint评审和回顾，快速发现方向错误；看板通过WIP限制，减少多任务切换的损耗；XP通过TDD和持续集成，减少返工。说白了，都是「少做无用功」。
第二，加速反馈。Scrum每2-4周就有一次评审，客户能及时看到成果；看板让团队每天都能看到工作流状态；XP的结对编程和TDD，让代码问题在几分钟内被发现。反馈越快，纠错成本越低。
第三，提升可预测性。Scrum的Sprint节奏让团队能估算出「每个周期能交付多少」；看板的周期时间度量让团队能预测「一个任务多久能完成」；XP的持续集成让「发布」不再是高风险事件。
我的建议：不要试图一次性引入所有实践。我曾经带过一个ASPICE Level 2的项目，团队一开始就搞Scrum+XP+看板，结果两周就崩了——太复杂。我的做法是：先跑Scrum，稳定节奏；然后引入看板可视化流程；最后用XP提升代码质量。循序渐进，团队更容易接受。
嗯，这里要注意一点：ASPICE和敏捷并不冲突。ASPICE关注「过程证据」，敏捷关注「交付价值」。你完全可以在ASPICE的框架下跑Scrum，只要把Sprint计划会、评审会等事件产生的文档保留好，就能同时满足两者的要求。这个我们后面章节会详细讲。