Scrum 是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发。Scrum 包括了一系列实践和预定义角色的过程骨架。Scrum 中的主要角色包括同项目经理类似的 Scrum 主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
需求经常在变。当下成立的需求，可能过几天就是伪需求了。
于是经常会出现：一个团队花了大量的时间和资源却做出一个根本没有市场的产品。在瞬息万变的今天，试图预测用户需求已经变得几乎不可能了。
Scrum 敏捷开发是解决该问题的一个有效抓手。
在 1990 年代初，我们开发了 Scrum。在 2010 年，我们撰写首版 Scrum 指南，以帮助全世界的人们理解 Scrum。自那时起，我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。
Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的，这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则，将掩盖问题并限制 Scrum 的好处，甚至可能变得毫无用途。
我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到Scrum 在许多本质上具有复杂性的工作领域中被采用，超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大，开发者（developers）、研究人员、分析师、科学家和其他专家都能在工作中应用。因此，我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者，而是为了简化统称。如果您从 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 将四个正式事件组合在一起以在一个容器型事件 Sprint 中进行检视和适应。这5个事件之所以起作用，是因为它们实现了基于经验主义的 Scrum 的三个支柱：透明、检视和适应。
涌现的过程和工作成果必须对执行工作的人员和接受工作的人员都是可见的和一致理解的。在 Scrum 中，重要的决策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。
透明使检视成为可能。没有透明和共识的检视会产生误导和浪费。
Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问题。为了帮助检视，Scrum 以 5 个事件的形式提供了稳定的节奏。 检视使适应成为可能。没有适应的检视是毫无意义的。Scrum 事件旨在激发改变。
如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或过程处理的内容加以调整。调整工作必须尽快执行以最小化进一步的偏差。 当所涉人员没有得到授权或不能自管理时，则适应将变得更加困难。在通过检视学到任何新东西时，Scrum 团队会做出相应调整。
Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观：承诺， 专注， 开放， 尊重，勇气
Scrum 团队致力于达成其目标并且相互支持。他们主要专注于 Sprint 的工作，以便尽可能地向着这些目标获取最好的进展。Scrum 团队及其利益攸关者对工作和挑战持开放态度。Scrum 团队成员相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的人的尊重。Scrum 团队成员有勇气做正确的事并处理那些棘手的问题。
这些价值观为 Scrum 团队的工作、行动和行为指引方向。做出的决定、采取的步骤以及使用Scrum 的方式应强化这些价值观，而不是削弱或破坏它们。Scrum 团队成员通过 Scrum 事件和工件来学习和探索这些价值观。当 Scrum 团队和与他们一起工作的人们体现这些价值观时，基于经验主义的 Scrum 的三个支柱：透明、检视和适应，就成为现实，并在每个人之间构建信任。
Scrum 的基本单位是小团队，称为 Scrum Team。Scrum 团队由一名 Scrum Master，一名产品负责人和开发人员组成。在 Scrum 团队中，没有子团队或层次结构。Scrum 团队是具有凝聚力的专业团体，一次专注于一个目标，即产品目标。
Scrum 团队是跨职能的，这意味着团队成员具有在每个 Sprint 中创造价值而所需的全部技能。他们也是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。 Scrum 团队规模足够小以保持灵活，同时足够大以便可以在一个 Sprint 中完成有意义的工作，通常只有 10 人或更少。总的来说，我们发现较小的团队沟通更好，效率更高。如果 Scrum 团队变得太大，则应考虑将他们重组为多个具有凝聚力的 Scrum 团队，每个团队都专注于同一产品。因此，他们应该共享相同的产品目标、产品待办列表和产品负责人。 Scrum 团队负责所有与产品相关的活动，包括与利益攸关者的协作、验证、维护、运营、实验、研究和开发，以及可能需要进行的其他任何活动。组织组建并授权 Scrum 团队自行管理他们自己的工作。以可持续的速度在 Sprint 中工作可以提高 Scrum 团队的专注度和一致性。
整个 Scrum 团队都有责任在每个 Sprint 中创建有价值的、有用的增量。Scrum 在 Scrum 团队中定义了三种特定的职责担当（Accountability）：开发人员、产品负责人和 Scrum Master。
开发人员是 Scrum 团队中致力于创建每个 Sprint 可用增量的任何方面的人员。 开发人员所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。但是， 开发人员始终要负责：
- 为Sprint创建计划，即 Sprint 待办列表；
- 通过遵循完成的定义来注入质量；
- 每天根据 Sprint 目标调整计划；
- 和作为专业人士对彼此负责。
产品负责人负责将 Scrum 团队的工作所产生的产品价值最大化。如何做到这一点可能在组织、Scrum 团队和个体之间存在很大差异。
产品负责人还负责对产品待办列表进行有效管理，包括：
- 开发并明确地沟通产品目标；
- 创建并清晰地沟通产品待办列表项；
- 对产品待办列表项进行排序；
- 确保产品待办列表是透明的、可见的和可理解的。
产品负责人可以自己做上述工作，或者也可以将职责委托他人。然而无论如何， 产品负责人是担当最终责任的人。
为保证产品负责人取得成功，整个组织必须尊重他们的决定。这些决定在产品待办列表的内容和顺序中可见，并在 Sprint 评审会议时透过可检视的增量予以体现。
产品负责人是一个人，而不是一个委员会。在产品待办列表中，产品负责人可以代表许多利益攸关者的期望要求。那些想要改变产品待办列表的人可以尝试去说服产品负责人来做到这一点。
Scrum Master 负责按照 Scrum 指南的游戏规则来建立 Scrum。他们通过帮助 Scrum 团队和组织内的每个人理解 Scrum 理论和实践来做到这一点。
Scrum Master 对 Scrum 团队的效能负责。他们通过让 Scrum 团队在 Scrum 框架内改进其实践来做到这一点。
Scrum Masters 是真正的领导者，服务于 Scrum 团队和作为更大范围的组织。
Scrum Master 以多种方式服务于 Scrum 团队，包括：
- 作为教练在自管理和跨职能方面辅导 Scrum 团队成员；
- 帮助 Scrum 团队专注于创建符合完成的定义的高价值增量；
- 促使移除 Scrum 团队工作进展中的障碍；
- 和确保所有 Scrum 事件都发生并且是积极的、富有成效的，并且在时间盒内完成。
Scrum Master 以多种方式服务于产品负责人，包括：
- 帮助找到有效定义产品目标和管理产品待办列表的技巧；
- 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
- 帮助建立针对复杂环境的基于经验主义的产品规划；
当需要或被要求时，引导利益攸关者协作。Scrum Master 以多种方式服务于组织，包括：
- 带领、培训和作为教练辅导组织采纳 Scrum；
- 在组织范围内规划并建议 Scrum 的实施；
- 帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法；
- 消除利益攸关者和 Scrum 团队之间的隔阂。
Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的机会。Scrum 使用事件来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。最理想的是，所有事件都在同一时间同一地点举行，以便减少复杂性。
Sprint 是 Scrum 的核心，在这里创意转化为价值。
它们是固定时长的事件，为期一个月或更短，以保持一致性。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。
实现产品目标所需的所有工作，包括 Sprint 计划会议、每日 Scrum 会议、Sprint 评审会议和 Sprint 回顾会议，都发生在 Sprint 内。
在 Sprint 期间：
- 不能做出危及 Sprint 目标的改变；
- 不能降低质量；
- 产品待办列表按需进行精化；
- 随着学到更多，可以与产品负责人就范围加以澄清和重新协商。
Sprint 通过确保至少每个自然月一次对达成产品目标的进展进行检视和适应，来实现可预测性。当 Sprint 的时间长度拉得太长时，Sprint 目标可能会失效，复杂性可能会上升，同时风险可能会增加。可以使用较短的 Sprint 来产生更多的学习周期，并将成本与工作投入的风险限制在更短的一段时间内。每个 Sprint 都可以视为一个短期的项目。
存在各种各样的实践来预测进展，例如，燃尽图、燃起图或累积流图。尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生什么是未知的。只有已经发生的事情才能用来做前瞻性的决策。
如果 Sprint 目标已过时，那么就可以取消 Sprint。只有产品负责人拥有取消 Sprint 的权力。
Sprint 计划会议通过安排在 Sprint 中要做的工作来启动 Sprint。最终的计划是由整个 Scrum 团队协作创建的。
产品负责人要确保与会者准备好讨论最重要的产品待办列表项 ，以及它们如何映射到产品目标。Scrum 团队还可以邀请其他人参加 Sprint 计划会议以提供建议。
Sprint 计划会议处理以下话题：
产品负责人提议产品如何在当前的 Sprint 中增加其价值和效用。然后，整个 Scrum 团队将共同制定一个 Sprint 目标，用以沟通当前 Sprint 对利益攸关者有价值的原因。必须在 Sprint 计划会议结束之前最终确定 Sprint 目标。
通过与产品负责人讨论， 开发人员从产品待办列表中选择一些产品待办列表项，放入当前 Sprint 中。Scrum 团队可以在此过程中精化这些产品待办列表项，从而增加理解和信心。 选择在 Sprint 中可以完成多少任务可能会有挑战。但是，开发人员对他们以往的表现，他们在即将到来的 Sprint 内的产能以及对他们的完成的定义了解得越多，他们对 Sprint 预测就越有信心。
对于每个选定的产品待办列表项，开发人员都会规划必要的工作，以便创建符合完成的定义的增量。这通常是通过将产品待办列表项分解为一天或更短的较小项来完成的。开发人员自行决定如何完成这一工作。没有人告诉他们如何将产品待办列表项转化为价值的增量。
Sprint 目标、这次 Sprint 所选出的产品待办列表项加上如何交付它们的计划称之为 Sprint 待办列表。
Sprint 计划会议是有时间盒限定的，以一个月的 Sprint 来说最多为 8 个小时。对于更短的 Sprint，Sprint 计划会议所需时间通常会更短。
每日 Scrum 会议的目的是检视达成 Sprint 目标的进展，并根据需要调整适应 Sprint 待办列表，以调整即将进行的计划工作。
每日 Scrum 会议是一个属于 Scrum 团队的开发人员的 15 分钟的事件。为了降低复杂性，它在 Sprint 的每个工作日都在同一时间同一地点举行。如果产品负责人或 Scrum Master 正在积极处理 Sprint 待办列表上的项，那么他们将作为开发人员参与其中。
开发人员可以选择他们想要的任何举行每日 Scrum 会议的结构和技术，只要他们专注于实现 Sprint 目标的进展，并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。
每日 Scrum 会议改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。
每日 Scrum 会议并不是唯一一次允许开发人员调整计划的时间。他们可以在一天中任何时间碰面，详细讨论如何调整适应或重新规划 Sprint 的剩余工作。
Sprint 评审会议的目的是检视 Sprint 的成果并确定未来的适应性。Scrum 团队向关键利益攸关者展示他们的工作结果，并讨论产品目标的进展情况。
在 Sprint 评审会议期间，Scrum 团队和利益攸关者将评审在这次 Sprint 中完成了什么，以及环境发生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。产品待办列表也可能会进行调整以适应新的机会。Sprint 评审会议是一个工作会议，Scrum 团队应避免将其仅限于展示。
Sprint 评审会议是 Sprint 的倒数第二个事件，Sprint 评审会议是有时间盒限定的，以一个月的 Sprint 来说，最多为 4 个小时。对于更短的 Sprint，Sprint 评审会议通常所需的时间更短。
Sprint 回顾会议的目的是规划提高质量和效能的方法。
Scrum 团队检视最近 Sprint 中有关个体、交互、过程、工具和他们的完成的定义的情况如何。被检查的元素通常随工作领域而变化。识别使他们误入歧途的假设，并探究其起源。Scrum 团队讨论在 Sprint 期间哪些进展顺利，遭遇到哪些问题以及这些问题是如何解决（或未解决）的。
Scrum 团队识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个 Sprint 的 Sprint 待办列表中。
Sprint 回顾会议结束 Sprint。它是有时间盒限定的，以一个月的 Sprint 来说，最多为 3 个小时。对于更短的 Sprint， Sprint 回顾会议通常所需的时间更短。
Scrum 的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度。因此，为适应而检视它们的每个人对工件都有相同的基础。
每个工件都包含一个承诺，以确保它提供可增强透明度并聚焦于可度量进展的信息：
- 对于产品待办列表而言，它是产品目标。
- 对于 Sprint 待办列表而言，它是 Sprint 目标。
- 对于增量而言，它是完成的定义。 这些承诺的存在是为了强化经验主义和 Scrum 团队及其利益攸关者的 Scrum 价值观。
产品待办列表是一份涌现的和有序的清单，它列出了改进产品所需的内容。它是 Scrum 团队所承担工作的唯一来源。
能够被Scrum 团队在一个 Sprint 中完成（Done）的产品待办列表项被认为准备就绪，在 Sprint 计划会议事件中可供选择。它们通常在精化活动后获得这种透明度。产品待办列表精化是将产品待办列表项分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为产品待办列表项增添细节，例如描述、优先顺序和规模。这些属性通常随工作领域而变化。
将要做这项工作的开发人员负责使其适当的大小。产品负责人可以通过帮助开发人员理解和权衡取舍来影响他们。
产品目标描述了产品的未来状态，可以作为 Scrum 团队制定计划的目标。产品目标在产品待办列表中。产品待办列表的其余部分涌现，用来定义“做什么”将实现产品目标。 产品是传递价值的载体。它具有明确的边界、已知的利益攸关者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。
产品目标是 Scrum 团队的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一个目标。
Sprint 待办列表由 Sprint 目标（为什么做）、为 Sprint 选择的产品待办列表项（做什么）以及交付增量的可执行计划（如何做）组成。
Sprint 待办列表是开发人员为其制定的计划。它是开发人员在 Sprint 期间为实现 Sprint 目标而计划完成的工作，是一个高度可视且实时的工作画面。因此，随着学到更多，Sprint 待办列表在整个 Sprint 期间会进行更新。它应该有足够的细节，以便他们可以在每日 Scrum 会议中检视其进展。
Sprint 目标是 Sprint 的单个目标。尽管 Sprint 目标是开发人员的承诺，但它为实现该目标所需的确切工作方面提供了灵活性。Sprint 目标还创造了连贯性和专注点，鼓励 Scrum 团队一起工作而不是分开独自行动。
Sprint 目标在 Sprint 计划会议事件中确定，然后添加到 Sprint 待办列表中。当开发人员在 Sprint 期间工作时，他们将 Sprint 目标铭记在心。如果需要做的工作与预期的不同，他们将与产品负责人协作，在不影响 Sprint 目标的情况下，协商本次 Sprint 待办列表的范围。
一个增量是迈向产品目标的一块坚实垫脚石。每个增量都是之前所有的增量累加起来的，并经过彻底地验证，以确保整合在一起的所有增量都能工作。为了提供价值，增量必须是可用的。
在一个 Sprint 中可以创建多个增量。增量的总和在 Sprint 评审会议中展示，从而支持经验主义。但是，增量可以在 Sprint 结束之前交付给利益攸关者。Sprint 评审会议决不应该被视为发布价值的关口。
一项工作除非符合完成的定义，否则不能将其视为增量的一部分。
完成的定义是当增量符合产品所需的质量度量标准时对其状态的正式描述。 当一个产品待办列表项符合完成的定义时，就会产生一个增量。
完成的定义通过使每一个人对作为增量的一部分、什么样的工作算是已完成的工作有一个共同的理解来创建透明。如果一个产品待办列表项不符合完成的定义，那么它就不能发布，甚至不能在 Sprint 评审会议中展示它。相反，它返回到产品待办列表中以供将来考虑。
如果增量的完成的定义是组织标准的一部分，那么所有 Scrum 团队都必须以此为最低标准来遵守。如果它不是组织标准的一部分，那么 Scrum 团队必须制定适合于该产品的完成的定义 。
开发人员需要遵守完成的定义。如果有多个 Scrum 团队在同一产品上一起工作，那么他们必须一起制定并遵守同样的完成的定义。
自己所在公司推崇 Scrum 开发。也践行了很久的 Scrum 开发模式。然后公司也花钱在工作日请 Scrum 教练给大家上课，提供 Scrum 培训，自己最后也考了 Scrum Master 证书。
思考几个问题，来更好的理解 Scrum 敏捷开发模式。
- 快速迭代与反馈：通过较短周期的迭代方式，快速交付可用的软件功能，从而能更及、更早期获取用户或者市场的反馈。这些即时反馈可以使团队及时调整方向，动态满足客户需求和市场环境。
- 高度适应性：敏捷开发非常适合不断变化的项目需求。传统的瀑布开发模式，一旦需求变更后，往往需要重新规划、设计、开发，导致项目延期和一些潜在风险，而 Scrum 则通过灵活的迭代计划和调整，使得团队可以轻松硬对变化，甚至将变化转换为机会，从而保证项目的竞争力和市场的适应性
- 持续交付价值：Scrum强调在每个迭代周期结束时交付可用的软件增量，这意味着客户可以更早地看到产品的实际价值。这种持续交付的方式有助于增强客户的信心，同时也有助于团队及时发现问题并进行修复，确保最终交付的产品能够满足客户的期望。类似数学中积分的思想。不积小流无以成江海。
- 强化团队协作：Scrum敏捷开发强调跨职能团队之间的紧密协作和沟通。团队成员共同制定目标、计划和任务，通过每日站会、迭代评审和回顾会议等方式保持信息的实时共享和问题的及时解决。这种团队协作方式有助于打破部门壁垒，提高团队的凝聚力和工作效率。
- 不断改进：通过对每个 Sprint 结束后的回顾，团队有机会一起聊聊这个 Sprint 中的问题并提出建议，以改进问题，更好的开展下一个 Sprint 的工作。
这些优势，核心原因就是组建了一个相同价值观，认可敏捷开发文化的一群人，当然这群人不是随意组建的，而是同一个 Squad 内，最小可执行作战单元组成的，比如常见的配置是：一个 Scrum Master、一个产品 PM、一个产品设计师、2个 UI 设计师、2名 iOS、2名 Android、2个 Web 前端开发、3名后端开发，被组织任命，自管理。里面的开发基本都是资深工程师起步，有的会是技术专家。
然后按照 Sprint 一个周期去开发迭代，交付最小 MVP 的原则开展。一个 Sprint 可能就是2周。基于这些现状和共同任何的 Scrum 价值观，产品的开发迭代势必比较敏捷。
忽然觉得一个 Scrum 团队，和业务域有点相似，也有很大区别。假如你在做客户端，是一个电商业务，那么为了方便的开展工作和更聚焦，端上也划分了很多业务域，比如商品域、购物车域、营销域、订单域等等。区别在于开发所说的业务域一个是在面上的纵向划分。都是客户端 iOS 开发，商品域有10名 iOS 开发，其中1位是架构师，9位是开发主力。需求来了按照资源和人员闲置情况，安排任务。
但 Scrum 团队是为了区域自治，找了每个端所需要的人。
一个典型的工作流程是：
-
项目负责人（一般是 PM）牵头，和积分产品设计师，主持会议。会议主要目的是：根据前期和用户的沟通发现的产品问题、需求；结合公司战略考虑，当下需要做的一些 feature；对于线上的产品，主动发现或者用户咨询，对于一些不合理的流程进行优化，归纳整理出一些需要做的功能列表
-
继续召开会议，PM、产品负责人和 Squad 内各个端负责人（前端、客户端、后端、设计）召开会议，大致根据目前人力资源评估工期，基于优先级和工期综合排序，产出一个该 Sprint 的待办列表
-
一般一个 Sprint 周期为2周，即14天
-
然后开会同步需求和做一些会上的讨论。聊透需求
-
各团队调研编写技术方案，尽可能准确的评估开发周期（包括开发开始时间、单测时间、联调时间、提测时间等具体的时间节点。开发上下游互相有依赖的需要搞清楚依赖情况，确保时间是正确的）
-
各端项目时间交给 PM 看完，觉得没问题，大家就会在效率平台上创建任务。及时更新任务状态
-
每天会有 Sprint 的日会，大家同步下目前手头任务进度，有风险的提早暴露风险，看看是加配资源，还是个人加班消化，还是某些需求可以砍掉，起个分支保存代码，下个 Sprint 再上。
-
开发结束后，开始 ShowCase，各端演示各个 case 功能点
-
整个释放到市场后，找时间召开该 Sprint 的回顾会议，看看哪些点做得好，哪些点做的不好。及时更改，打造更好的团队。