Scrum是一个框架，可以帮助团队一起工作。就像橄榄球队（以此为名）为大型比赛训练一样，Scrum鼓励团队学习经验，在解决问题时自我组织，并反思自己的得失，以不断提高。
虽然我所谈论的Scrum最常被软件开发团队使用，但是它的原理和课程可以应用于各种团队合作。这是Scrum如此受欢迎的原因之一。人们通常认为Scrum是一种敏捷的项目管理框架，它描述了一系列会议，工具和角色，它们可以协同工作，以帮助团队构建和管理其工作。
在本文中，我们将在《Scrum指南》和Scrum.org首席执行官David West的帮助下讨论如何构成传统的Scrum框架 。我们还将提供一些示例，说明我们如何看待客户偏离这些基本要求以适应其特定需求。
框架
人们常常认为Scrum和敏捷是一回事，因为Scrum围绕着持续改进，这是敏捷的核心原则。但是，Scrum是敏捷完成工作的心态，是完成工作的框架。您不能真正做到“敏捷”，因为整个团队需要全心全意地改变他们考虑为客户提供价值的方式。但是您可以使用Scrum之类的框架来帮助您开始以这种方式思考，并在日常的沟通和工作中实践敏捷原则的构建。
Scrum框架是启发式的。它基于不断学习和对波动因素的调整。它承认团队在项目开始时并不了解所有内容，并且会通过经验不断发展。Scrum的结构旨在帮助团队自然地适应不断变化的条件和用户需求，并在流程中内置了重新优先级和较短的发布周期，因此您的团队可以不断学习和改进。
尽管Scrum是结构化的，但它并不完全僵化。它的执行可以根据任何组织的需求进行定制。关于成功的Scrum团队必须如何工作的理论很多。但是，在帮助敏捷团队在Atlassian上完成工作十多年之后，我们了解到清晰的沟通，透明性以及对持续改进的奉献始终应始终是您选择的任何框架的核心。其余的取决于您。
Scrum工件
让我们从识别Scrum中的三个工件开始。人工制品是我们制造的东西，就像解决问题的工具一样。在Scrum中，这三个工件是产品待办事项列表，冲刺待办事项列表以及定义为“完成”的增量。这是Scrum团队中的三个常量，我们会继续进行考察并长期投资。
- 产品待办列表是产品所有者或产品经理维护的需要完成的工作的主列表。这是功能，要求，增强功能和修复程序的动态列表，可作为sprint待办事项的输入。从本质上讲，它是团队的“待办事项”列表。产品负责人会不断地重新审查，重新安排产品的优先级并进行维护，因为随着我们了解更多或随着市场变化，项目可能不再相关或其他问题可能得到解决。
- Sprint待办事项列表是开发团队选择在当前sprint周期中实施的项目，用户案例或错误修复的列表。在每次冲刺之前，在冲刺计划会议（我们将在本文后面讨论）中，团队从产品待办事项列表中选择对冲刺将处理哪些项目。冲刺积压可能是灵活的，并且可以在冲刺期间演进。但是，基本的sprint目标（团队希望从当前的sprint中实现）是不能妥协的。
- 增量（或冲刺目标）是冲刺的可用最终产品。在Atlassian，我们通常会在冲刺结束演示期间演示“增量”，团队在该演示中显示冲刺已完成的过程。您可能不会听到“递增”这个词，因为它通常被称为团队对“完成”的定义，里程碑，冲刺目标，甚至是完整版本或已发布的史诗。这仅取决于您的团队如何定义“完成”以及如何定义冲刺目标。例如，某些团队选择在每次冲刺结束时向其客户发布一些东西。因此，他们对“完成”的定义将被“装运”。但是，这对于其他类型的团队可能并不现实。假设您使用的是基于服务器的产品，该产品每季度只能交付给客户。您可能仍然选择在2周的冲刺中工作，但是您对“完成”的定义可能正在完成打算一起运输的较大版本的一部分。但是，当然，发布软件花费的时间越长，软件遗漏标记的风险就越高。
如您所知，您的团队可以选择定义很多变化，甚至在工件内部也可以。这就是为什么保持开放状态以保持甚至保持文物的发展的重要性。也许您对“完成”的定义给您的团队带来了巨大的压力，因此您需要返回并选择一个新的定义。
专家提示
您应该像对待产品一样灵活地使用框架。花必要的时间检查进展情况，必要时进行调整，不要仅仅为了保持一致性就强加于人。
Scrum仪式或事件
Scrum框架中一些比较知名的组件是Scrum团队定期执行的一系列顺序事件，仪式或会议。仪式是我们为团队带来最多变化的地方。例如，有些团队发现所有这些仪式的执行都是繁琐且重复的，而另一些团队则将它们用作必要的签到。我们的建议是开始将所有仪式用于两次冲刺，然后看一下感觉。然后，您可以进行快速回顾，并查看可能需要调整的地方。
以下是Scrum团队可能参加的所有关键仪式的列表：
- 组织积压：有时称为积压整理，此事件是产品所有者的责任。产品负责人的主要工作是推动产品实现其产品愿景，并在市场和客户上保持不断的发展。因此，他/她使用用户和开发团队的反馈来维护此列表，以帮助确定优先级并保持列表整洁，并随时可以进行处理。您可以在此处阅读有关保持健康积压的更多信息。
- Sprint计划：整个开发团队在这次会议期间计划当前Sprint期间要执行的工作（范围）。这次会议是由Scrum主管领导的，是团队确定sprint目标的地方。然后，将特定的使用案例从产品待办事项列表添加到sprint中。这些故事始终与目标保持一致，并且Scrum团队还同意在短跑期间实施这些故事是可行的。
在计划会议结束时，每个Scrum成员都需要清楚在sprint中可以传递什么以及增量如何传递。 - 冲刺：冲刺是Scrum团队一起完成增量工作的实际时间段。对于冲刺来说，通常需要两周的时间，尽管有些团队认为一周的范围更容易确定，而一个月的时间更容易实现有价值的增长。来自Scrum.org的Dave West建议，工作越复杂，未知数越多，冲刺应该越短。但这实际上取决于您的团队，如果它不起作用，您不必害怕对其进行更改！在此期间，如有必要，可以在产品所有者和开发团队之间重新协商范围。这形成了Scrum经验性的症结。
从策划到回顾的所有事件都发生在冲刺期间。一旦为冲刺确定了一定的时间间隔，就必须在整个开发期间保持一致。这有助于团队从过去的经验中学习，并将这种见识应用于未来的冲刺。 - 每日Scrum或站立会议：这是每天（通常是早晨）在同一时间举行的超短会议，并保持简单。许多团队尝试在15分钟内完成会议，但这只是一个指导。这次会议也称为“每日站立”，强调它需要快速召开。日常Scrum的目标是使团队中的每个人信息保持一致，与sprint目标保持一致，并制定下一个24小时的计划。
站立会议是时候表达您对达到冲刺目标或任何阻碍因素的疑虑。
站立会议的一种常见方法是让每个团队成员在实现冲刺目标的情况下回答三个问题：
•我昨天做了什么？
•我今天打算做什么？
•是否有障碍？
但是，我们已经看到会议迅速变成了闲聊，从昨天和第二天开始过人们的日常工作安排。但是站立会议的理论是，它会使日常会议上的闲聊分散注意力，因此团队可以将精力集中在一天的其余时间。所以假如它变成了日常日照本宣科，请不要害怕修正此问题。
- Sprint审查：在Sprint结束时，团队聚在一起举行非正式会议，以查看增量演示或检查增量。开发团队向利益相关者和队友展示了已“完成”的待办事项，以征求反馈。产品所有者可以决定是否释放增量，尽管在大多数情况下，释放增量。
产品所有者根据当前的Sprint重新设计积压的产品时，也可以参加此次审核会议，这可以反馈到下一个Sprint计划会话中。对于一个月的冲刺，请考虑将您的冲刺审阅装箱至多四个小时。 - Sprint回顾：在回顾是所在球队走到一起，以记录和讨论什么工作，什么样的冲刺，项目，人或关系，工具，甚至对某些仪式都没有工作。这样做的想法是创建一个团队可以集中精力进行下一步工作以及下一步需要改进的地方，而较少关注发生问题的地方。
Scrum成功的三个基本角色
Scrum团队需要三个特定角色：产品所有者，Scrum管理员和开发团队。而且由于Scrum团队是跨职能的，因此开发团队除开发人员外还包括测试人员，设计师，UX专家和操作工程师。
Scrum产品负责人
产品负责人是他们产品的拥护者。他们专注于了解业务，客户和市场需求，然后优先安排工程团队要完成的工作。有效的产品所有者：
- 构建和管理产品积压。
- 与业务和团队紧密合作，以确保每个人都了解产品积压工作中的工作项。
- 为团队提供下一步要提供的功能的明确指导。
- 决定何时发货时倾向于更频繁地发货。
产品负责人并不总是产品经理。产品负责人致力于确保开发团队为企业带来最大的价值。同样，产品所有者必须是个人，这一点也很重要。没有开发团队想要多个产品所有者的混合指导。
Scrum大师
Scrum大师是团队中Scrum的拥护者。他们在Scrum流程中指导团队，产品所有者和业务，并寻找微调其实践的方法。
一个有效的Scrum主管深刻理解团队正在完成的工作，可以帮助团队优化其透明度和交付流程。作为总主持人，他/她为冲刺计划，站立，冲刺审查和冲刺回顾计划了所需的资源（人力和后勤）。
Scrum开发团队
Scrum团队完成既定任务。他们是可持续发展实践的倡导者。最有效的Scrum团队是紧密合作的，并在同一地点，通常有5至7名成员。确定团队规模的一种方法是使用亚马逊首席执行官杰夫·贝佐斯（Jeff Bezos）提出的著名的“两个比萨饼规则”（团队应足够小，可以共享两个比萨饼）。
团队成员具有不同的技能，并且彼此交叉培训，因此没有人会成为工作交付的瓶颈。强大的Scrum团队会自我组织，并以清晰的“我们”态度进行项目。团队的所有成员互相帮助，以确保成功完成冲刺。
Scrum团队为每个冲刺制定计划。他们以历史速度为指导，预测他们认为可以在迭代中完成的工作量。保持迭代长度不变，可以为开发团队提供有关其估计和交付过程的重要反馈，从而使他们的预测随着时间的推移越来越准确。
Scrum，看板和敏捷
Scrum是一种非常流行的敏捷框架，以至于Scrum和敏捷经常被误解为同一件事。但是还有其他框架，例如看板（kanban），这是一个受欢迎的替代方案。一些公司甚至选择遵循Scrum和看板的混合模型，后者已经获得了’Scrumban’或Kanplan的名称，这是看板的积压。
Scrum和看板都使用视觉方法，例如Scrum板或看板来跟踪工作进度。两者都强调效率并将复杂的任务分解为较小的可管理工作部分，但是它们实现该目标的方法不同。
Scrum专注于较小的定长迭代。一旦确定了冲刺的时间段，便可以确定可以在此冲刺周期内实施的故事或产品积压条目。但是，在看板中，当前周期要执行的任务数或进行中的工作（WIP限制）首先是固定的。然后，将实现这些功能所需的时间反向计算。
看板不像Scrum那样结构化。除了在制品限制之外，它还可以公开解释。但是，Scrum在实施过程中强制执行了几个类别概念，例如sprint审查，回顾，每日Scrum等。它还坚持跨功能，这是Scrum团队不依赖外部成员来实现的能力。他们的目标。放在一起跨职能团队并不简单。从这个意义上讲，看板更容易适应，而Scrum可以被认为是开发团队的思维过程和功能的根本转变。
但是，为什么要争吵？
Scrum框架本身很简单。规则，工件，事件和角色很容易理解。它的半规范性方法实际上有助于消除开发过程中的歧义，同时为公司提供了足够的空间向其介绍其个人风格。
将复杂任务组织成可管理的用户故事使其成为困难项目的理想选择。而且，角色和计划中事件的明确划分确保了在整个开发周期中都具有透明性和集体所有权。快速发布可以保持团队的积极性，使用户感到高兴，因为他们可以在短时间内看到进度。
但是，Scrum可能需要花费一些时间来掌握，特别是如果开发团队已适应典型的瀑布模型。对于新团队而言，较小的迭代，每日的Scrum会议，Sprint审查以及确定Scrum管理员的概念可能是具有挑战性的文化转变。
但是，长期收益远远超过了最初的学习曲线。Scrum在跨不同行业和垂直领域开发复杂的硬件和软件产品方面的成功使它成为您的组织采用的引人注目的框架。
