Scrum科普

Scrum 是什么？

Scrum 是当前最流行的敏捷软件开发方法论和实施框架。

Scrum 是一种团队管理工作的方式，其将工作分解为较小的工作单元，并在周期性固定的时间段内持续地交付工作单元。

Scrum的历史

我们在20世纪90年代初开发了Scrum。我们在2010年编写了第一版Scrum指南，以帮助全世界的人们了解Scrum。从那时起，我们通过小规模、功能性的更新来发展该指南。我们共同支持它。

Scrum指南包含了Scrum的定义。该框架的每个元素都有一个特定的目的，对于通过Scrum实现的整体价值和结果至关重要。改变Scrum的核心设计或理念，遗漏元素，或不遵循Scrum的规则，都会掩盖问题，限制Scrum的好处，甚至有可能使其失去作用。

我们关注着Scrum在一个不断增长的复杂世界中的使用情况。我们谦卑地看到，除了Scrum的根基所在的软件产品开发之外，Scrum还被许多拥有基本复杂工作的领域所采用。随着Scrum使用的普及，开发人员、研究人员、分析师、科学家和其他专家都在做这项工作。我们在Scrum中使用 "开发者 "这个词并不是为了排斥，而是为了简化。如果你从Scrum中获得了价值，请考虑将自己包括在内。

随着Scrum的使用，符合本文所描述的Scrum框架的模式、流程和见解都可能被发现、应用和设计出来。对它们的描述超出了《Scrum指南》的目的，因为它们对环境是敏感的，而且在Scrum的使用中差异很大。这种在Scrum框架内使用的策略差别很大，在其他地方也有描述。

Scrum的定义

Scrum是一个轻量级的框架，它帮助人们、团队和组织通过对复杂问题的适应性解决方案产生价值。

简而言之，Scrum要求Scrum Master培养一种环境。

• 产品负责人将一个复杂问题的工作安排到产品后备库中。

• Scrum团队在Sprint期间将选择的工作变成价值增量。

• Scrum团队和其利益相关者检查结果，并为下一个Sprint进行调整。

• 重复进行

Scrum很简单。按原样尝试，确定其哲学、理论和结构是否有助于实现目标和创造价值。Scrum框架是故意不完整的，只定义了实施Scrum理论所需的部分。Scrum是由使用它的人的集体智慧建立的。Scrum的规则不是为人们提供详细的指示，而是指导他们的关系和互动。

各种流程、技术和方法都可以在这个框架内使用。Scrum围绕着现有的实践，或使其成为不必要的。Scrum使当前的管理、环境和工作技术的相对有效性显而易见，从而可以进行改进。

Scrum理论

Scrum 基于经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum 采用迭代增量式的方法来优化可预测性和管理风险。透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。

Scrum是建立在经验主义和精益思维之上的。经验主义认为，知识来自于经验，并根据观察到的情况做出决定。精益思维减少了浪费，并将注意力集中在本质上。

Scrum采用了迭代、增量的方法来优化可预测性和控制风险。Scrum让那些集体拥有所有技能和专业知识的人参与进来，并根据需要分享或获得这些技能。

Scrum将四个正式的活动结合起来，在一个包含的事件，即Sprint中进行检查和调整。这些活动之所以有效，是因为它们实现了Scrum的经验性支柱--透明、检查和适应。

透明度

流程中的关键环节必须为那些对产出负责的人可见。例如，负责完成工作和验收工作的人必须对 “Definition of Done” 有一致的定义。

对于执行工作的人和接受工作的人来说，新兴的过程和工作必须是可见的。在Scrum中，重要的决定是基于其三个正式工件的感知状态。透明度低的工件会导致降低价值和增加风险的决定。

透明度使检查成为可能。没有透明度的检查是误导和浪费的。

检查

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进度，以发现不必要的偏差。

Scrum工作成果和商定目标的进展必须被经常性地检查，以发现潜在的不理想的差异或问题。为了帮助检查，Scrum以其五个事件的形式提供了节奏。

