Scrum 是一个项目管理框架，强调团队合作，问责制和迭代进展，以实现明确的目标。该框架从一个简单的前提开始：从可以看到或已知的东西开始。之后，跟踪进度并根据需要进行调整。
Scrum 的三大支柱
Scrum 的基础是经验主义，它指出知识来自经验，我们应该根据已知的事情做出决定。有三个支柱将 Scrum 结合在一起。
为什么选择 Scrum？
Scrum 一次提供功能，而瀑布只提供阶段。典型的瀑布式开发是基于阶段的顺序过程，在项目结束之前不会给出价值。Scrum 将这种模式转变为每一周提供新功能，而不是专注于未来的大发布。
Scrum 将复杂的工作划分为简单的部分，将大型组织划分为小型团队，将影响深远的项目划分为一系列短时间的称为 sprint 的视野。
通过迭代和渐进式构建，公司能够更快，更有效地为客户提供他们真正需要的产品和服务。使用 Scrum，您可以在每个小开发周期结束时接收并整合客户反馈，这意味着您的结果将通过实际使用而非您的假设来塑造。这使得让客户和主要利益相关者密切参与和参与变得更加容易。
敏捷与 Scrum
敏捷方法是一种有助于在 SDLC 过程中持续迭代开发和测试的实践。敏捷将产品分解为更小的构建。Scrum 只是众多迭代和增量敏捷软件开发过程中的一个，它使我们能够专注于在最短的时间内提供业务价值。
Scrum 框架通常处理的是需求可能会发生变化，或者大部分时间在项目开始时都不知道。Scrum 的特点是：
轻量级
简单易懂
很难掌握
Scrum 的好处
以下是 scrum 为组织，团队，产品和个人提供的好处。
更好的质量：存在实现愿景或目标的项目。Scrum 提供持续反馈和曝光的框架，以确保质量尽可能高。Scrum 通过以下实践帮助确保质量
缩短产品上市时间：Scrum 已被证明能够为传统方法提供比最终客户快 30%到 40%的价值。
提高投资回报率：缩短上市时间是 Scrum 项目实现更高投资回报率（ROI）的一个关键原因。由于收入和其他目标福利开始提前，早期积累意味着更高的总回报率。这是净现值（NPV）计算的基本原则。
士气高级团队：与喜欢工作的快乐人士一起工作可以令人满意和有益。自我管理将通常由经理或组织做出的决策放入 scrum 团队成员的手中。
加强团队协作：当 Scrum 团队负责项目和产品时，他们可以产生很好的结果。Scrum 团队通过增强团队参与和沟通来协作并掌握质量和项目绩效。
Scrum 框架
Scrum 很简单。它与大量交织的强制组件相反。Scrum 不是一种方法论。Scrum 实现了经验主义的科学方法。Scrum 用启发式方法取代了程序化的算法方法，尊重人和自组织，以处理不可预测性和解决复杂问题。下图显示了 Ken Schwaber 和 Jeff Sutherland 在他们的“30 天软件”一书中描述的 Scrum in Action，它将我们从规划到软件交付。
Scrum 流程的组成部分
Scrum 框架本身非常简单。它仅定义了一些通用指南，仅包含一些规则，角色，工件和事件。然而，这些组件中的每一个都很重要，用于特定目的，对于成功使用框架至关重要。
Scrum Framework 的主要组件是：
Scrum 角色：Scrum Master，Scrum 产品负责人和 Scrum 团队
工件：Sprint 积压，产品积压，燃尽图，日志等 ……
Scrum 活动：Sprint 计划，春季评论，每日站立，冲刺复古等 ……
短跑
下图显示了 SCRUM 框架的关键元素。该过程已由敏捷软件工具 Scrum Process Canvas 应用。
Scrum 角色
当一个组织决定接受 Scrum 时，首先要了解的是 Scrum 角色与传统项目执行角色的不同之处。虽然 Scrum 中只有三个主要角色，但它们并不会自动与我们大多数人熟悉的标题保持一致。让我们从每个的简要定义开始：
产品拥有者
产品所有者是代表业务或用户社区的人员的 scrum 开发角色，负责与用户组合作以确定产品版本中的功能。产品负责人的主要职责是：
制定产品和服务的方向和战略，包括短期和长期目标;
提供或获取有关产品或服务的知识;
了解并解释开发团队的客户需求;
收集，优先排序和管理产品或服务要求;
接管与产品或服务预算相关的任何责任，包括其盈利能力;
确定产品或服务功能的发布日期;
每天与开发团队一起回答问题并做出决定;
接受或拒绝与 Sprint 相关的已完成功能;
在每个 Sprint 的最后展示开发团队的主要实现;
负责产品 Backlog
Scrum 大师
Scrum master 是敏捷开发团队的推动者。Scrum 是一种方法，允许团队根据敏捷原则自我组织并快速进行更改。Scrum master 管理信息交换的过程。Scrum Master 的主要职责是：
充当教练，帮助团队遵循 Scrum 价值观和实践;
帮助消除障碍并保护团队免受外部干扰;
促进团队与利益相关者之间的良好合作;
促进团队内部的常识;
保护团队免受组织干扰;
Scrum 团队
Scrum 团队（又名开发团队）由 3 到 9 人组成，他们必须满足提供产品或服务的所有技术需求。它们将由 Scrum Master 直接引导，但不会直接管理。他们必须是自我组织的，多才多艺的，并且负责任地完成所有必需的任务。
开发团队负责从分析，设计，开发，测试到技术写作等每个 sprint 提供潜在的可交付产品增量。对于 Scrum 团队具有以下特征非常重要：
团队必须是自组织的。所有团队组件必须管理自己的工作以完成已经给出的任务。在 Agile Scrum 中，没有团队负责人或直线经理的身影。每个人都必须做出足够的承诺来开展自己的活动，并为团队的成功做出贡献。如果一个失败，每个人都会失败。
团队必须是跨职能的。所有团队成员必须拥有所有必需的知识和技能，以提供做得好并且随时可用的服务或产品。专家可用于必要的案例，但仅作为教练将知识传授给团队以实现特定差距。
成为产品负责人需要企业愿景。产品负责人代表客户的声音，需要将他们的需求转化为 Scrum Master 和开发团队。这通常是一份全职工作。
Scrum Master 不是直线经理。他们帮助向开发团队提供所需的教练，并帮助消除团队面临的任何障碍。
Scrum 工件
SCRUM 工件用于帮助定义进入团队并且当前正在团队中工作的工作负载。还有更多的工件，例如，用户故事，发布积压，刻录图表等。但我们将专注于核心三：
产品积压
产品待办事项是用户故事的集合，其呈现产品团队所需 / 期望的功能。通常，产品所有者负责此列表。
Sprint 积压
Sprint 积压包含一系列可以包含在当前 sprint 中的故事。有关 sprint 积压与将项目包含在 sprint 中之间关系的两个要点需要注意。1）团队决定添加到 sprint 的内容。因此，团队负责交付这些物品的所有权和责任。2）在将项目从 sprint backlog 中删除并添加到 sprint 之前，团队必须确保他们拥有积压中所需的所有信息。通常，团队定义在添加项目之前必须存在的项目清单。
产品 Backlog 与 Sprint Backlog
在冲刺积压是 Scrum 的冲刺过程中完成了由 Scrum 团队确定的任务列表。在 sprint 计划会议期间，团队通常以用户故事的形式选择一些产品待办事项，并确定完成每个用户故事所需的任务，如下图所示：
刻录图表
刻录图表是剩余工作与时间的图形表示。突出的工作（或积压工作）通常在垂直轴上，沿水平方向的时间。也就是说，这是一份杰出工作的运行图表。它可用于预测何时完成所有工作。它通常用于敏捷软件开发方法，如 Scrum。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。杰出的工作可以用时间或故事点来表示。
Scrum 活动
沟通是关键！SCRUM 依赖于团队的所有方面并且透明地工作（Scrum 支柱#1）。考虑到这种核心理念，该方法围绕一系列关键事件构建，以确保其他两个支柱：检查和调整如下表所示：
事件
检查
适应
Sprint 计划
产品积压
（承诺回顾）
（Done 的定义）
冲刺目标
预测
Sprint 积压
每日 Scrum
冲刺目标的进展
Sprint 积压
每日计划
Sprint 评论
产品增量
产品积压（发布）
市场商业条件
产品积压
Sprint 回顾
团队合作
技术与工程
完成的定义
切实可行的改进
注意：在执行每个 sprint 期间，Scrum 中有五个主要会议，如下图所示：
Sprint 计划
所有冲刺都从计划开始。团队需要确定并承诺将作为 sprint 的一部分交付哪些项目。可能的项目总是从 Sprint Backlog 中获取，如下图所示：
这是 SCRUM 主人可以发光的时间。产品所有者从业务 / 客户的角度确定他们需要的方面，SCRUM 团队，确定他们认为可以提供哪些项目，以及 SCRUM 主人适应所有项目并确保满足两个方面的最佳要求。
每日 Scrum 会议
一旦团队确定了他们承诺作为 sprint 的一部分交付的项目。该团队将举行每日站立会议。此次会议的核心目标是确保团队中的每个人（以及可能的观察员）完全了解正在完成的任务的状态和进度：
他们做了什么
他们今天要做什么
什么阻止他们
此每日更新向团队提供实例反馈并提供。这些会议意味着简短，每人不超过 3 分钟。
注意：
观察员在那里观察，SCRUM 主人必须尽可能减轻外部干扰和团队干扰。
Sprint 评审会议
在 Sprint 结束时举行 Sprint 评审 / 演示会议以检查增量。团队根据完成定义演示增量，重点关注 Sprint 目标。产品负责人审核并接受交付的增量。
Sprint 回顾
冲刺回顾通常是冲刺中最后完成的事情。许多团队将在冲刺审查后立即执行此操作。包括 Scrum Master 和产品所有者在内的整个团队都应该参与其中。您可以安排 scrum 回顾展达一个小时，这通常是足够的。回顾展让团队有机会确定 3 个关键方面：
应该开始做什么？
什么不顺利（并再次停止做）？
什么进展顺利（并且应该继续做什么？）？
这种方法的目的是不断提高团队效率。
积压细化会议
将积压视为项目的路线图。当团队协作创建需要为项目完成构建或完成的所有事项的列表时，可以修改此列表并将其添加到整个项目中，以确保满足项目的所有必要需求。
短跑
在 Scrum 框架中，Scrum 产品 Backlog 中实现条目所需的所有活动都在 Sprint 中执行（也称为“Iterations”）。短跑总是很短：通常大约 2 - 4 周。每个 Sprint 都遵循一个定义的过程，如下所示：
如前所述，产品待办事项中的项目按优先级排序并选择 sprint backlog。一个 sprint 只包含几个大项目，即使单个项目低估工作的影响也会对 sprint 产生深远的影响。而且由于较大的项目往往难以估计和理解，因此短跑失败的可能性会进一步增加。经验丰富的 Scrum 团队花费时间和精力将复杂和较大的项目（即用户功能或史诗）分解为较小的用户故事（或随后分解为任务或子任务）。
史诗
史诗捕捉了大量的作品。它本质上是一个“大型用户故事”，可以分解为许多小故事。完成史诗可能需要几次冲刺。因此，当我们将 epic 用于开发时，它必须被分解为更小的用户故事。
在项目周期的早期，我们提出了 Epics。这些是非常高级的，几乎以营销为中心的功能性要点。
我们将大型故事称为“史诗”，以传达有关它们的信息。我喜欢把这与电影有关。如果我告诉你一部特定的电影是一部“动作冒险电影”，它会告诉你有关电影的一些信息。可能有一些汽车追逐，可能是一些射击，等等。同样，将一个故事称为“史诗”有时可以传达其他意义。
用户故事
故事是产品要求或业务案例的简要陈述。通常，故事用简单的语言表达，以帮助读者理解软件应该完成的内容。产品所有者创建故事。然后，scrum 用户将故事分成一个或多个 scrum 任务。
用户故事通常是最终用户可见的功能。用户故事遵循“我作为世界卫生组织想要做什么”的格式，以便为什么。用户故事为客户 / 用户提供价值。这是客户 / 用户的产品要求。
例如“作为客户，我希望能够创建一个帐户，以便我可以看到我去年购买的商品，以帮助我明年的预算。”
任务
另一方面，任务更具技术性，任务通常类似于代码，设计，为此类创建测试数据，自动执行等等。这些往往是由一个人完成的事情。任务不是以用户素材格式编写的。任务更具技术性。
例如“评估用户界面的角度材料设计”或“将应用程序提交到应用商店”。
為初學者提供更多敏捷和 Scrum 文章
Scrum 和自组织团队 (Scrum and Self-Organizing Team) 敏捷和 Scrum – 有什么区别？在 Scrum Sprint 中发布的频率是如何确定的？通过 3 个步骤建立自组织团队 The Best Free Scrum Learning Resources, Guides and Articles 为什么敏捷开发是您项目的更好选择？为什么 Scrum 是 – 快速失败技术?8 经常被误解的 Scrum Master 角色 Scrum Events – 初学者阅读文章 Scrum 在 3 分钟内完成