Scrum 是符合敏捷开发原则的一种典型且在全球使用最为广泛的框架，它用于复杂产品的开发。本文将介绍包括 Scrum 的角色、事件（仪式）、工件，以及把它们组织在一起的规则等内容。
Scrum 是一个帮助团队更好协作的框架。就像橄榄球队（它的名字的由来）为赢得大型比赛进行集训一样，Scrum 鼓励团队从经验中学习，以自组织的方式去处理问题，并对他们的胜利和失败反思，不断改进。虽然 Scrum 通常是被软件开发团队使用，但它的原则和经验可用于各种团队合作，这也是 Scrum 如此受欢迎的原因之一。
Scrum 通常被认为是一个敏捷项目管理框架，它描述了一组帮助协同工作的事件、工件和角色，旨在帮助团队更高效的组织和管理其工作。
Scrum 相关文章
人们通常认为 Scrum 和敏捷开发是同一回事，因为 Scrum 关注持续改进，而这也是敏捷开发的核心原则。但是，Scrum 是完成工作的一种框架，而敏捷开发是一种思维模式。
并且，仅凭 Scrum 你无法真正“敏捷化”，因为这需要整个团队一致努力，才能改变组织向客户交付价值的思维方式。但是，你可以使用 Scrum等框架来协助你开始思考这一方式，并在日常沟通和工作中实践如何构建敏捷工作流原则。
Scrum 框架是一种基于持续学习和需求多变的启发式框架。它承认团队在项目开始时并不了解所有内容，要求团队吸取经验教训不断发展。Scrum 框架旨在帮助团队自适应不断变化的外部环境和用户要求，并在流程和较短的发布周期中快速调整优先级，以便团队不断学习和改进。
虽然 Scrum 是结构化框架，但它并不是完全僵化的，你可以根据组织需求调整其执行。关于 Scrum 团队如何才能成功有很多的理论。但是，十多年来，在帮助 PingCode 敏捷团队达成工作目标的过程中，我们发现，无论你选择何种框架，沟通、透明、持续改进始终都是框架的核心。
Scrum 团队需要三个特定角色：Product Ower（产品负责人）、Scrum（敏捷教练）和 Scrum 团队。由于 Scrum 团队为跨职能部门，因此除开发人员之外，开发团队还包括测试人员、设计人员、用户体验 (UX) 专家和运营工程师等等。
主要负责构建正确的产品，确定 Scrum 团队交付什么，并解释为什么做这些工作。Product Ower 是产品方面的佼佼者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。
高效的产品负责人应能：
- 构建和管理产品待办事项（Product Bcklog）。
- 与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。
- 明确指导团队接下来提供哪些功能。
- 确定何时发布产品，且倾向于更频繁地交付产品。
产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。
主要负责帮助产品负责人和开发团队中的每个人理解和拥抱 Scrum 的价值观、原则和实践，确保 Scrum 流程顺利进行。
Scrum master 是其团队中 Scrum 方面的佼佼者，他们负责对团队、产品负责人、企业进行 Scrum 流程方面的培训，并寻找方法持续优化他们在此方面的实践。
高效的 Scrum Master 应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为最主要的推动者，此角色负责安排迭代规划、每日站会、迭代评审和迭代回顾所需的资源（人力和物力）。
负责以正确的方式构建产品，执行具体工作任务。Scrum 团队是具体工作的执行者，成员通常为 5 到 9 名（并不绝对）。确定团队规模的一种方法是亚马逊首席执行官 Jeff Bezos 提出的著名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。
团队成员具有不同的技能，并且彼此互相学习成长，因此没有人会成为交付工作的瓶颈。强大的 Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成迭代。
Scrum 团队可推进每个迭代的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。
Scrum 工件是团队要完成的事情，就像是解决问题的工具。在 Scrum 中，常见的三个工件分别是 Product Backlog（产品待办事项）、Sprint Backlog（迭代待办事项），以及你对“DoD（已完成）”定义的增量变化。它们是 Scrum 团队中的三个常量，团队需要不断地对其进行重新审视，并投入额外的时间进行改进。
Product Backlog 是整个产品的用户故事集合，这些用户故事可以来自甲方客户、Product Ower 自己对产品的理解、研发团队、公司战略规划拆解等等。
本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或者优先级出现调整等等。
Sprint Backlog 指的是在一个迭代周期中要完成的用户故事列表。这些用户故事来自 Product Backlog，每次迭代前，Product Ower 根据交付价值，将优先级最高的用户故事放入迭代。
每次进入迭代之前，团队需要召开迭代规划会议，团队从 Product Backlog 中选择本次迭代计划完成的需求。迭代待办事项可能较为灵活，也可以在迭代期间变化。但是，基本的迭代目标（团队希望通过在当前迭代中实现的目标）不能受到影响。
增量是指在一个 Sprint 中完成的所有 Product Backlog 的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。
在完成以上三个工件的时候，团队可以选择定义很多变体，因为工件维护最好保持开放态度。比如对“已完成”、“故事点”重新定义，能更好的提升效率和品质，那你完全可以根据需求进行新的定义。
Tips：你应该像处理产品一样敏捷地处理 Scrum 框架，花一些必要的时间来检查事务的进展情况（无论是通过 PingCode 这样的工具或者是其他），并在必要时做出调整，而不要仅仅为了一致性而强迫自己执行某些事项。
Scrum 框架还包括 Scrum 团队定期举行的一系列仪式。通过这些仪式，我们可以看到团队之间的差异。
例如，有些团队发现举行所有这些仪式既繁琐又重复，而另一些团队则将这些仪式作为必要的信息共享环节。而我们的建议是，在两次迭代阶段使用所有仪式，然后看看其效果。接着，你可以进行快速回顾，看看可能需要进行哪些调整。
以下是 Scrum 团队可能参加的所有重要仪式清单：
有时也被称为待办事项梳理，它由 Product Ower 负责。Product Ower 的主要工作是协助实现产品愿景，并持续关注市场和客户。因此，他可根据用户和开发团队的反馈来维护此列表，以协助确定列表的优先级以及保持整洁。
由整个开发团队在迭代计划会期间进行，主要规划当前迭代期间要执行的工作（范围）。迭代计划会议由 Scrum Master 主持，而团队则在会议期间决定迭代目标。接着，可将产品待办事项中的用户故事添加到迭代中。这些故事应与目标始终保持一致，且 Scrum 团队也承诺可在迭代期间完成。 在规划会议结束时，每位 Scrum 成员均需清楚在迭代期间可以交付的内容，以及如何交付增量变化。
迭代是 Scrum 团队共同完成增量的实际时间段。两周是一个相当典型的迭代时长，尽管某些团队发现一周更容易确定范围，或是一个月更容易提供有价值的增量变化。但国外知名敏捷教练 Dave West 建议，工作越复杂，未知因素就越多，而迭代就应该越短。但事实上，这取决于团队，而如果不起作用，团队也可以进行改变！
所有事件（从规划到回顾）都是在迭代期间发生的。一旦确定了迭代的特定时间间隔，就必须在整个开发期间保持一致。这有助于团队吸取经验教训，并将这些洞察应用于未来的迭代。
这是每天在同一时间（通常是早晨）和地点举行的超短例会，为了确保此会议简洁明了，很多团队试图在15 分钟内完成会议，但这只是一个参考。
每日 Scrum 旨在让团队中的每一个成员都保持同步，共同朝着迭代目标努力，并制定未来 24 小时的计划。 你可在每日短会上说出自己在实现迭代目标或解决任何障碍时遇到的问题。 每日短会的其中一种常见举行方法是让每个团队成员在实现迭代目标的过程中回答三个问题：
- 我昨天做了什么？
- 我今天打算做什么？
- 是否存在障碍？
然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是：它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。
在迭代结束时，团队聚集在一起进行非正式会议，以观看增量演示。开发团队向利益相关者和团队成员展示目前处于“已完成”状态的待办事项，以征求他们的反馈意见。尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。
此次审核会议也是产品负责人根据当前迭代重新处理产品待办事项之时，当前迭代可为下一次迭代规划会议提供相关信息。对于为期一个月的迭代，可考虑将你的迭代审核时间限制为最长四个小时。
迭代回顾会是团队聚集在一起共同记录和讨论迭代、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。我们的思路是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待改进，而不是专注于出了什么问题。
Scrum 是一个非常流行的敏捷框架，以至于 Scrum 和敏捷经常被误解为同一个东西。但是除 Scrum 外还有其他框架，例如看板，也是一种流行的替代方案。有的公司甚至选择采用 Scrum 和看板的混合模式。
Scrum 和看板都使用可视化管理方法，例如 scrum 板或看板板来跟踪工作进度。两者都强调效率并将复杂的任务拆分为更小的可管理工作，但他们实现该目标的方法不同。
Scrum 专注于较小的、固定周期的迭代。一旦确定了 sprint 的时间段，就确定了可以在该 sprint 周期内实现的需求。然而，在看板中，首先要在当前周期中执行的任务数或在制品（WIP 限制）是固定的。然后向后计算实现这些功能所需的时间。
看板不像 Scrum 那样结构化。除了 WIP 限制之外，它的原则或者实践是相当开放的。甚至，Scrum 部分概念也能作为其实施的一部分，如 Sprint 审查、回顾、每日站会等。它还更适应跨团队的协作，因为 scrum 团队不依赖外部成员来实现的能力他们的目标，在Scrum模式下要拼凑一个跨职能团队并不简单，其中涉及了思维方式和价值、流程等诸多转变。从这个角度上来看，看板更容易适应。
但是，为什么是 Scrum？
Scrum 框架本身很简单，规则、工件、事件和角色很容易理解。它的半规范性方法实际上有助于消除开发过程中的歧义，同时为公司提供足够的空间来介绍他们的个人风格。
其次，是 Scrum 擅长将复杂的项目转化成一个个可实现的待办事项。此外，角色和计划事件的明确划分确保了整个开发周期的透明度和团队的自组织性。以及快速发布能让团队保持积极性并让用户感到高兴，因为他们可以在很短的时间内看到进展。
然而，完全理解 Scrum 可能需要一些时间，尤其是在开发团队已经适应了典型的瀑布模型的情况下。较小的迭代、每日站会、迭代评审和确定 Scrum Master 的概念对于新团队来说可能是一个具有挑战性的文化转变。
但是，实施 Scrum 所带来的长期收益远远超过最初学习造成的成本。所以 Scrum 无论是在跨不同行业的垂直领域开发复杂的硬件或软件产品方面，都成功使其引人注目的框架。
敏捷宣言已经诞生二十年，这份简短却“颠覆”规则的文件，帮助我们将产品开发交付的方式，从长途运输变成了“次日达”一样的存在。当下的我们正处在一个持续创新的世界，面对技术变革洪流，有时候我们可能会产生思考：敏捷宣言是否仍然应该成为我们的指南？
在正式讨论这个问题之前，我们先来重温一下敏捷宣言：
2001年2月11日至13日，在犹他州瓦萨奇山的雪鸟（Snowbird）滑雪胜地洛奇酒店，17位软件开发领域的领军人物聚在一起 ，他们分享、探讨了非常多的软件开发方式、经验，比如：极限编程（XP）、透明化、自适应软件开发（ASD）、特征驱动开发（FDD）、动态系统开发方法（DSDM）等等，并试图找到他们的共同点，以更简单的规则来适应快速变化的环境。
经过为期三天的讨论，他们在价值观和原则层面上达成共识，选择了 Agile 一词并为其赋予了特殊的意义，制定并发布了软件行业历史上最为重要的文件之一：《敏捷宣言》。
参会者将这个组织命名为“敏捷联盟（ The Agile Alliance ）”，希望能够帮助软件行业中的其他人以全新、更敏捷的方式思考软件开发、方法和组织。而“敏捷宣言”则被展示在一个网站上（ https://agilemanifesto.org/ ） 。到目前为止，《敏捷宣言》已被翻译成了60多种语言，并作为一种信仰被推广至全球，甚至是非软件行业。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下敏捷价值观：
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说，尽管右边的项目有一定的价值，我们更重视左边项目的价值。
敏捷宣言的12条原则包括：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
附：《敏捷宣言》英文版原文
从敏捷宣言发布时起，其内容就几乎就没有发生过变化，但围绕敏捷的世界却大不相同。
敏捷宣言的17位发起人虽然成功地在几个核心原则下统一了他们不同的观点，但争论并没有就此结束。在某些方面，敏捷的发展早已经超越了创始人在开始时所提出的范畴，并且似乎每个人对敏捷都有自己的看法。比如SAFe、LeSS等等，甚至有些敏捷实践和软件开发没有任何关系，而敏捷宣言却曾这样描述：“我们正通过这样的方式，来帮助其他人发现更好的软件开发方法。”
Scrum.org 的 CEO 戴夫·韦斯特 (Dave West) 曾前往各个组织观察敏捷实践，然后组建了一个研究团队，并使用敏捷开发的模式研究病毒治疗遗传失明的方法。事实上，软件开发之外的领域利用敏捷方法的已经并不少见，但这并不在宣言提出人的意料之中。
敏捷专业人士布坎南曾这样解释《敏捷宣言》：“并不是说它不能被解释，而是需要更深入的理解才能确保这些原则/价值观被正确地翻译”，但即使在软件开发中，要正确理解并执行这些原则也并不容易。
许多人认为，敏捷培训和咨询的泛滥加剧了“伪敏捷”之类的存在，有些人甚至将这种敏捷推广背后的组织称为“敏捷产业联盟”。敏捷专业人士布坎南曾这样评价这种现象：“你做的和说的可能都是对的，但你不理解基本的敏捷原则”。
甚至有些人认为敏捷管理工具制造厂商，比如 PingCode、Atlassian 也加剧了这种情况，因为工具支持像 Scrum 和 Kanban 这类敏捷框架，固化了敏捷，让使用敏捷的人不用加以理解就能直接使用。但实际上，敏捷是一种文化价值，团队应该可以用他们认为最合适的方式工作。而敏捷框架与敏捷文化价值观是并存的，但如果你没有文化上的认同，那么你所做的可能从一开始就有缺陷。
为了敏捷而敏捷，过度追求敏捷本身，往往会与宣言的原则背道而驰——过分关注细节、缺乏交付、僵硬的遵守流程原则，出现这种现象的从业者甚至有些是带有敏捷证书的。这些糟糕的敏捷体验很可能机会导致一些人完全放弃敏捷。但是在敏捷被广泛采用的同时，很多人也会因《敏捷宣言》有时被误导，那么《敏捷宣言》还是一份值得参考的指南吗？
在与数以百计的客户、内部和外部敏捷教练、敏捷爱好者和狂热的实践者交谈之后，以及从社交媒体上花了大量的时间调研之后，可以确认的是：敏捷宣言仍然具有现实意义，甚至现在比以往更有意义。
Scrum.org的CEO 戴夫·韦斯特 (Dave West) 曾这样评价：敏捷原则其实根本不是什么新东西，它们只是以一种不同的方式被应用。敏捷宣言的价值就像是伽利略、阿基米德等科学工作者发现的定律/规律。
或者，我们可以这样认为，《敏捷宣言》最大的成就是整理出了一种尚未用于软件开发领域的思维方式。
那么，我们应该根据世界的变化对《敏捷宣言》进行更新吗？
不一定。
当像《敏捷宣言》这样具有文化意义的东西出现时，我们可以重新解释它，但没有什么能比得上原作。因为，与其试图更新它，不如花更多的时间弄清楚如何让它更好的应用于自己、团队或组织。
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/1088.html