检查使人适应。没有适应性的检查被认为是毫无意义的。Scrum事件的设计是为了激发变化。

适应

如果检视者发现流程中的一个或多个方面背离了可接受的标准，并且将会导致产品不合格时，就必须对流程本身或者流程化的内容进行调整。Scrum 通过所提供的多种事件来及时调整以缩小偏差。

如果一个流程的任何方面偏离了可接受的范围，或者所产生的产品是不可接受的，那么必须调整正在应用的流程或正在生产的材料。调整必须尽快进行，以减少进一步的偏差。

当相关人员没有得到授权或自我管理时，适应就变得更加困难。一个Scrum团队在通过检查了解到任何新情况的时候，就应该进行调整。

Scrum价值观

Scrum的成功应用取决于人们是否能更熟练地运用五种价值观。

承诺、专注、开放、尊重和勇气

Scrum团队致力于实现其目标并相互支持。他们主要关注的是Sprint的工作，以便尽可能地朝着这些目标取得进展。Scrum团队和其利益相关者对工作和挑战持开放态度。Scrum团队成员互相尊重，认为对方是有能力的、独立的人，并被与他们一起工作的人尊重成这样。Scrum团队成员有勇气去做正确的事情，去解决棘手的问题。

这些价值观为Scrum团队的工作、行动和行为指明了方向。所做的决定、采取的步骤以及使用Scrum的方式应该加强这些价值观，而不是削弱或破坏它们。Scrum团队成员在与Scrum事件和工件合作的过程中学习和探索这些价值观。当这些价值观被Scrum团队和与他们一起工作的人体现出来时，Scrum的经验性支柱--透明、检查和适应--就会变成现实，建立信任。

Scrum团队

Scrum 的框架结构通常由 “3 of 3s” 组成，即 3 种角色，3 种事件，3 种工件。

Scrum是一个小团队的基本单位，即Scrum团队。Scrum团队由一名 Scrum Master,、一名产品负责人和开发人员组成。

在Scrum团队中，没有子团队或等级制度。它是一个由专业人员组成的有凝聚力的单位，每次都集中在一个目标上，即产品目标。

Scrum团队是跨职能的，这意味着成员拥有所有必要的技能来创造每个Sprint的价值。他们也是自我管理的，意味着他们在内部决定谁做什么，何时做，如何做。

Scrum团队小到可以保持灵活性，大到可以在一个Sprint中完成重要的工作，通常是10人或更少。一般来说，我们发现小团队的沟通能力更强，效率更高。如果Scrum团队变得太大，他们应该考虑重组为多个有凝聚力的Scrum团队，每个团队都专注于同一个产品。因此，他们应该共享相同的产品目标、产品Backlog和产品负责人。

Scrum团队负责所有与产品相关的活动，从利益相关者的合作、验证、维护、操作、实验、研究和开发，以及其他任何可能需要的活动。他们被组织结构化并被授权管理自己的工作。以可持续的速度在Sprints中工作可以提高Scrum团队的专注度和一致性。

整个Scrum团队有责任在每个Sprint创造一个有价值的、有用的增量。Scrum定义了Scrum团队中的三个具体责任人：开发人员、产品负责人和Scrum Master.。

开发人员

开发人员是Scrum团队中致力于在每个Sprint创建可用增量的任何方面的人。

开发人员所需要的具体技能通常是广泛的，并且会随着工作领域的不同而变化。然而，开发人员总是要对以下方面负责。

• 为Sprint创建一个计划，即Sprint Backlog。

• 通过遵守 "完成的定义 "来灌输质量。

• 每天调整他们的计划，以实现Sprint的目标；以及。

• 作为专业人员对彼此负责。

产品负责人

产品负责人负责将Scrum团队的工作所产生的产品的价值最大化。如何做到这一点，在不同的组织、Scrum团队和个人之间会有很大的不同。

