1. 概述

本章节将介绍 Scrum 的基础知识，以及对比 Scrum 与瀑布流式开发，也将介绍 Scrum 中的 3 个角色、3 个工件和 3 个活动。

首先介绍 Scrum 与传统瀑布流式开发之间的区别。

瀑布式开发通常花费数个月时间规划（Plan）产品，然后再花费数个月时间研发（Build）产品，接着测试（Test）产品、评审（Review），最终部署（Deploy）产品。

重点是，如果市场需求或技术环境发生变化，此时研发出的产品很可能无法满足市场需求，瀑布式开发在遇到这些变化时，将出现很多问题。首先，产品规划必须先于后续工作完成，在绝大部分案例中，规划环节结束时，还不能完全理解项目，但开发已经完成。通常情况下，整个项目必须回溯到规划阶段，然后从头再来。否则，研发人员将因不理解产品规划，而受到批评。研发工作完成时，这种情况将出现多次。比如研发工作已经完成，进行产品测试时发现问题，就得重新开发，有时甚至需要重新规划产品。在接下来的步骤中，也将多次出现同样的问题。这很可能导致产品发布时间滞后，短则数月，长则数年。

使用 Scrum（一种敏捷开发实现）时，该流程被分解成多个更小的部分。首先，我们为开始构建最小特性集合（min feature set）进行足够的规划，然后开发规划的东西。接下来，测试和评审该小特性集合，直到准备发布。该循环完成时，将得到可发布的产品。该流程通常只需要 1 - 3 周的时间。然后不断地重复该流程，以减少每次规划过程中从规划到开发到测试的时间。我们只执行完成下次增量发布的详尽规划，最终得到多个被称为 Sprint 的增量发布，一个 Sprint 通常需要 1 - 3 周的时间，只需不断重复 Sprint，直到产品功能齐全。有时，可能在第二个或第三个或第四个或甚至更久的 Sprint 后，最终塑造出产品。但不管怎么说，最终拥有一个潜在的可发布产品。

在 Scrum 中，团队正常工作需要三个关键角色。首先，产品负责人（Product Owner）负责阐明产品所需的功能。Scrum Master 是团队的负责人，负责帮助团队尽其所能地完成工作，组织会议和保障其它工作。Scrum 团队（Scrum Team）由开发、测试、文案以及其他帮助构建产品的人员组成，团队成员通常扮演多种角色，有时开发人员可能最终完成测试，或者测试人员可能最终完成文案。无论哪种方式，团队都在努力地完成产品。

Scrum 使用三种文档化的工件（Artifact）。第一种是产品待办事项列表（Product Backlog），产品负责人在其中创建可能被纳入产品的功能的优先级列表。用户故事（User Story）是一种描述功能集合的方式，它遵循「作为一个___，我需要___，以便___。」的格式。这种表述用户故事的方式，使产品负责人可以给团队指定合适的详细程度，以评估任务大小。最高优先级的用户故事将进入 Sprint 待办事项列表（Sprint Backlog），其余的被评估大小，并且被提交到下个 Sprint 中。燃尽图（Burndown Chart），在 Sprint 期间，展示 Sprint 待办事项列表中的任务的完成进度。当燃尽图曲线接近 0 时，意味着本次 Sprint 即将完工。

Scrum 由三种会议（或讨论）组成。Sprint 计划会（Sprint Plan Meeting）是产品负责人、Scrum Master、团队碰头的会议，用于讨论用户故事和估算工作量。每日例会（Daily Scrum）是我们熟知的站立会，在该会议中，整个团队简述工作进度，并且讨论是否有任务需要搁置或需要帮助。Sprint 临近尾声时，将举行评审会（Review）和回顾会（Retrospective），在该会议中，团队向产品负责人演示开发完成的工作，然后团队讨论是否有需要改进的地方。

接下来回顾 Scrum 的工作流程。

从产品待办事项列表开始，它是产品负责人建立可能纳入产品的创意和功能的列表的地方。产品负责人对该列表进行优先级排序，并且将排名靠前的条目带给团队讨论。团队、产品负责人和 Scrum Master 在 Sprint 计划会上讨论高优先级的用户故事，决定将哪些用户故事纳入到下个 Sprint。Sprint 计划会议的输出是 Sprint 待办事项列表，它是被提交到下个 Sprint 的用户故事列表。基于 Sprint 计划会议的讨论，整个团队和产品负责人必须对每个用户故事所涉及的东西有深刻的理解。Sprint 是 1 - 3 周的时间盒，Sprint 待办事项列表中承诺的工作将在该时间盒内被完成。在 Sprint 期间，每日例会用于团队交流他们已经完成什么任务，正在做什么任务，以及遇到的问题。Sprint 的产出是潜在的可发布产品。可发布意味着产品负责人决定是否发布，或者是否在发布前添加新功能。在 Sprint 结束时，举行 Sprint 评审会和 Sprint 回顾会。在 Sprint 评审会中，团队向产品负责人演示案例。在回顾会中，团队一起反思工作中可以改进的地方。每个 Sprint 都重复该工作流程。

2. 规则

在 Scrum 中，研发流程被分为多个 Sprint。每个 Sprint 的工作流程如下：

Sprint 遵循如下规则：

• Sprint 受时间盒的限制，无论工作完成与否都将在特定日期结束，并且不延长
• 每个迭代不超过 4 周（通常 2 周），并且无间歇地相继进行
• 在 Sprint 过程中不能增加新事项，Scrum 在下一个 Sprint 时才接受变化。在当前 Sprint 周期中，只注重短小、清晰、相对固定的目标
• Scrum 强调：Sprint 结束时，产生真正的可发布产品

3. 角色

4. 工件

名称	描述
产品待办事项列表（Product Backlog）	产品待办事项列表存在（并且演化）于产品的整个生命周期，它是产品的路线图。 1. 使用用户故事描述的需求列表 2. 产品负责人对该列表进行优先级排序 3. Sprint 结束时，需要更新优先级
Sprint 待办事项列表（Sprint Backlog）	定义 Sprint 目标，明确具体需要完成的任务。 管理 Sprint 待办事项列表的规则如下： 1. 团队成员自己挑选任务，而非指派任务 2. 对于每个任务，每天需要更新剩余的工作量估算 3. 每个团队成员都可以修改 Sprint 待办事项列表，增加、删除或修改任务
燃尽图（Burndown Chart）	燃尽图是展示剩余任务数量的趋势图。图中 Y 轴代表剩余工作量，X 轴代表 Sprint 的工作日。
增量（Increment）	增量是 Sprint 完成的产品待办事项列表，以及之前所有 Sprint 产生的增量的总和。在 Sprint 结束时，新的增量必须是完成的，这意味着它必须可用，并且达到 Scrum 团队“完成”的定义标准。无论产品负责人是否决定真正发布它，增量必须可用。
阻碍清单（Blocks List）	列举团队内部及与团队相关的所有阻碍项目进度的问题。Scrum Master 需要确保所有问题都已分配，并且可以得到解决。

5. 会议

参考文档

• https://www.bilibili.com/video/BV1rW411K7vD/
• https://www.jianshu.com/p/c68985d282f5
• https://zhuanlan.zhihu.com/p/525614983
• https://blog.csdn.net/p309654858/article/details/127766590