敏捷开发入门：Scrum框架完全解读

从瀑布到敏捷：为什么需要 Scrum

软件开发早期普遍采用瀑布模型。需求先冻结，再依次经过设计、开发、测试、上线。这个模式在需求稳定时有效。可现实里，需求几乎一直在变：市场在变，用户在变，技术栈也在变。

等产品上线时，当初的需求可能已经过时。团队忙了几个月，交付的却不是用户真正要的东西。这正是瀑布模型的核心矛盾。

2001 年，17 位软件工程专家发布了《敏捷宣言》，提出四个价值观：个体和互动高于流程和工具，可工作的软件高于详尽的文档，客户协作高于合同谈判，响应变化高于遵循计划。敏捷开发由此成为软件行业的共识。

Scrum 就是敏捷开发中应用十分广泛的框架。它不承诺一次规划到位，而是把工作切分成短周期，每个周期结束都交付可用成果，再用反馈调整方向。对刚接触敏捷开发的团队来说，Scrum 框架往往是比较容易上手的起点。

Scrum 是什么：框架，不是方法论

Scrum 是一个轻量级框架，帮助团队在复杂环境中持续创造价值。这里要区分一个概念：Scrum 是框架，不是方法论。

方法论会告诉你每一步怎么做。框架只提供结构：谁来做什么、有哪些工件、按什么节奏检视。至于代码怎么写、测试怎么跑、发布流程怎么设计，Scrum 都不规定，由团队自己决定。

Scrum 的底层逻辑是经验主义，包含三个支柱：

• 透明：过程和结果对所有人可见，不藏问题
• 检视：定期检查工件和进展，及早发现偏差
• 适应：发现偏差后及时调整，而不是硬扛到结束

围绕这三个支柱，Scrum 框架用一套固定结构运转：三个角色、三个工件、五个事件、五个价值观。下面逐一展开。

Scrum 团队：三个角色

Scrum 团队由产品负责人、Scrum Master、开发者三类角色组成，团队通常控制在 10 人以内，共同围绕一个产品目标协作。

产品负责人

产品负责人（Product Owner）负责"做什么"和"先做什么"。他维护产品待办列表，排定需求优先级，确保团队始终在处理更有价值的事。

产品负责人是一个人，不是一个委员会。需求优先级如果被销售、客户、老板多方拉扯，团队就会失去焦点。产品负责人的存在，就是为组织建立一个清晰的价值排序接口。

Scrum Master

Scrum Master 常被误当成会议主持人或轻量级项目经理。实际上，他的职责是帮助团队正确理解和应用 Scrum，提升团队有效性。

Scrum Master 服务产品负责人、服务开发者、也服务整个组织：促进团队自管理、帮助移除障碍、推动事件有效运转。真正的问题往往不是"会不会开会"，而是团队有没有形成有效的运转机制。

开发者

开发者（Developers）是团队中负责交付增量的人。他们承诺完成 Sprint 目标，自己拆任务、定技术方案、控制质量。

开发者不区分前后端和测试，只要有完成工作所需的技能，都可以参与。Scrum 里的团队是自管理的：谁来做什么，团队内部自己决定，而不是靠项目经理分配。

Scrum 工件：三个待办与增量

工件是支撑检视和透明的信息载体。Scrum 框架定义了三个工件。

产品待办列表

产品待办列表（Product Backlog）是按价值排序的需求清单。所有要做的事都放进这里，由产品负责人维护。它不是一次列全的，而是随信息增加持续细化。

Sprint 待办列表

Sprint 待办列表（Sprint Backlog）是当前 Sprint 要完成的条目，以及为实现这些条目拆出的任务。它由团队在 Sprint 计划会上确定，是团队当前周期的任务清单。

产品增量

每个 Sprint 结束时，团队交付一个可用的增量（Increment）。增量是可部署的成果，可以给用户用，也可以集成进产品。增量不是"部分完成的功能"，而是达到完成定义的标准。

完成定义