产品负责人也要对有效的产品Backlog管理负责，这包括。

• 开发并明确地传达产品目标

• 创建并明确沟通产品Backlog项目

• 对产品Backlog项目进行排序；以及。

• 确保产品Backlog是透明的、可见的和可理解的。

产品负责人可以做上述工作，也可以将责任委托给其他人。无论怎样，产品负责人仍然是负责任的。

为了使产品负责人成功，整个组织必须尊重他们的决定。这些决定在产品Backlog的内容和排序中是可见的，以及通过 Sprint 审查中可检查的增量。

产品负责人是一个人，而不是一个委员会。产品负责人可以代表产品Backlog中许多利益相关者的需求。那些想要改变产品Backlog的人可以通过试图说服产品负责人来实现。

Scrum Master

Scrum Master 负责建立Scrum指南中定义的Scrum。他们通过帮助每个人理解Scrum理论和实践来实现这一目标，包括在Scrum团队和组织中。

Scrum Master 对Scrum团队的有效性负责。他们通过使Scrum团队在Scrum框架内改善其实践来实现这一目标。

Scrum Master是真正的领导者，为Scrum团队和更大的组织服务。

Scrum Master以多种方式为Scrum团队服务，包括。

• 指导团队成员进行自我管理和跨职能的工作。

• 帮助 Scrum 团队专注于创建符合完成定义的高价值增量;

• 消除 Scrum 团队进展的障碍;

• 确保所有的Scrum活动都是积极的、富有成效的，并保持在规定的时间内。

Scrum Master 以多种方式为产品负责人服务，包括。

• 帮助寻找有效的产品目标定义和产品待办事项管理技术;

• 帮助 Scrum 团队理解清晰简洁的产品待办事项列表项的必要性;

• 帮助建立针对复杂环境的实证产品规划；和，

• 根据要求或需要促进利益相关者的合作。

Scrum Master以多种方式为组织服务，包括。

• 领导、培训和指导组织对Scrum的采用。

• 为组织内的Scrum实施提供计划和建议。

• 帮助员工和利益相关者理解并颁布复杂工作的经验方法；以及。

• 消除利益相关者和Scrum团队之间的障碍。

Scrum事件

Sprint是所有其他事件的容器。Scrum的每个事件都是检查和调整Scrum工件的正式机会。这些事件是专门设计来实现所需的透明度的。如果不按规定操作任何事件，就会失去检查和调整的机会。活动在Scrum中被用来创造规律性，并尽量减少对Scrum中未定义的会议的需求。

最理想的情况是，所有事件都在同一时间和地点举行，以减少复杂性。

Sprint(冲刺)

Sprint(冲刺)是Scrum的核心，是将想法变成价值的地方。

它们是固定长度的活动，为期一个月或更短，以创造一致性。一个新的Sprint在上一个Sprint结束后立即开始。

实现产品目标所需的所有工作，包括 Sprint 计划、每日站会、Sprint 评审和 Sprint 回顾，都在Sprint中进行。

在Sprint期间:

• 不进行任何会危及 Sprint 目标的更改；

• 质量不下降；

• 根据需要细化产品待办列表；和，

• 随着了解的更多，范围可能会被澄清并与产品负责人重新协商。

冲刺通过确保至少每个日历月检查和调整产品目标的进展来实现可预测性。当 Sprint 的视野太长时，Sprint 目标可能会变得无效，复杂性可能会增加，风险也可能会增加。可以采用更短的 Sprint 来产生更多的学习周期，并将成本和工作量的风险限制在更短的时间范围内。每个 Sprint 都可以被认为是一个短项目。

存在各种预测进度的实践，例如 burn-downs、burn-ups或 cumulative flows。虽然被证明是有用的，但这些并不能取代经验主义的重要性。在复杂的环境中，会发生什么是未知的。只有已经发生的事情才能用于前瞻性决策。

