Scrum（软件开发）
Scrum规定了团队的规定，以将工作分解为目标，以在被称为Sprints的时间盒迭代中完成。每个冲刺不超过一个月，通常持续两个星期。 Scrum团队评估了最多15分钟的时间盒，即每日Scrums的进度。在冲刺结束时，团队举行了两次会议：一项Sprint审查，以展示利益相关者的工作并征求反馈，以及一项内部Sprint回顾。负责Scrum团队的人通常称为Scrum Master 。
Scrum的产品开发方法涉及将决策授权提高到运营水平。与产品开发的顺序方法不同，Scrum是产品开发的迭代和增量框架。 Scrum允许持续反馈和灵活性，要求团队通过鼓励身体共同设置或关闭在线协作来进行自组织，并要求所有团队成员之间的频繁沟通。 Scrum的灵活和半计划的方法部分基于需求波动的概念，随着项目的发展，利益相关者将改变其要求。
历史
Scrum在软件开发中使用一词来自1986年的哈佛商业评论论文，名为“新产品开发游戏”， Hirotaka Takeuchi和Ikujiro Nonaka 。根据汽车，影印工和打印机行业的制造公司的案例研究，作者概述了一种新的产品开发方法，以提高速度和灵活性。他们称此为“橄榄球方法”，因为该过程涉及一个跨多个重叠阶段运作的单个跨职能团队，在该阶段中，团队“试图以一个单位进行距离，来回传球”。作者后来在他们的书《知识创建公司》中开发了Scrum。
在1990年代初期，肯·施瓦伯（Ken Schwaber）使用了他公司的高级开发方法中将成为Scrum。 Jeff Sutherland ，John Scumniotales和Jeff McKenna在Easel Corporation开发了类似的方法，指的是Scrum一词的方法。萨瑟兰（Sutherland）和施瓦伯（Schwaber）随后共同努力，将他们的想法整合到一个正式称为Scrum的单一框架中。施瓦伯（Schwaber）和萨瑟兰（Sutherland）对Scrum进行了测试并不断改进，导致了1995年的研究论文，并于2001年发表了敏捷软件开发宣言。Schwaber还与杜邦研究站的Babatunde Ogunnaike合作，以及德拉威大学（University of Delaware）开发Scrum。 Ogunnaike认为，如果产品管理不植根于经验实践，那么在初始条件变化时，软件开发项目通常会失败。
2002年，施瓦伯（Schwaber）与其他人建立了Scrum Alliance并建立了经过认证的Scrum认证系列。施瓦伯（Schwaber）于2009年底离开了Scrum Alliance，并随后创立了Scrum.org，负责监督平行的专业Scrum认证系列。自2009年以来，Schwaber和Sutherland发布并更新了一份名为Scrum指南的公共文件。它已被修订了6次，当前版本是2020年11月。
Scrum一词以前是Schwaber商标，但注册已失效。据推测，施瓦伯（Schwaber）允许其失效，目的是认识和实现该术语的广泛使用。
Scrum团队
Scrum团队至少组织了三类个人：产品主，开发人员和Scrum Master。产品主与利益相关者（对项目的结果感兴趣的利益相关者）联系，以与开发人员传达任务和期望。 Scrum团队中的开发人员自行组织工作，并促进了Scrum Master。理想情况下，Scrum团队应该遵守Scrum的五个值：承诺，勇气，专注，开放性和尊重。
产品拥有者
每个Scrum团队都有一个产品所有者。产品主专注于产品开发的业务方面，并花费大部分时间与利益相关者和团队联系。该角色旨在主要代表产品的利益相关者，客户的声音或委员会的欲望，并负责交付业务成果。产品所有者管理产品积压，这本质上是项目的运行待办事项列表，并负责最大化团队所提供的价值。他们不决定团队的技术解决方案，而是可能试图在团队成员之间寻求共识。
作为Scrum团队与利益相关者的主要联络人，产品所有者负责传达公告，项目定义和进度，RIDAS（风险，障碍，依赖和假设），资金和计划变化，产品积压和项目治理，以及项目治理，其他职责。产品所有者在必要时也可以取消冲刺，而无需团队成员的输入。
开发人员
在Scrum中， “开发人员或团队成员”一词是指任何在产品开发和支持中扮演角色的人，并且可以包括研究人员，建筑师，设计师，程序员等。
Scrum Master
Scrum由Scrum大师促进，其角色是教育和教练团队有关Scrum理论和实践。 Scrum Masters与传统团队负责人或项目经理的角色和责任不同。一些Scrum主责任包括教练，客观设置，解决问题，监督，计划，积压管理和沟通便利。另一方面，传统的项目经理通常承担人员管理责任，而Scrum Master没有。 Scrum团队不涉及项目经理，以最大程度地提高开发人员之间的自我组织。
工作流程
短跑
Sprint（也称为迭代，时机或设计冲刺）是固定的一段时间，团队成员在特定目标上进行工作。每个冲刺通常在一个星期到一个月之间，两个星期是最常见的。通常，举行日常会议，以讨论进行的项目进展以及团队成员所面临的困难。 Sprint的结果是功能可交付的，或者以增量获得了一些开发的产品。
当冲刺异常终止时，下一步是进行新的Sprint计划，其中审查了终止的原因。
每个冲刺都从一个冲刺计划活动开始，在该活动中定义了Sprint目标。从积压的人中选择了计划的冲刺的优先级。每个冲刺以两个事件结束：
- Sprint审查（显示出利益相关者以引起反馈的进展）
- Sprint回顾（确定下一个冲刺的课程和改进）
Scrum强调了每个冲刺结束时可行的产出，这使开发产品更接近市场成功。
冲刺计划
在冲刺开始时，Scrum团队举办了一项冲刺计划活动：
- 同意冲刺目标，即他们打算通过Sprint End实现的目标
- 识别有助于此目标的产品积压项目
- 通过选择应在Sprint中完成哪些已识别项目来形成Sprint积压
为期四周的冲刺，建议的Sprint计划的最大持续时间为八个小时。
每日混乱
每天在冲刺期间，开发人员每天都有特定准则（通常是站立的），并可以由Scrum Master促进。每天的Scrum会议的时间少于15分钟，每天在同一时间和位置举行。会议的目的是宣布在不进行任何详细讨论的情况下宣布对冲刺目标和可能阻碍目标的问题取得的进展。结束后，个别成员可以参加“突破性会议”或“派对后”进行扩展讨论和协作。 Scrum Masters负责确保团队成员有效地使用每日混乱，或者，如果团队成员无法使用它们，则可以提供替代方案以实现相似的成果。
事后事件
Sprint评论在Sprint结束时进行了一次会议，该会议的团队与利益相关者分享了他们完成的工作，并与他们联系，以反馈，期望和即将到来的计划。在Sprint审查中，已完成的可交付成果向利益相关者证明，他们也应该知道产品增量并正在进行中。 Sprint评论的建议持续时间为每周冲刺一小时。
Sprint回顾展是一次独立的会议，使团队成员可以内部分析冲刺的优势和劣势，未来的改进领域以及持续的流程改进行动。
积压精炼
积压改进是一个过程，团队成员修改并优先考虑将来冲刺的积压。它可以作为在新冲刺开始之前完成的单独阶段或团队成员自己工作的连续过程。积压精炼可以包括将大型任务分解为较小，更清晰的任务，成功标准的澄清以及对不断变化的优先级和回报的修订。建议在积压精炼上投资一支团队的冲刺能力的10％。
文物
文物是一种通过记录对项目的工作来管理产品开发的手段。所使用的主要混乱伪像是产品积压，Sprint Backlog和增量。
产品积压
产品积压是要完成的工作的细分，并包含团队为产品维护的产品要求的有序列表（例如功能，错误修复，非功能性要求）。产品积压的顺序对应于任务的紧迫性。积压项目的常见格式包括用户故事和用例。产品积压也可能包含产品所有者对业务价值的评估以及团队对产品的努力或复杂性的评估，可以使用圆形的斐波那契量表在故事点中说明。这些估计有助于产品所有者衡量时间表，并可能影响产品积压项目的顺序。
产品所有者根据风险，业务价值，依赖关系，规模和时机等考虑因素维护和优先考虑产品积压项目。积压待说顶部的高优先级项目被分解为开发人员进行工作的更详细信息，而在积压下进一步的任务可能更模糊。
冲刺积压
Sprint积压是产品积压的项目子集，旨在供开发人员在特定的冲刺中解决。开发人员用他们认为适合填补冲刺的任务填补了这一积压，并利用过去的性能评估其每个冲刺的能力。 Scrum方法具有任何特定个人或领导者分配给开发人员的Sprint积压的任务。团队成员通过根据积压优先级及其能力和能力和能力和能力和能力和能力和能力和能力和能力而自我组织。
增量
增量是Sprint的潜在释放输出，它符合Sprint目标。它是由所有已完成的Sprint积压项目组成的，该项目与所有以前的Sprint的工作集成在一起。理想的增量是完整的，功能齐全的，并且处于可用条件。
其他文物
燃烧图
经常在Scrum中使用，燃烧图是一张公开显示的图表，显示了其余工作。每天更新，它提供了快速的可视化供参考。燃烧图表的水平轴显示了剩余的天数，而垂直轴显示了每天剩余的工作量。在Sprint计划中，绘制了理想的燃烧图表。然后，在冲刺期间，开发人员使用剩余的工作更新图表，以便每天更新图表，显示实际和预测之间的比较。
释放燃烧图表
在每个冲刺的末尾进行更新，发布燃烧图表显示了提供预测范围的进度。释放燃烧图表的水平轴显示了释放中的冲刺，而垂直轴显示了每个冲刺末端完成的工作量。
速度
一些项目经理认为，可以通过评估上一个冲刺中完成的工作来得出团队对单个冲刺的全部能力。历史“速度”数据的收集是帮助团队了解其能力的指南。尽管如此，在Scrum从业者中，速度的概念一直存在争议。
限制
一些人认为，诸如日常混乱和混乱审查之类的Scrum事件会损害生产力和浪费时间，这可以更好地花在实际的生产任务上。实际上，许多Scrum从业人员进行的活动，例如日常混乱，作为一个扩展的讨论，而无需遵守时间盒的要求。
还观察到Scrum对许多类型的团队（包括兼职或地理上遥远的团队）构成困难；具有高度专业化的成员，最好是自己或在工作集团中工作；其中有许多外部依赖性破坏了计划的短冲刺的工作；并且不适合增量和开发测试。
改编
Scrum经常在不同的情况下量身定制或适应以实现不同的目标。适应Scrum的一种常见方法是Scrum与其他软件开发方法的组合，因为Scrum不涵盖整个产品开发生命周期。各种Scrum从业人员还提出了有关如何应用或适应特定问题或组织的更详细的技术。许多人将这些技术称为“模式”，这是一种在建筑和软件中设计模式的类似用途。
Scrimban
Scrumban是基于Scrum和看板的软件生产模型。为了说明每个工作阶段，在同一空间工作的团队经常使用后笔记或大型白板。 Scrumban特别适合使用频繁和意外的工作项目（例如生产缺陷或编程错误）进行产品维护。在这种情况下，尽管仍然可以应用Scrum的日常活动和其他实践，但时间限制的Scrum Sprint可能并不那么有益。同时，看板模型允许团队可视化工作阶段和限制。
混乱
Scrums是一种按大规模操作Scrum的技术，用于在同一产品上协调的多个团队。 Scrums Crums Daily Scrum会议涉及从每个团队中选出的大使，他们可能是开发人员或Scrum Master。作为协调的工具，Scrums允许团队共同处理整个团队风险，障碍，依赖关系和假设（RIDAS）（RIDAS），这些（RIDAS）可以在自己的积压中跟踪。
大规模混乱
大型Scrum（Light）是一个产品开发框架，它通过Bas Vodde和Craig Larman开发的各种规则和准则来缩放Scrum。较少的框架有两个级别：第一个较少的水平，最多可用于八支球队；第二层被称为“不太巨大”，可以适应涉及数百个开发人员的开发。
批评
一项系统的审查发现“分布式混乱没有影响，对整体项目成功没有影响，在分布式软件开发中”。
马丁·福勒（Martin Fowler）是《敏捷软件开发宣言》的作者之一，他批评了他所谓的“虚假”实践，这些实践“无视敏捷的价值观和原则”，以及“敏捷的工业复杂方法对人们相反”的敏捷工业综合方法。敏捷的原则是重视“个人和互动在流程和工具上”，并允许从事工作的个人决定工作的完成方式，改变过程以满足他们的需求。