Scrum框架入门：三个角色、三件工件、五个事件
聊到敏捷开发，Scrum是绕不开的话题。我在量化团队推行敏捷时，发现很多人把Scrum理解成「每天开个站会」——这其实是个误区。Scrum真正的核心，是三个角色、三件工件、五个事件组成的闭环。说白了，它是一套让团队持续交付价值的机制。
今天我就结合自己在因子工厂项目中的实践，把这套框架拆开揉碎了讲给你听。
一、Scrum的三个角色
角色定义清楚了，责任边界就清晰了。我见过太多团队扯皮，根源就是角色职责模糊。
1. Product Owner（产品负责人）
PO的核心职责就一句话：确保团队做正确的事。
我个人习惯把PO比作「产品价值的守护者」。他负责管理Product Backlog，决定需求的优先级。注意，PO不是项目经理，他不指挥团队怎么干活，而是告诉团队「做什么」和「为什么做」。
PO的关键职责：
- 定义产品愿景和路线图
- 维护Product Backlog，确保条目清晰、优先级明确
- 在Sprint Planning中解释需求，回答团队疑问
- 验收完成的功能，确认是否达到「完成定义」
我在项目中遇到过一位PO，他把所有需求一股脑塞进Backlog，连优先级都不排。结果团队每次Sprint Planning都要花半天时间讨论「先做哪个」。后来我建议他每周花两小时梳理Backlog，把Top 10的需求排好序，效率提升了一大截。
2. Scrum Master（敏捷教练）
Scrum Master不是「团队领导」，而是「服务型领导」。这个角色经常被误解——有人觉得Scrum Master就是开会主持人，也有人觉得这是个闲职。
其实Scrum Master的核心工作是消除障碍。团队遇到流程阻塞、资源冲突、外部依赖等问题，Scrum Master要负责搞定。
避坑指南：我曾经见过一个Scrum Master，每天忙着帮团队写代码、改Bug。结果团队越来越依赖他，自己反而失去了解决问题的能力。记住，Scrum Master的职责是让团队自组织，不是替团队干活。
3. 开发团队
开发团队是Scrum里最核心的角色。他们负责在每个Sprint结束时交付「潜在可交付的产品增量」。
团队有几个特点：
- 跨职能：团队内部具备完成工作所需的所有技能
- 自组织：没人告诉团队怎么干活，他们自己决定
- 规模适中：3-9人，太小缺乏技能互补，太大沟通成本飙升
你想想看，一个量化因子工厂的开发团队，需要哪些技能？策略研究员、数据工程师、后端开发、测试工程师……如果这些角色分散在不同部门，每次迭代都要跨部门协调，效率肯定上不去。所以我在组建团队时，尽量让这些角色坐在一起，形成一个完整的交付单元。
二、Scrum的三件工件
工件是Scrum的「信息辐射器」。它们让团队和利益相关者能随时看到项目状态。
1. Product Backlog（产品待办列表）
Product Backlog是一个动态的、有序的需求列表。它不是一成不变的，而是随着对产品的理解加深而持续演进。
每个Backlog条目应该包含：
- 描述（用户故事格式）
- 优先级
- 估算（故事点或理想人天）
- 验收标准
我的经验：Backlog条目不要写得太细。我见过有人把「修改按钮颜色」也写成一个用户故事，这其实没必要。Backlog的粒度应该控制在「一个Sprint能完成2-3个条目」的水平。太细了管理成本高，太粗了没法估算。
2. Sprint Backlog（迭代待办列表）
Sprint Backlog是团队在当前Sprint中承诺完成的工作。它从Product Backlog中选取，加上团队自己分解的任务。
举个例子：Product Backlog里有一条「实现因子回测引擎」，团队在Sprint Planning中把它拆成了「设计数据接口」「实现回测核心逻辑」「编写单元测试」「集成验证」四个任务。这些任务就构成了Sprint Backlog。
Sprint Backlog是团队自己的「作战地图」。它应该足够详细，让团队成员每天都能看到进度。
3. Increment（产品增量）
Increment是每个Sprint结束时交付的「潜在可用的产品功能」。注意「潜在可用」这个词——它意味着功能已经开发完成、测试通过、文档齐全，随时可以上线。
在因子工厂项目中，每个Sprint结束时，我们都会有一个可运行的因子计算模块。虽然可能只覆盖了部分因子类型，但它是完整的、可用的。
注意：「完成」不是「写完代码」。我见过团队在Sprint Review上展示半成品，说「功能基本完成了，就差测试和文档」。这其实不算完成。Scrum要求每个Increment都达到团队定义的「完成定义」（Definition of Done）。
三、Scrum的五个事件
事件是Scrum的「节奏器」。它们让团队保持同步，及时调整方向。
1. Sprint Planning（迭代计划会）
Sprint Planning是每个Sprint的起点。团队和PO一起，决定这个Sprint要做什么、怎么做。
会议回答三个问题：
- 这个Sprint要交付什么？（从Product Backlog中选取）
- 如何完成选中的工作？（分解任务、分配负责人）
- 团队能承诺多少工作量？（基于历史速率和团队容量）
我个人习惯把Sprint Planning控制在2-4小时（对于两周的Sprint）。时间太短，需求讨论不透彻；时间太长，大家注意力会下降。
2. Daily Scrum（每日站会）
Daily Scrum是每天15分钟的同步会议。团队围在一起，回答三个问题：
- 昨天我完成了什么？
- 今天我要做什么？
- 我遇到了什么障碍？
注意，Daily Scrum不是汇报给Scrum Master听的，而是团队成员之间的信息同步。我见过有人把Daily Scrum开成了「汇报会」，每个人对着Scrum Master说一遍，其他人都在玩手机。这完全失去了站会的意义。
避坑指南：我曾经在团队里推行「站会不过3分钟」的规则。每个人只说关键信息，遇到需要深入讨论的问题，会后拉个小会单独聊。这样站会效率高，大家也愿意参加。
3. Sprint Review（迭代评审会）
Sprint Review是展示成果的会议。团队向PO和利益相关者演示这个Sprint完成的功能。
会议的重点是获取反馈。PO会确认功能是否满足需求，利益相关者会提出新的想法。这些反馈会进入Product Backlog，影响后续的优先级。
在因子工厂项目中，我们每次Sprint Review都会跑一遍新开发的因子计算逻辑，让研究员现场验证结果。有一次研究员发现某个因子的计算结果和预期有偏差，当场就指出了问题。团队在下一个Sprint立即修复，避免了更大的返工。
4. Sprint Retrospective（迭代回顾会）
Sprint Retrospective是团队自我改进的会议。团队回顾这个Sprint的过程，找出做得好、做得不好、需要改进的地方。
回顾会通常分三步：
- 收集数据：这个Sprint发生了什么？
- 分析原因：为什么会出现这些问题？
- 制定改进计划：下一个Sprint我们尝试做什么？
我特别喜欢回顾会。它让团队有机会停下来思考，而不是一直埋头赶路。我记得有一次回顾会，团队发现测试覆盖率太低导致返工频繁。于是我们决定在下一个Sprint把「编写单元测试」作为每个任务的强制步骤。效果立竿见影——Bug率下降了60%。
四、Scrum框架的核心逻辑
说了这么多，Scrum到底是怎么运转的？我画了一张图，帮你理解整个流程。
从这张图你能看到，Scrum是一个闭环：Product Backlog → Sprint Planning → Sprint Backlog → Daily Scrum → Sprint Review → Increment → Sprint Retrospective → 反馈回到Product Backlog。每个Sprint都在这个循环中持续改进。
说白了，Scrum不是银弹。它不会自动让团队变高效。但它提供了一套清晰的框架，让团队有节奏地交付、有规律地反思、有方向地改进。我在多个量化团队推行Scrum后，最大的感受是：团队不再迷茫了。每个人都知道自己该做什么、什么时候做、做到什么程度算完。
嗯，这就是Scrum框架的核心。记住三个角色、三件工件、五个事件，你就掌握了Scrum的骨架。剩下的，就是在实践中不断填充血肉。