如果Sprint目标变得过时，一个Sprint可能会被取消。只有产品负责人才有权力取消Sprint。

Sprint Planning(冲刺计划)

Sprint Planning 通过布置要为 Sprint 执行的工作来启动 Sprint。这个最终计划是由整个 Scrum 团队的协作工作创建的。

产品负责人确保与会者准备好讨论最重要的产品待办列表项以及它们如何映射到产品目标。 Scrum 团队也可以邀请其他人参加 Sprint Planning 来提供建议。

Sprint 计划涉及以下主题：

主题一：为什么这个 Sprint 有价值？ 产品负责人提出产品如何在当前 Sprint 中增加其价值和实用性。然后整个 Scrum 团队合作定义一个 Sprint 目标，该目标传达了为什么 Sprint 对利益相关者有价值。 Sprint 目标必须在 Sprint 计划结束之前完成。

主题二：这个 Sprint 可以做什么？ 通过与产品负责人的讨论，开发人员从产品待办列表中选择要包含在当前 Sprint 中的项目。 Scrum 团队可以在此过程中改进这些项目，从而增加理解和信心。

选择在 Sprint 中可以完成多少可能具有挑战性。然而，开发人员对他们过去的表现、即将到来的能力以及完成的定义了解得越多，他们对 Sprint 预测的信心就越大。

话题三：选择的工作将如何完成？ 对于每个选定的产品待办列表项，开发人员计划创建满足完成定义的增量所需的工作。这通常是通过将产品待办列表项分解为一天或更短时间的较小工作项来完成的。如何做到这一点由开发人员自行决定。没有其他人告诉他们如何将产品待办列表项转化为价值增量。

Sprint 目标、为 Sprint 选择的产品待办列表项以及交付它们的计划一起称为 Sprint 待办列表。

对于为期一个月的 Sprint，Sprint 计划的时间限制为最多 8 小时。对于更短的 Sprint，事件通常更短。

Daily Scrum (每日站会)

Daily Scrum 的目的是检查 Sprint 目标的进展情况，并根据需要调整 Sprint Backlog，调整即将到来的计划工作。

Daily Scrum 是面向 Scrum 团队开发人员的 15 分钟活动。为了降低复杂性，它在 Sprint 的每个工作日的同一时间和地点举行。如果产品负责人或 Scrum Master 正在积极处理 Sprint Backlog 中的项目，他们将作为开发人员参与。

开发人员可以选择他们想要的任何结构和技术，只要他们的 Daily Scrum 专注于实现 Sprint 目标的进展并为第二天的工作制定可操作的计划。这创造了焦点并改善了自我管理。

Daily Scrums 改善沟通，识别障碍，促进快速决策，从而消除对其他会议的需要。

Daily Scrum 并不是开发人员唯一可以调整计划的时间。他们经常全天开会，就调整或重新规划 Sprint 的其余工作进行更详细的讨论。

Sprint Review （冲刺评审）

Sprint 评审的目的是检查 Sprint 的结果并确定未来的调整。 Scrum 团队向关键利益相关者展示他们的工作结果，并讨论实现产品目标的进展。

在活动期间，Scrum 团队和利益相关者审查 Sprint 中完成的内容以及他们的环境中发生的更改。根据这些信息，与会者就下一步该做什么进行协作。产品待办列表也可能会进行调整以满足新的机会。 Sprint 评审是一个工作会议，Scrum 团队应该避免将其局限于演示。

Sprint Review 是 Sprint 的倒数第二个事件，对于一个月的 Sprint，时间限制为最多四个小时。对于更短的 Sprint，事件通常更短。

Sprint Retrospective（冲刺回顾）

Sprint 回顾的目的是规划提高质量和效率的方法。

Scrum 团队检查上一个 Sprint 在个人、交互、流程、工具及其完成定义方面的进展情况。检查的元素通常因工作领域而异。确定了导致他们误入歧途的假设，并探索了它们的起源。 Scrum 团队讨论 Sprint 期间哪些方面进展顺利，遇到哪些问题，以及这些问题是如何解决（或未解决）的。

