一、敏捷开发概述

大家好，我是你们的讲师。今天咱们聊聊敏捷开发。说实话，我刚入行那会儿，敏捷还是个新鲜词。那时候大家还在用瀑布模型，一个项目做半年，需求文档能堆半人高。后来我慢慢发现，这种模式在快速变化的市场里，真的有点跟不上节奏。

敏捷开发，说白了就是一种应对变化的能力。它不是一套死板的流程，而是一种思维方式。我个人的理解是：与其花三个月做一份完美的计划，不如花两周做出一个能跑的原型，然后根据反馈不断调整。

1.1 敏捷宣言

2001年，17位软件行业的大佬聚在美国犹他州的一个滑雪场。他们聊着聊着，发现大家其实都在做类似的事情——试图找到一种更轻量、更灵活的软件开发方式。于是，敏捷宣言诞生了。

宣言的核心就四句话：

• 个体和互动 高于 流程和工具
• 可工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

注意，这里说的是「高于」，不是「代替」。流程和工具依然重要，但人更重要。我在项目中遇到过很多次，团队把流程定得死死的，结果出了问题没人敢变通。嗯，这其实就违背了敏捷的初衷。

1.2 敏捷原则

光有宣言还不够，得有具体的行为准则。敏捷联盟总结了12条原则，我挑几个重点说说：

1. 尽早、持续地交付有价值的软件 —— 别等到最后才给客户看，两周一次甚至更频繁。
2. 欢迎需求变化 —— 即使是在开发后期。你想想看，客户自己可能都不知道想要什么，变化是常态。
3. 业务人员和开发人员每天一起工作 —— 我曾经见过一个项目，业务和开发隔着一堵墙，沟通全靠邮件。结果呢？做出来的东西根本不是客户要的。
4. 面对面沟通 —— 这是最有效的传递信息的方式。能当面聊就别发邮件，能视频就别打字。
5. 可持续的开发速度 —— 别搞996，长期加班只会让代码质量越来越差。

1.3 Scrum框架介绍

Scrum是目前最流行的敏捷框架。它不复杂，但很多人用错了。我见过不少团队，把Scrum当成「每天站会+两周迭代」，然后就觉得自己敏捷了。其实远不止这些。

Scrum的核心角色有三个：

角色	职责	我的一点观察
产品负责人（PO）	定义需求、排优先级、确保团队做正确的事	这个角色最难当。既要懂业务，又要懂技术，还得会沟通。我见过最差的PO，直接把需求文档扔给团队就不管了。
Scrum Master	确保流程顺畅、移除障碍、教练团队	不是项目经理！不是项目经理！不是项目经理！重要的事情说三遍。Scrum Master是服务型领导，不是发号施令的。
开发团队	自组织、跨职能、交付可工作的软件	团队一般5-9人。人太少做不了复杂的事，人太多沟通成本就上去了。

Scrum的事件也很关键：

• Sprint（迭代）：通常2-4周，固定时间盒。
• Sprint计划会：确定这个迭代要做什么，怎么做。
• 每日站会：15分钟，回答三个问题——昨天做了什么？今天打算做什么？有什么阻碍？
• Sprint评审会：给PO和干系人演示成果，收集反馈。
• Sprint回顾会：团队内部复盘，哪些做得好，哪些需要改进。

1.4 看板方法介绍

看板方法比Scrum更轻量。它源自丰田的生产系统，后来被David Anderson引入到软件开发中。说白了，看板就是一块板子，上面贴着各种任务卡片，从左到右流动。

看板的核心原则：

1. 可视化工作流 —— 把「待办」、「进行中」、「已完成」这些列画出来，每张卡片代表一个任务。
2. 限制在制品（WIP） —— 这是最关键的一点。每个「进行中」的列最多只能有3-5张卡片。为什么？因为同时做太多事，反而什么都做不好。
3. 管理流动 —— 关注任务从开始到结束的时间，想办法缩短它。
4. 明确流程规则 —— 比如「测试通过才能移到已完成列」。
5. 持续改进 —— 定期回顾，调整流程。

我个人习惯把看板和Scrum结合起来用。比如在Sprint里，用看板来跟踪每天的进度。这样既有迭代的节奏感，又有可视化的透明度。

看板和Scrum最大的区别是什么？

• Scrum有固定的迭代周期，看板是持续流动的。
• Scrum有明确的角色（PO、SM），看板没有强制角色。
• Scrum更适合产品开发，看板更适合运维、支持类工作。

但说实话，在实际项目中，两者经常混用。你不需要纠结「我到底该用Scrum还是看板」，而是问自己：「我的团队现在最需要解决什么问题？」

好了，这一章的内容就到这里。下一章我们会深入聊聊Scrum的实践细节，包括怎么开好计划会、怎么估算工作量。到时候我会分享一些我踩过的坑，希望对你有帮助。