Scrum
Scrum 指南：它是什么、它的工作原理以及如何开始
什么是 Scrum？
Scrum 是一个敏捷的项目管理框架，可帮助团队通过一系列价值观、原则和实践来组织和管理他们的工作。就像橄榄球队（其名字也源于此）为准备大型比赛而进行培训那样，Scrum 鼓励团队吸取经验，在处理问题时进行自我组织，并通过反思得失实现持续改进。
虽然我谈论的 Scrum 是软件开发团队最常用的工具，但它的原则和经验教训可用于各种团队合作。这是 Scrum 如此受欢迎的原因之一。Scrum 通常被认为是一个敏捷开发项目管理框架，它描述了一组协同工作的会议、工具和角色，以帮助团队组织和管理其工作。
在本文中，我们将在 Scrum 指南和 Scrum.org 首席执行官 David West 的帮助下，讨论如何构建传统的 Scrum 框架。我们还将举例说明我们如何看待客户偏离这些基本原则以满足其特定需求。为此，我们的 Jira Software 集团产品经理、前敏捷开发教练 Megan Cook 将在我们的敏捷开发教练系列视频中介绍一些提示和技巧：
免费开始使用 Jira Scrum 模板
简化您的项目，轻松规划、跟踪和管理涉及多个冲刺的工作。Jira Scrum 模板包括看板、待办事项列表、路线图、报告等！
敏捷与 Scrum
人们通常认为 Scrum 和敏捷是同一回事，因为 Scrum 关注持续改进，而这是敏捷的核心原则。但是，Scrum 是完成工作的框架，而敏捷是一种理念。敏捷理念侧重于通过小规模和频繁的发布进行持续的渐进改进。您无法真正“敏捷化”，因为这需要整个团队一致努力才能改变其向客户交付价值的思维方式。但是，您可以使用 Scrum 等框架来协助您开始思考这一方式，并在日常沟通和工作中实践如何构建敏捷原则。
敏捷和 Scrum 的定义之间的区别可以在 Scrum 指南和敏捷宣言中找到。敏捷宣言概述了四个价值观：
- 个人和交互优先于流程和工具
- 工作软件优先于全面的文档
- 客户合作高于合同谈判
- 响应变化优先于遵循计划
Scrum 的定义基于经验主义和精益思维。经验主义说，知识来自经验，决策是根据所观察到的情况做出的。精益思维可以减少浪费，并专注于本质。Scrum 框架是一种基于持续学习和波动因素调整的启发式框架。它承认团队在项目开始时并不了解所有内容，并通过吸取经验教训不断发展。Scrum 的结构旨在帮助团队自然而然地适应不断变化的条件和用户要求，并在流程和较短的发布周期中重新调整优先级，以便您的团队不断学习和改进。
虽然 Scrum 是结构化框架，但它并不是完全僵化的。您可以根据组织需求调整其执行。关于 Scrum 团队如何才能成功，有许多理论。但是，十多年来，在帮助 Atlassian 敏捷开发团队完成工作的过程中，我们发现，无论您选择何种框架，清晰的沟通、透明度和致力于持续改进始终都是框架的核心。剩下的，就得靠您自己了。
Scrum 团队
Scrum 团队是一个小而灵活的团队，致力于提供承诺的产品增量。Scrum 团队的规模通常很小，大约 10 人，但它足够大，足以在冲刺中完成大量工作。Scrum 团队需要三个特定角色：产品负责人、Scrum 主管和开发团队。由于 Scrum 团队跨职能部门，所以“开发团队”除了开发人员之外，还包括测试人员、设计人员、用户体验专家和运维工程师。
Scrum 产品负责人
产品负责人是产品方面的佼佼者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能：
- 构建和管理产品待办事项。
- 与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。
- 明确指导团队接下来提供哪些功能。
-
确定何时发布产品，且倾向于更频繁地交付产品。
产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。
Scrum 主管
Scrum 主管是其团队中在 Scrum 方面的佼佼者。他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法细调他们在此方面的实践。
高效的 Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为首席推动者，此角色负责安排冲刺规划、每日短会、冲刺审核和冲刺回顾所需的资源（人力和物力）。
Scrum 开发团队
Scrum 团队是具体工作的执行者。他们是可持续发展实践方面的佼佼者。效率最高的 Scrum 团队关系紧密、同地协作，且成员通常为 5 到 7 名。确定团队规模的一种方法是遵循 Amazon 首席执行官 Jeff Bezos 提出的著名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。
团队成员具有不同的技能，并且彼此互相锤炼，因此没有人会成为交付工作的瓶颈。强大的 Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成冲刺。
Scrum 团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。
Scrum 工件
Scrum 工件是 Scrum 团队使用的重要信息，可帮助定义产品以及创建产品需要做哪些工作。Scrum 中有三种工件：产品待办事项、Sprint 待办事项以及您对“完成”的定义的增量。Scrum 团队应在冲刺期间和一段时间内回顾这三个常数。
- 产品待办事项是产品负责人或产品经理需要完成的主要工作列表。它是功能、要求、增强功能和修复的动态列表，并用作冲刺待办事项的输入。本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或是可能会以其他方式解决问题。
- 冲刺待办事项是开发团队为实现当前冲刺周期而选择的项目、用户故事或缺陷修复列表。每次冲刺之前，在冲刺规划会议（我们将在后文进行讨论）中，团队从产品待办事项中选择为进行冲刺而处理的项目。冲刺待办事项可能较为灵活，可以在冲刺期间发展。但是，基本的冲刺目标（团队希望通过在当前冲刺中实现的目标）不能受到影响。
- 增量（或冲刺目标）是冲刺阶段中可用的最终产品。在 Atlassian，我们通常会在冲刺结束演示期间展示“增量”，而团队则会展示在冲刺期间完成的内容。在此领域之外，您可能不会听到“增量”一词，因为它通常是指团队对“已完成”、里程碑、冲刺目标，甚至是完整版本或已交付长篇故事的定义。这只取决于您的团队如何定义“已完成”以及您如何定义冲刺目标。例如，某些团队选择在每次冲刺结束时向客户发布某些东西。因此，他们对“已完成”的定义将是“已发货”。但对其他团队而言，则可能并非如此。假设您使用的是基于服务器的产品，该产品只能每季度发送给客户。您仍可选择在为期 2 周的冲刺中工作，但是，您对“已完成”的定义可能只是完成您计划一起发布的更大版本的其中一部分。当然，发布软件所需的时间越长，软件错过标记的风险就越高。
如您所知，您的团队可以选择定义很多变体，即使是在工件内也是如此。这便是为何必须对工件维护方式保持开放态度的原因。也许您对“已完成”的定义会给您团队减压，且您需要返回并选择一个新的定义。
您应该像处理产品一样敏捷地处理框架。花一些必要的时间来检查事务的进展情况，并在必要时做出调整，而不要仅仅为了一致性而强迫自己执行某些事项。
Scrum 仪式或事件
Scrum 框架包括 Scrum 练习、仪式和 Scrum 团队定期举行的会议。敏捷仪式是我们看到团队差异最多的地方。例如，有些团队发现举办所有这些仪式既繁琐又重复，而另一些团队则将其用作必要的登记手段。我们的建议是，在两次冲刺阶段使用所有仪式，然后看看其效果。接着，您可以进行快速回顾，看看可能需要进行哪些调整。
以下是 Scrum 团队可能参加的所有重要仪式清单：
-
组织待办事项列表：有时也被称为待办事项梳理，它由产品负责人负责。产品负责人的主要工作是协助实现产品愿景，并持续关注市场和客户。因此，客户可根据用户和开发团队的反馈来维护此列表，以协助确定列表的优先级并保持整洁，同时准备在任意给定时间进行工作。您可在此处了解有关维护正常待办事项列表的更多信息。
-
冲刺规划：当前冲刺期间要执行的工作（范围）将由整个开发团队在本次会议期间进行规划。此会议将由 Scrum 主管主持，且会在此期间由团队决定冲刺目标。然后，产品待办事项中的特定用户故事会被添加到冲刺中。这些故事始终与目标一致，并且经过 Scrum 团队的同意，在冲刺期间实施是可行的。
在规划会议结束时，每个 Scrum 成员都需要明确在冲刺中可以交付什么以及如何实现更多。 -
冲刺：冲刺是 Scrum 团队共同完成增量的实际时间段。两周是一个相当典型的冲刺时长，尽管某些团队发现一周更容易确定范围，或是一个月更容易提供有价值的增量变化。Scrum.org 的 Dave West 建议，工作越复杂，未知因素就越多，而冲刺就应该越短。但事实上，这取决于您团队；而如果不起作用，您也不应畏惧改变！在此期间，必要时可由产品负责人和开发团队重新协商范围。这构成了 Scrum 经验本质的关键。
所有事件（从规划到回顾）都是在冲刺期间发生的。一旦确定了冲刺的特定时间间隔，就必须在整个开发期间保持一致。这有助于团队吸取经验教训，并将这些洞察应用于未来的冲刺。 -
每日 Scrum 或简短例会：这是每天在同一时间（通常是早晨）和地点举行的超短例会，以确保此会议简洁明了。很多团队试图在 15 分钟内完成会议，但这只是一个参考。此会议也被称为“每日短会”，它强调需快速举行会议。每日 Scrum 旨在让团队中的每一个成员都保持同步，共同朝着冲刺目标努力，并制定未来 24 小时的计划。
您可在每日短会上说出自己在实现冲刺目标或解决任何障碍时遇到的问题。
每日短会的其中一种常见举行方法是让每个团队成员在实现冲刺目标的过程中回答三个问题：
• 我昨天做了什么？
• 我今天打算做什么？
• 是否存在障碍？
然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是，它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。 -
冲刺审核：在冲刺结束时，团队聚集在一起进行非正式会议，以观看增量演示或检查增量。开发团队向利益相关者和团队成员展示目前处于“已完成”状态的待办事项，以征求他们的反馈意见。尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。
此次审核会议也是产品负责人根据当前冲刺重新处理产品待办事项之时，当前冲刺可为下一次冲刺规划会议提供相关信息。对于为期一个月的冲刺，可考虑将您的冲刺审核时间限制为最长四个小时。 -
冲刺回顾：回顾是指团队聚集在一起共同记录和讨论冲刺、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。我们的思路是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待改进，而不是专注于出了什么问题。
免费开始使用 Jira Scrum 模板
Scrum 价值观
2016 年，Scrum 指南添加了五个 Scrum 价值观。这些价值观为 Scrum 团队的工作、行动和行为提供了指导。它们对于 Scrum 团队的成功至关重要。
承诺
Scrum 团队规模小且敏捷，每个团队成员都对团队的成功起着重要作用。因此，每个团队成员都应同意承担自己可以完成的任务，而不是过度投入。应经常就工作进展进行沟通，通常采用站会形式。
勇气
对于 Scrum 团队来说，勇气就是勇于质疑现状或任何阻碍其成功的东西。Scrum 团队成员应该有勇气尝试新事物，并感到足够安全。Scrum 团队应该有勇气和安全感，对障碍、项目进度、延误等情况保持透明。
重点
Scrum 团队工作流程的核心是冲刺，这是一段有针对性的特定时段，团队在此期间完成一定数量的工作。冲刺不仅提供了结构，还能集中精力完成计划的工作量。
开放性
每日站会可以促进开放性，让团队可以公开谈论正在进行的工作和障碍。在 Atlassian，我们的 Scrum 团队经常会解决以下问题：
- 我昨天做了什么？
- 今天要做什么？
- 哪些问题阻碍了我？
这有助于突出进展并发现障碍。每个人都分享进展时，还有助于加强团队力量。
尊重
敏捷团队的优势在于其协作，并认识到每个团队成员都在冲刺中为工作做出了贡献。他们互相庆祝成就，并尊重彼此、产品负责人、利益相关者和 Scrum 主管。
Scrum、看板和敏捷开发
Scrum 是一种非常流行的敏捷开发框架，以至于 Scrum 和敏捷开发经常被误认为是同一回事。此外，还有一些框架（如看板）也是较受欢迎的选择。某些公司甚至选择使用 Scrum 和看板的混合模式，后者也亦称为“Scrumban”或“Kanplan”，这是一种附带待办事项列表的看板。
Scrum 和看板都采用可视化方法（例如 Scrum 板或看板）来跟踪工作进度。两者都强调效率，并将复杂的任务分成可管理的较小工作，但它们实现目标的方法却各有不同。
Scrum 专注于固定长度的小型迭代。一旦最终确定冲刺的时间段，便可确定在此冲刺周期内可实施的故事或产品待办事项条目。但在看板中，首先需确定当前周期内要实施的任务数量或正在进行的工作（WIP 限制）。然后，向后计算实施这些功能所需的时间。
看板的结构化程度不如 Scrum。除了 WIP 限制之外，它的解释是相当开放的。但是，Scrum 在实现过程中必须强制实施几个明确的概念，如冲刺审核、回顾、每日 Scrum 等。此外，它还坚持跨职能。换言之，Scrum 团队无需依赖外部成员就能够实现目标。组建跨职能团队并非易事。从此意义而言，看板更容易适应，而 Scrum 则可视为开发团队思维过程和运作方式的根本性转变。
开始使用 Scrum
Scrum 框架本身很简单。规则、工件、事件和角色都不难理解。其半规范性方法实际上有助于消除开发过程中的歧义，同时可为公司提供足够的空间来引入自己的个性风格。
Scrum 可将复杂的任务组织成易于管理的用户故事，是棘手项目的理想之选。此外，明确划分角色和规划开展的活动可确保整个开发周期的透明度和集体自主权。快速发布可保持团队的积极性和用户满意度，因为他们可以在短时间内看到工作进展。
但是，我们可能需要时间才能充分了解 Scrum，特别是在开发团队适应典型的瀑布模型时。小型迭代、每日 Scrum 会议、冲刺审核和确定 Scrum 主管的概念对于新团队来说可能是具有挑战性的文化转变。
但是，长期的好处远远超过最初的学习曲线。Scrum 在跨不同行业和垂直领域开发复杂的硬件和软件产品方面取得的成功，使其成为满足贵组织需求的卓越框架。
如需学习 Jira Software 的 Scrum，请查阅本教程。