Scrum 团队确定最有帮助的更改以提高其有效性。尽快解决最具影响力的改进。它们甚至可能被添加到下一个 Sprint 的 Sprint Backlog 中。

Sprint 回顾总结了 Sprint。对于为期一个月的 Sprint，它的时间限制为最多三个小时。对于更短的 Sprint，事件通常更短。

Scrum Artifacts （Scrum工件）

Scrum 的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度。因此，每个检查它们的人都有相同的适应基础。

每个工件都包含一个承诺，以确保它提供的信息可以提高透明度和重点，从而可以衡量进展：

• 对于产品待办列表，它是产品目标。

• 对于 Sprint Backlog，它是 Sprint （冲刺）目标。

• 对于增量，它是完成的定义。

这些承诺的存在是为了加强 Scrum 团队及其利益相关者的经验主义和 Scrum 价值观。

Product Backlog(产品待办事项列表)

产品待办列表是一个紧急的、有序的列表，列出了改进产品所需的内容。它是 Scrum 团队承担的唯一工作来源。

可以在一个 Sprint 中由 Scrum 团队完成的产品待办列表项被视为已准备好在 Sprint 计划事件中进行选择。他们通常在精炼活动后获得这种程度的透明度。产品待办列表细化是将产品待办列表项目分解并进一步定义为更小更精确的项目的行为。这是一项持续的活动，用于添加详细信息，例如描述、订单和尺寸。属性通常因工作领域而异。

将进行这项工作的开发人员负责调整大小。产品负责人可以通过帮助开发人员理解和选择权衡来影响他们。

承诺：产品目标 产品目标描述了产品的未来状态，可以作为 Scrum 团队计划的目标。产品目标在产品待办列表中。产品待办列表的其余部分用于定义“什么”将实现产品目标。

产品是传递价值的工具。它有明确的边界、已知的利益相关者、明确定义的用户或客户。产品可以是服务、实体产品或更抽象的东西。

产品目标是 Scrum 团队的长期目标。他们必须先完成（或放弃）一个目标，然后才能开始下一个目标。

Sprint Backlog(冲刺待办清单)

Sprint Backlog 由 Sprint 目标（为什么）、为 Sprint 选择的一组产品 Backlog 项目（什么）以及交付增量的可操作计划（如何）组成。

Sprint Backlog 是由开发人员制定并为开发人员制定的计划。它是开发人员为实现 Sprint 目标而计划在 Sprint 期间完成的工作的高度可见的实时图片。因此，Sprint Backlog 在整个 Sprint 中随着学习的增加而更新。它应该有足够的细节，以便他们可以检查他们在 Daily Scrum 中的进度。

承诺：冲刺目标 Sprint 目标是 Sprint 的单一目标。尽管 Sprint 目标是开发人员的承诺，但它在实现目标所需的确切工作方面提供了灵活性。 Sprint 目标还创造了连贯性和重点，鼓励 Scrum 团队一起工作，而不是在单独的计划上。

Sprint 目标是在 Sprint 计划活动期间创建的，然后添加到 Sprint Backlog 中。当开发人员在 Sprint 期间工作时，他们会牢记 Sprint 目标。如果工作结果与他们预期的不同，他们会与产品负责人合作，在不影响 Sprint 目标的情况下协商 Sprint 待办列表的范围。

Increment(增量)

增量是实现产品目标的具体垫脚石。每个增量都是对所有先前增量的补充，并经过彻底验证，确保所有增量协同工作。为了提供价值，增量必须可用。

可以在 Sprint 中创建多个增量。增量的总和在 Sprint 评审中呈现，从而支持经验主义。但是，增量可能会在 Sprint 结束之前交付给利益相关者。 Sprint 评审永远不应被视为释放价值的大门。