完成定义（Definition of Done，DoD）是团队约定的"完成"标准。它回答了"做到什么程度才算做完"，避免"开发说完了、测试说没完"的扯皮。DoD 由团队共同维护，标准越清晰，透明度越高。

Scrum 事件：五个仪式

Scrum 用五个固定事件建立节奏，所有事件都有时间盒（timebox），到点就停。

Sprint

Sprint 也叫冲刺，是 Scrum 的基本迭代单位，通常 1-4 周，期间长度固定。Sprint 一结束就马上开始下一个，中间不插队、不打断。新需求再急，也放进下一个 Sprint。

Sprint 计划会

每个 Sprint 开始前开计划会。团队和产品负责人一起确定 Sprint 目标，从产品待办列表挑出本次要做的条目，再拆成任务。会议输出 Sprint 待办列表。

每日站会

每日站会（Daily Scrum）是团队每天进行的检视活动，时间盒固定为 15 分钟。它的作用不是向谁汇报进度，而是检查团队距 Sprint 目标的进展，并据此调整当天的工作安排、优化协作。新版 Scrum 指南已不再强制套用固定的三个问题，团队可以围绕 Sprint 目标自行组织讨论。会议结束时，团队应形成一份当天剩余工作的清晰计划。站会本身不负责解决问题，暴露出来的障碍在会后另行处理。

Sprint 评审会

Sprint 结束时开评审会，团队向干系人演示完成的功能，收集反馈。评审会关注的是"做出来的东西对不对"，由此调整产品待办列表。

Sprint 回顾会

最后是回顾会，团队检视自身工作方式：哪些地方做得好、哪些要改进，并确定下一个 Sprint 的改进项。这是团队持续改进的机制。

五大价值观与适用边界

Scrum 的五个价值观是：承诺、专注、开放、尊重、勇气。价值观不是口号，而是支撑框架运转的行为准则。比如，每日站会上敢把问题摆上台面，靠的是"开放"和"勇气"。

Scrum 不是万能的。它适合需求不确定、需要快速试错的产品研发。如果需求非常稳定、且由外部合同严格约束交付物，预测型方法可能更合适。判断标准不是"哪个先进"，而是"哪个适合你的场景"。

常见误区有三个：一是把 Scrum 当成银弹，以为换流程就能解决所有问题；二是只开会不落地，站会照开，工作方式没变；三是角色没分清，产品负责人缺位，Scrum Master 当项目经理用。这些都会让 Scrum 流于形式。

用工具支撑落地

框架讲完，落地才是关键。Scrum 依赖透明和持续检视。如果需求、任务、Bug 散落在聊天记录和表格里，透明就无从谈起，几个仪式也容易变成走过场。

所以多数团队会把信息放进项目管理工具里。以禅道这类国内团队常用的工具为例：需求有单独的列表，可以排优先级，对应产品待办列表；需求进入迭代后拆成任务，形成 Sprint 待办列表；用例和 Bug 有明确的状态，承担质量闭环。角色和工件有了落点，站会和评审会就不需要靠记忆对账。

敏捷开发落地靠的不是工具本身，它只是把过程记录下来，让检视和适应有据可依。选工具时也不用追求功能多，关键是需求、任务、Bug 的信息流是否清晰。

给你的第一个 Sprint：行动清单

看完这篇敏捷开发入门，如果想让 Scrum 框架真正跑起来，可以从下面几步开始：

• 明确一个产品负责人，让他维护产品待办列表，排好优先级
• 任命或培训一名 Scrum Master，负责守流程、清障碍
• 组建不超过 10 人的跨职能团队，确认一个共同的 Sprint 目标
• 定下 Sprint 周期（建议从 2 周开始）和完成定义
• 开好第一次 Sprint 计划会，把需求拆成可执行的任务
• 每天固定时间开 15 分钟站会，把障碍摆上台面
• Sprint 结束时做评审和回顾，用反馈驱动下一个迭代

Scrum 框架的核心不是仪式本身，而是通过短周期的透明、检视、适应，让团队持续交付真正的价值。把需求、任务、Bug 的信息流管好，你的敏捷开发实践会更容易坚持下来。