简介

Scrum 是一个灵活且高效的框架，旨在通过迭代和增量的方式帮助团队实现目标。它强调自主性和紧密合作，确保每天和每个阶段都朝着既定目标稳步前进。Scrum 基于经验主义，即知识来源于实际经验和已知的事物，通过不断优化来提高可预测性和管理风险。

Scrum 的核心是一个称为 Sprint（冲刺）的短周期迭代，通常持续一个月左右。每个 Sprint 都会产生一个可用的产品增量，这意味着每次迭代结束时都有一个可以发布的功能。Sprint 的长度在开发过程中保持一致，新的 Sprint 在上一个 Sprint 结束后立即开始。

如果 Sprint 时间过长，需求可能会发生变化，增加复杂度和风险。因此，Scrum 通过每月一次的检视和调整来确保项目的可预见性，并将风险限制在一个月的成本内。

团队角色

Scrum 团队由三个关键角色组成：

1. 产品负责人 (Product Owner)：

   • 代表客户的需求，确保团队专注于最有价值的功能。
   • 编写用户故事并排定优先级，放入产品待办事项列表（Product Backlog），以最大化项目的价值。
   • 协助团队理解需求，确保他们始终在开发最具价值的功能。
   • 对项目的整体规划、ROI 目标和发布计划负责，确保项目成功。

2. Scrum 主管 (Scrum Master)：（也叫敏捷教练）

   • 确保 Scrum 方法正确实施，并帮助团队遵守规则。
   • 教导团队和其他利益相关者如何使用 Scrum 方法。
   • 解决障碍，促进沟通，确保团队高效运作。

3. 开发团队：

   • 自组织、跨职能的团队，负责将 Sprint 待办事项列表（Sprint Backlog）转化为可用的产品增量。
   • 每个 Sprint 中，团队成员协作完成任务，确保 Sprint 目标的实现。
   • 团队规模一般为 5 到 9 人，包括设计师、开发者等多技能人员。

关键工件

Scrum 使用几个重要的工件来跟踪进展和管理任务：

1. 冲刺（Sprint）： 在Scrum框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint。官方建议每个Sprint的长度是2到4周（互联网产品研发可以使用1周的Sprint），前一个Sprint结束后，新的下一个Sprint紧接着立即开始；Sprint由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Sprint回顾会议构成。
2. 产品列表（Product Backlog）： 即产品需求列表，我更喜欢称之为需求池。其表现形式通常为用户故事，颗粒度较粗。它是一个有序的需求列表，包含所有需要开发的功能，由产品负责人维护并根据优先级排序，确保团队始终在处理最重要的工作。列表内容是动态的，随着项目的进展不断更新和完善。
3. 冲刺列表（Sprint Backlog）： 即本次Sprint迭代包含的任务列表，颗粒度较细。它是当前Sprint需要完成的任务清单，从产品待办事项列表中选出最高优先级的条目。包含详细的任务分解，每项任务明确负责人及其剩余工作量，仅团队有权修改其内容，确保任务清晰且可控。
4. 产品增量（Product Increment）： 本次Sprint+过去Sprint所产生的价值总和，说人话就是新版产品，要求满足验收标准。每个Sprint完成的所有产品待办事项列表项，以及之前所有Sprint的增量总和，必须符合“完成”的定义，即它是可用的、经过充分测试的，并准备好发布。

Scrum活动

Scrum活动主要由产品待办事项列表梳理、Sprint计划会议、迭代式软件开发、每日站立会议、持续集成、Sprint评审会议和Sprint回顾会议组成。

（1）产品待办事项列表梳理（Product Backlog）****

  PO会将利益相关者们的需求以及自身想法转化为具体的用户故事，接着进行需求规划：与利益相关者了解需求价值，放弃伪需求和无价值需求，将价值需求放入Product Backlog（需求池）；
  产品待办事项通常会很多，也很宽泛，而且想法会变来变去，优先级也会变化，所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容：
   1）保持产品待办事项列表有序；
   2）把看起来不再重要的事项移除或者降级；
   3）增加或提升涌现出来的或变得更重要的事项；
   4）将事项分解成更小的事项；
   5）将事项归并为更大的事项；
   6）对事项进行估算。
  产品待办事项列表梳理的最大好处是为即将到来的Sprint做准备，为此梳理时会特别关注那些即将被实现的事项。

