敏捷与 Scrum 基础

第 25 章 · 软件工程

一、敏捷宣言与原则

敏捷宣言（Agile Manifesto）提出四个价值偏好：个体与互动高于流程与工具、可工作的软件高于详尽的文档、客户协作高于合同谈判、响应变化高于遵循计划。不是说右边不重要，而是左边更优先。背后还有十二条原则：尽早持续交付、欢迎需求变更、短周期交付、业务与开发每日协作、激励个人、面对面沟通、可工作的软件是进度度量、可持续节奏、技术卓越与好设计、简洁、自组织团队、定期反思与调整。这些共同指向「小步快跑、频繁反馈、持续改进」。

二、Scrum 框架：角色、事件、工件

Scrum 用少量角色、事件和工件把迭代固定下来，便于团队形成节奏。

角色：Product Owner（PO）——对产品待办事项负责，排优先级、澄清需求；Scrum Master（SM）——服务团队与流程，移除障碍、促进 Scrum 落地；Development Team——跨职能开发团队，共同交付增量。没有「项目经理」单点指挥，而是 PO 管「做什么」、团队管「怎么做」、SM 管「流程顺不顺」。

事件：Sprint——固定时长（如 2 周）的迭代，期内目标不变；Sprint Planning——规划本 Sprint 要做什么；Daily Scrum（Standup）——每日短会，同步进度与障碍；Sprint Review——展示本 Sprint 成果、收集反馈；Sprint Retrospective——回顾过程，改进下一轮。

工件：Product Backlog——产品待办列表，按优先级排序；Sprint Backlog——本 Sprint 承诺要完成的事项；Increment——Sprint 结束时的可交付增量（可工作、可发布）。

三、Sprint、Backlog、Daily Standup、回顾

Sprint 是 Scrum 的心跳：固定长度（通常 1～4 周），期内目标与范围锁定，不随意加需求；若必须加，则与 PO 协商替换或延后其他项。Sprint 结束产出Increment（可交付、可演示）。Product Backlog 由 PO 维护，条目用用户故事或需求描述，按价值与依赖排序；Sprint Backlog 是团队在本 Sprint 选中的条目，拆成可执行任务。Daily Standup（每日站会）时间盒（如 15 分钟），每人简短说：昨天做了什么、今天做什么、有什么阻碍；不展开讨论，阻塞会后跟进。Sprint Retrospective（回顾）在 Sprint 结束后做：什么做得好、什么要改进、下个 Sprint 试什么行动，让过程持续进化。

四、敏捷不是无计划

敏捷强调响应变化，不等于「不要计划」。而是计划缩短周期、频繁更新：有 Sprint 计划、发布规划、路线图，但不会一次性把半年细节锁死；根据反馈调整优先级与范围。Backlog 本身就是「计划」的活文档；估算与速度（下一章会讲）用来做预测与承诺。误解「敏捷 = 无计划」会导致需求永远在变、谁都能插单、团队疲于应付；正确做法是「有计划、有节奏、有变更机制」——PO 管优先级，Sprint 内尽量不插单，变更通过 Backlog 与规划纳入。

五、小结

敏捷宣言四组价值与十二条原则，指向小步交付与持续改进。Scrum：角色（PO、SM、Dev Team）、事件（Sprint、Planning、Daily、Review、Retro）、工件（Product Backlog、Sprint Backlog、Increment）。Sprint 固定时长、Backlog 驱动选择、Daily 同步、回顾改进过程。敏捷不是无计划，而是计划短周期、可调整、有变更机制。下一章讲看板与精益思想，另一种可视化与流动的协作方式。