Scrum 敏捷开发：角色、会议与工件
什么是Scrum？一个为敏捷而生的框架
在开始深入角色、会议与工件之前，有必要先理解 Scrum 的本质。Scrum 是一个轻量级、迭代增量的敏捷框架，用于管理复杂产品的开发。它不是具体的工作流程，而是一套规则、角色和仪式，帮助团队围绕共同目标进行协作，并在不断变化的环境中持续交付价值。
Scrum 基于经验过程控制理论，依靠透明度、检视和适应三大支柱。这意味着团队不会试图在项目开始前规划一切，而是通过短周期的开发（称为Sprint）频繁交付可工作的产品增量，并通过定期检查和调整来优化方向。
Scrum的三大角色：谁在做什么
Scrum 团队是一个自组织、跨职能的群体，由三个明确定义的角色组成。没有子团队，没有层级，只有平等的、各司其职的成员。
产品负责人 (Product Owner)
产品负责人是价值的最大化者。他负责定义产品愿景，管理产品待办列表（Product Backlog），并对列表中条目的优先级有最终决定权。产品负责人的核心职责是将利益相关者的需求转化为可执行的条目，并确保团队始终在做最有价值的事情。
一个好的产品负责人不是“需求传递者”，而是需要深入理解用户和业务，能够持续细化需求，并为团队解答疑问。他需要确保待办列表的条目清晰可见、便于理解，并按照对业务的价值排序。注意：产品负责人是一个人，而不是一个委员会，这样才能保证决策速度与问责的清晰。
Scrum Master
Scrum Master 是 Scrum 的守护者和服务型领导者。他不直接管理团队，而是通过引导、教练和辅导帮助团队和组织理解并实践 Scrum 理论、规则和价值观。
Scrum Master 的三项主要服务对象是：团队、产品负责人和组织。
- 为团队服务：消除遇到的障碍，促进自组织，指导团队创造高价值增量。
- 为产品负责人服务：帮助找到有效的待办列表管理技巧，与团队沟通产品愿景，支持需求的切分与优先级。
- 为组织服务：在更大范围内推广 Scrum 经验，推动改变那些妨碍敏捷性的结构和流程。
关键认知：Scrum Master 不是项目经理，也不是团队的“上级”。他的权力来源于影响力，目标是帮助团队在不需要他的那一天依然能够高效运作。
开发团队 (Development Team)
开发团队是实际交付产品增量的专业角色集合。他们拥有所有必要的技能来完成每个 Sprint 的工作，并集体为成果负责。开发团队是跨职能的，意味着团队内部具备设计、编码、测试、文档编写等所有能力，不需要依赖外部团队来完成交付。
开发团队的数量建议控制在 3 到 9 人之间（不包括产品负责人和 Scrum Master，除非他们也参与执行工作）。这个规模保证了充分的沟通和足够的技能覆盖。团队自组织决定如何完成工作，没有外部人员告诉他们应该如何将待办列表转化为可交付的功能。责任是共有的：整个团队对 Sprint 目标的达成负责，而不是个别成员只对自己那块工作负责。
Scrum的五个核心会议：有节奏的协作
Scrum 通过固定时间盒的会议来创造节奏、确保透明，并提供正式的检视和适应机会。这五个活动构成了 Sprint 的心脏。
Sprint 规划会议 (Sprint Planning)
每个 Sprint 都以规划会议开始。这是一个时间盒为 8 小时（针对一个月长度的 Sprint，短 Sprint 则等比例缩短）的活动。在这个会议中，整个 Scrum 团队共同合作，回答两个核心问题：
- 本次 Sprint 可以交付什么增量？
- 这些工作将如何完成？
产品负责人负责解释 Sprint 的目标和最高优先级的待办列表条目，团队则评估他们在这个 Sprint 中能够完成多少工作。最终，团队会产出 Sprint 目标，这是一句简短的说明，描述 Sprint 要达成的业务目标。同时，团队会分解出一批选定的待办条目，形成初步的交付计划（称为 Sprint Backlog），并明确一旦遇到范围冲突时，将以目标为指导做出取舍。
每日站会 (Daily Scrum)
每日站会是开发团队内部的 15 分钟时间盒会议，每天在同一时间同一地点举行。它的核心目的是同步进度、暴露障碍，并规划接下来 24 小时的工作，而不是向管理层做状态报告。
经典的三个问题是：
- 昨天我为达成 Sprint 目标做了什么？
- 今天我将做什么来帮助达成 Sprint 目标？
- 我是否看到任何阻碍我或团队达成 Sprint 目标的障碍？
Scrum Master 确保会议发生并保持在时间限制内，但会议由开发团队主导。关键不在于给出详细的任务报告，而在于团队对目标进展形成共同理解，并迅速识别需要协作解决的障碍。
Sprint 评审会议 (Sprint Review)
Sprint 评审是在 Sprint 结束时举行的非正式会议，时间盒通常为 4 小时（针对一个月时长 Sprint）。其目的不是审批或质疑团队，而是检视 Sprint 产生的增量，并根据反馈适应产品待办列表。
参与者包括 Scrum 团队和被产品负责人邀请的主要利益相关者。团队演示他们完成的工作，产品负责人说明哪些条目已经“完成”和哪些没有。然后整个小组讨论当前的状况、市场变化以及下一步最值得做的事情。输出是一个可能被修订的产品待办列表，它反映了最新的理解。
Sprint 回顾会议 (Sprint Retrospective)
如果说评审关注的是“产品”，那么回顾关注的就是“过程”。回顾会议是 Scrum 团队检视自身工作方式的机会，时间盒通常为 3 小时（针对一个月时长 Sprint）。会议目标是找出哪些地方做得好、哪些地方可以改进，并制定具体的改进行动计划。
团队讨论过程、工具、人际关系、团队协作等方面。常用的结构有“开始-停止-继续”、“帆船模型”等引导方法。最重要的是，回顾会议必须产生至少一个可执行的改进行动，并将其落实到下一个 Sprint 的工作方式中。持续改进是 Scrum 的核心引擎。
待办列表梳理 (Product Backlog Refinement) —— 持续发生的工作
虽然 Scrum 指南没有将其列为一个独立事件，但待办列表梳理是持续进行的关键活动。它发生在 Sprint 期间，包括详细化需求、拆分大条目、补充验收标准、以及重新排序。团队通常预留不超过 Sprint 总容量 10% 的时间来进行梳理。这确保了未来几个 Sprint 的待办列表条目已足够清晰，并为持续的知识获取留出空间。
Scrum的三大工件：透明度的载体
Scrum 工件代表工作或价值，旨在最大化关键信息的透明度，让每个人都拥有相同的信息基础来做决策。
产品待办列表 (Product Backlog)
产品待办列表是产品需要的所有东西的有序列表，是需求变更的唯一来源。它包含功能、缺陷修复、技术工作、知识获取等所有可能对产品有价值的事物。产品负责人负责其内容、可用性和优先级。
待办列表是动态的，随着产品、用户和市场的理解不断演进。位于顶部的条目更小、更清晰、更详细，越往下则越模糊和粗略，这是“逐渐明晰”的原则。一个好的待办列表让团队能够持续拣选最有价值的条目来工作。
Sprint 待办列表 (Sprint Backlog)
Sprint 待办列表是团队在当前 Sprint 内计划完成的工作集合，加上一个用以达成 Sprint 目标的计划。它使得团队承诺要交付的工作变得可见，并通常采用任务板的形式进行可视化。团队在整个 Sprint 中拥有完全所有权，可以根据实际情况自主添加、删除或修改任务（只要不危笃 Sprint 目标）。每日剩余的预估工作量应该持续被追踪，通常使用燃尽图来直观展现进度。
增量 (Increment)
增量是 Sprint 结束时所有已完成的待办列表条目的总和，它必须符合团队“完成”(Done) 的定义。“完成”是一个共享的、透明的质量标准。每个新的增量必须集成之前所有的增量，并经过全面测试，确保所有部分协同工作。增量必须是可用的，不管产品负责人是否决定实际发布它。未达到“完成”标准的工作不能视作增量，也不能在评审中演示。增量的存在让团队能够频繁获得真实反馈。
如何开始你的第一个Sprint？
理解了角色、会议和工件，剩下的就是实践。作为初学者，可以从下面几步入手：
- 组建跨职能的团队，明确产品负责人和 Scrum Master。
- 创建初始产品待办列表，即使它还很粗糙。
- 定义一个 Sprint 长度（建议 2 周，适合初期）。
- 召开首次 Sprint 规划会议，拉取少量由团队评估过的条目，形成明确的 Sprint 目标。
- 在整个 Sprint 中严格遵守每日站会节奏，让障碍可见。
- 在 Sprint 结束时，邀请利益相关者进行非正式的评审，然后立刻进行坦诚的回顾。
- 让下一个 Sprint 迭代这些经验。
Scrum 没有银弹，但它提供了一套结构化的实验框架。真正的威力来自于团队对“检视与适应”的彻底执行，以及组织文化的支持。先跑起来，再不断改进，这就是 Scrum 之道。