（2）Sprint计划会议 （Sprint Planning Meeting）
  Sprint计划会议的目的是要为这个Sprint的工作做计划。这份计划是由整个Scrum团队共同协作完成的：
   • Sprint开始时均需召开该会议，产品负责人和团队共同探讨该Sprint的工作内容；
   • 产品负责人从最高优先级的产品待办事项中筛选目标，团队评估目标可实现性；
   • 会议时长一般不超过8小时（前4小时讨论需求，后4小时制定具体计划）。
  最终产生的Sprint待办事项列表（也叫冲刺列表（Sprint Backlog））为开发团队提供明确的增量构建指引。（含任务拆解与工期估算）

  这里值得一提的是需求规划和需求评审的区别，前者由PO主导，涉及商业、市场、运营，更像是范围层“我们做什么，不做什么”；后者由PM主导，涉及业务逻辑、产品架构、产品设计、功能实现、用户体验设计，更像是结构层“如何构建，如何连接”。

  比如PO提出一个用户故事，孩子的多个家长都可以实时收到孩子的学习情况，需求规划会对该需求价值、规模进行评判：其投资回报率及产品当前阶段，我们现在是否要实现这个需求。

  PM根据这个需求细化，是通过Push通知、短信通知、弹窗通知还是信息提示？包含学习时长、测试成绩、能力分析模型、老师评价等哪些功能?需求评审会对这些实现需求基于用户体验、技术层面进行评判：其实现方式、可行性、疑难点、潜在风险，我们如何去落地实现这些需求或者部分需求。（PM  是Product manager  产品经理，PO 产品负责人 (Product Owner)，在我的团队实践中是产品总监）

（3）迭代式软件开发 + 每日站立会议  （Daily Scrum Meeting）

  项目进入开发阶段，设计、开发、测试按照计划展开工作。
  通过将整个软件交付过程分成多个迭代周期：
   ✓ 实现增量交付与快速反馈；
   ✓ 通过持续关注工作节奏和高效协作（如每日站立会议），提升团队可持续生产力。

  每日站立会议核心规则：
   ▸ 准时开始（迟到者可能面临惩罚）；
   ▸ 全员参与且限时15分钟；
   ▸ 固定时间地点站立召开；
   ▸ 三问标准化反馈：
    -「今日成果？」
    -「明日计划？」
    -「当前障碍？」

  每日 Scrum 站会增进团队间的交流沟通、发现开发过程中需要移除的障碍、促进快速决策、提高团队的认知程度，这是一个进行检视与适应的关键会议。

（4）需求变更

  需求变更是在所难免的，我们要“响应变化高于遵循计划”；若发生紧急变更，我们从开发成本进行考量，是在本次完成还是将部分任务延后到下一次迭代，以确保本次迭代能如期交付；若发生重大变更，我们需要进行团队会议讨论解决方案。

  随着时间变化，问题发现、需求新解、任务完成，我们会对Sprint Backlog进行不断地调整修改。

（5）测试验收 + 持续集成

  对已完成开发的功能进行可用性、易用性、体验度、还原度等一系列测试验收，发布通过测试的部分、修复未通过部分；

  注意敏捷开发中的测试并非完成本次迭代所有开发任务才测试，而是完成一个测试一个，及时地发现问题解决问题。

  关键价值：
   ♦ 高频集成实现早期缺陷检测；
   ♦ 每Sprint交付可用功能增量（经充分测试且随时可发布）；
   ♦ 最终形成完整的产品版本堆叠。

（6）Sprint评审会议 （Sprint Review Meeting）
  操作要点：
   ▹ 时长4小时，展示Sprint成果；
   ▹ 利益相关方参与并获得反馈；
   ▹ 决策下一次Sprint内容；

（7）Sprint回顾会议 （Sprint Retrospective Meeting）
  流程特征：
   ✦ 每个Sprint结束后必开；
   ✦ 聚焦持续改进（限时4小时）；
   ✦ 识别流程优化机会，保障后续迭代效率。

总体回顾

    角色、工作、会议、产出