工作不能被视为增量的一部分，除非它符合完成的定义。

承诺：完成的定义 完成的定义是在满足产品所需的质量度量时对增量状态的正式描述。

产品待办列表项满足完成定义的那一刻，一个增量就诞生了。

完成的定义通过让每个人都对作为增量的一部分完成的工作有共同的理解来创造透明度。如果一个产品待办列表项目不符合完成的定义，它就不能被发布，甚至不能在 Sprint 评审中展示。相反，它返回到产品待办列表以供将来考虑。

如果增量的完成定义是组织标准的一部分，则所有 Scrum 团队都必须至少遵循它。如果它不是组织标准，Scrum 团队必须创建适合产品的完成定义。

开发人员必须遵守完成的定义。如果有多个 Scrum 团队在一个产品上一起工作，他们必须相互定义并遵守相同的完成定义。

总结

Scrum 的框架结构通常由 “3 of 3s” 组成，即 3 种角色，3 种事件，3 种工件。

团队组成，3 种角色（Roles）

• 开发团队（Development Team）：一个自组织的跨技能的小团队，承担实际开发工作，负责在周期性的迭代中不断的交付有价值的工作。开发团队通过集体共同交付价值，而不是通过个体。
• 产品负责人（Product Owner）：产品负责人是产品最终用户的代表，负责确定产品的方向和愿景，定义产品发布的计划、内容和优先级。Product Owner 要不断的与开发团队沟通，保证团队在做从业务角度来说最正确的事情。
• Scrum 教练（Scrum Master）：Scrum 定义了一个全新的全职工作角色 Scrum Master。Scrum Master 负责确保团队合理的运作 Scrum，帮助团队移除实施中的障碍。

团队事件， 3 种事件（Events）

• 迭代计划会议（Sprint Planning Meeting）：在每个迭代之初，开发团队和 Product Owner 共同来计划在迭代周期内要完成的工作。Product Owner 负责向团队讲解要完成的工作的内容，开发团队负责对工作进行估计。
• 每日站立会议（Daily Standup Meeting）：每天，开发团队和产品负责人都要进行一个短暂的沟通。在会议期间，每个团队成员都要回答 3 个问题：“我昨天做了什么？”，“我今天准备做什么？”，“我遇到了什么问题？”。
• 迭代评审会议（Sprint Review Meeting）：在迭代周期结束时，开发团队向产品负责人及所有干系人进行演示，并接受反馈。

3 种工件（Artifacts）

• 产品待办列表（Product Backlog）：这是一个 Product Owner 想要交付的产品功能列表。 Product Owner 负责维护该列表，并且列表项按照交付优先级进行排序。
• 冲刺待办列表（Sprint Backlog）：这是一个迭代计划会议的输出，包含开发团队在迭代周期内所要完成的工作列表。
• 产品增量（Product Increment）：每个迭代周期都需要交付高质量的产品增量。产品增量必须满足 Scrum 团队对完成标准（Definition of Done）的定义。

随着时间的推移，Scrum 的 “3 of 3s” 框架也在不断的扩展。比如，很多团队发现在迭代结束时，通过回顾会议可以改进团队以交付更大的价值。所以，现在迭代回顾会议已经成为了框架中第 4 种会议。

• 迭代回顾会议（Sprint Retrospective Meeting）：在迭代周期结束时，Scrum 团队通过会议来对迭代的过程进行总结，以促使团队自我持续改进。
• 产品待办列表精化会议（Product Backlog Refinement Meeting）：通过会议的形式，对 Product Backlog 进行精化，以促进和加深团队对产品的理解。
• 项目计划会议（Project Planning Meeting）：项目启动会议。
• 产品发布计划会议（Product Release Planning Meeting）：制定产品发布的计划。

参考

https://www.cnblogs.com/gaochundong/p/what_is_scrum.html

https://scrumguides.org/scrum-guide.html#purpose-of-the-scrum-guide