Scrum 是一种用于开发、交付和持续支持复杂产品的敏捷框架，其核心在于通过短周期的迭代和增量式交付，来应对不确定性并最大化产品价值。它并非一套详尽无遗的具体流程或技术，而是一个轻量级的、规定了基本规则和角色的框架。其精髓主要体现在：它以经验主义三大支柱（透明、检视、适应）为理论基础、由三个明确定义的角色（产品负责人、Scrum Master、开发者）构成自管理团队、通过五个结构化的事件（Sprint本身及其包含的Sprint规划会、每日站会、Sprint评审会和Sprint回顾会）来驱动节奏与反馈、并依赖于三个关键的工件（产品待办列表、Sprint待办列表、产品增量）来确保工作的透明与价值的持续交付。Scrum的根本目标，是在控制风险的同时，尽早、并持续地交付出对客户有价值的产品。
正如Scrum的联合创始人之一杰夫·萨瑟兰所言：“Scrum 是一门在限定时间内完成双倍工作的艺术。” 这句话精准地概括了Scrum追求高效与价值的核心理念。它通过一种结构化的方式，将复杂的、看似无法预测的项目，分解成一系列小型的、可管理的、可快速验证的增量，从而让团队在变化中稳步前进。
一、Scrum 的哲学基石：经验主义与敏捷宣言
要真正理解Scrum，就必须先深入其赖以建立的哲学基石——经验主义（Empiricism）。经验主义认为，知识来源于感官经验和实践。在Scrum的语境下，这意味着我们承认并拥抱“我们无法预知一切”的现实。对于复杂问题，与其花费大量时间去制定一个看似完美的、长期的、但极有可能在未来被证明是错误的计划，不如通过一系列短周期的“实践-学习-调整”循环，来逐步逼近最终的目标。Scrum正是将这一哲学思想，通过其框架结构具体化和实践化了。
经验主义在Scrum中通过三大支柱来体现：透明（Transparency）、检视（Inspection）和适应（Adaptation）。
透明意味着项目相关的所有重要方面，无论是进展、问题、还是工件，都必须对所有负责产出结果的人清晰可见。例如，产品待办列表（Product Backlog）必须对所有干系人开放，团队的工作进度必须通过任务看板等方式直观展示。没有透明，有效的检视就无从谈起。
检视是指Scrum团队必须频繁地、有规律地检视Scrum工件和项目进展，以便及时发现任何不符合期望的变差或问题。Scrum中的每一个事件（如每日站会、Sprint评审会）都为检视提供了专门的机会。
适应则是指，当检视发现当前的做法或产出偏离了可接受的范围时，团队必须尽快地做出调整，以最小化进一步的偏离。例如，在Sprint回顾会中发现某个流程存在问题，团队就应该在下一个Sprint中立即尝试新的做法。
这三大支柱共同构成了一个持续学习和改进的闭环，是Scrum框架能够有效应对复杂性和不确定性的根本原因。同时，Scrum也是对2001年《敏捷软件开发宣言》核心价值观和十二条原则的杰出实践。它强调“个体和互动高于流程和工具”，“可工作的软件高于详尽的文档”，“客户合作高于合同谈判”，以及“响应变化高于遵循计划”。可以说，Scrum为这些高阶的敏捷价值观，提供了一套具体、可操作的落地实践框架。想要深入了解其官方定义，可以参考最新的Scrum指南。
二、Scrum 的三大核心角色：构建自管理团队的“铁三角”
Scrum框架定义了三个非常明确的核心角色，他们共同组成一个紧密协作的Scrum团队。这个团队是跨职能的、自管理的，他们作为一个整体，拥有交付一个可用的、有价值的产品增量所需的全部技能和权力。这三个角色形成了一个稳定的“铁三角”，确保了团队在价值、流程和执行三个维度上的平衡与高效。
产品负责人（Product Owner，简称PO）：产品负责人的核心职责是最大化产品所带来的价值，这些价值是由开发者团队的工作所实现的。他们是产品“价值”的最终责任人，是连接客户、业务干系人与开发者团队之间的桥梁。具体来说，PO的主要工作是清晰地表达和沟通产品目标，创建并明确地沟通产品待办列表项，对产品待办列表项进行排序以最好地实现目标和使命，并确保产品待办列表对所有人都是透明、可见和可理解的。在一个组织中，为了确保决策的统一性和高效性，产品负责人应该是“一个人，而不是一个委员会”。他们拥有对产品待办列表的最终决定权，任何想改变待办列表优先级的人，都必须先说服PO。
Scrum Master（简称SM）：Scrum Master的核心职责是确保Scrum团队能够按照Scrum指南来有效地工作。他们并非传统的项目经理或团队领导，而是一位“服务型领导”（Servant-Leader）。其服务的对象包括Scrum团队、产品负责人以及整个组织。对于Scrum团队，SM通过教导团队自管理和跨职能，帮助团队专注于创造高价值的增量，并移除团队前进道路上的障碍。对于产品负责人，SM帮助其找到有效定义产品目标和管理产品待办列表的技巧。对于整个组织，SM则通过引导、培训和辅导，帮助组织理解和采纳Scrum，推动组织环境的变革以更好地支持Scrum团队。一个优秀的Scrum Master是团队的“教练”和“流程守护者”，他们通过赋能而非命令，来激发团队的潜能。
开发者（Developers）：开发者是指Scrum团队中那些致力于创建每个Sprint可用增量的任何方面的专业人士。他们是一个跨职能的群体，包含了传统意义上的设计师、程序员、测试工程师、架构师等所有交付产品所需的人员。开发者团队作为一个整体，对他们所交付的工作质量负有集体责任。他们是自管理的，这意味着他们自己决定“如何”将产品待办列表项转化为可用的产品增量。他们负责创建Sprint的计划（即Sprint待办列表），在每日站会中同步进展并调整计划，并通过遵守“完成的定义”来确保工作质量。
三、Scrum 的五大事件：驱动节奏与反馈的“心跳”
Scrum通过一系列有固定节奏和时间限制的事件，来构建其经验主义的反馈循环，并最大程度地减少其他不必要的会议。这些事件被称为Scrum的“心跳”，为团队提供了进行检视和适应的正式机会。所有事件都有一个最长持续时间，即“时间盒”（Time-box），以确保投入的时间是有效率的。
Sprint：Sprint是所有其他事件的容器，是Scrum框架的核心。它是一个固定长度的、不超过一个月的迭代周期，在此期间，团队致力于创造一个“完成的”、可用的、潜在可发布的产品增量。一个Sprint在前一个Sprint结束后立即开始，这种固定的节奏为项目带来了可预测性。在整个Sprint期间，产品待办列表的优先级应保持稳定，质量目标不应降低。
Sprint规划会（Sprint Planning）：每个Sprint都以Sprint规划会开始。在这个会议中，整个Scrum团队共同协作，来规划即将在当前Sprint中完成的工作。会议主要回答三个问题：为什么这个Sprint有价值？（Why） – 产品负责人提出一个Sprint目标；这个Sprint能完成什么？（What） – 开发者团队从产品待办列表中选择若干项纳入Sprint；选出的工作将如何完成？（How） – 开发者团队为选定的工作制定具体的执行计划，形成Sprint待办列表。
每日站会（Daily Scrum）：每日站会是一个为开发者团队准备的、每天在同一时间同一地点举行的、不超过15分钟的短会。其目的是为了检视迈向Sprint目标的进展，并为后续的24小时调整工作计划。开发者团队利用这个机会来同步信息、识别障碍，并优化协作。会议的形式可以多样，但核心是确保团队能够聚焦于Sprint目标，并尽快地解决任何可能阻碍他们前进的问题。
Sprint评审会（Sprint Review）：Sprint评审会在每个Sprint结束时举行，其目的是检视本个Sprint的产出（即产品增量），并根据需要调整产品待办列表。这是一个非正式的工作会议，Scrum团队会向关键的干系人演示他们在这个Sprint中完成的工作，并收集反馈。这不是一个简单的“汇报会”，而是一次宝贵的协作机会，通过真实的、可工作的产品增量来引发关于产品未来方向的深入讨论。
Sprint回顾会（Sprint Retrospective）：Sprint回顾会是每个Sprint的最后一个事件，在Sprint评审会之后、下一个Sprint规划会之前举行。其目的是规划在下一个Sprint中提升质量和效果的方法。整个Scrum团队（PO, SM, 开发者）都会参加，共同检视上一个Sprint中关于人、关系、流程和工具等方面的情况，识别出哪些做得好，哪些可以改进，并为如何改进制定一个具体的、可执行的计划。这是Scrum团队进行自我反思和持续改进的关键机制。
四、Scrum 的三大工件：让价值与进度“透明化”的载体
Scrum的工件代表了工作或价值，它们被设计用来最大化关键信息的透明度，为检视和适应提供坚实的基础。每个工件都包含一个“承诺”（Commitment），以确保它能提供增强透明度和凝聚力的信息。
产品待办列表（Product Backlog）：产品待办列表是一个涌现的、有序的列表，包含了改善产品所需的一切。它是Scrum团队需要做的所有工作的唯一来源。产品负责人负责维护这个列表，包括其内容、可用性和排序。产品待办列表是一个“活的”工件，它会随着产品的发展和市场的变化而不断演进。为了确保其清晰和有序，一个良好的产品待办列表项应该具备细节适当、经过估算、涌现的和经过排序的（DEEP）等特点。管理这个动态的列表是一项复杂的任务，现代团队通常会使用像智能化研发管理系统PingCode这样的工具来对其进行可视化管理、排序和追踪，从而确保所有干系人都能看到一个统一、透明的视图。
承诺：产品目标（Product Goal） – 产品目标描述了产品的未来状态，是Scrum团队规划要达成的长期目标。产品待办列表正是为了实现这个目标而存在的。
Sprint待办列表（Sprint Backlog）：Sprint待办列表由Sprint目标、为Sprint选择的产品待办列表项，以及交付增量的可行计划三个部分组成。它是由开发者为开发者创建的实时工作计划。Sprint待办列表具有高度的可视性，通常会以物理或电子任务看板的形式展现，让团队可以实时追踪Sprint的进展。它是动态的，在Sprint期间，开发者团队可以根据学习到的新知识对其进行修改和调整。
承诺：Sprint目标（Sprint Goal） – Sprint目标是在Sprint期间通过实现Sprint待办列表要达成的唯一目的。它为开发者团队提供了工作的灵活性，并鼓励他们作为一个团队进行协作，而不是各自为战。
产品增量（Increment）：产品增量是Sprint中完成的所有产品待办列表项与之前所有Sprint所创造的增量的总和。每个Sprint结束时，必须创造出一个新的、可用的、“完成的”产品增量。这意味着它必须处于可用状态，并满足Scrum团队共同定义的“完成的定义”。增量是Scrum经验主义核心的体现，它是团队工作的具体产出，是Sprint评审会中进行检视和收集反馈的坚实基础。
承诺：“完成”的定义（Definition of Done） – 这是一个正式的描述，当增量满足了产品所需的质量标准时，它就达到了这个状态。
五、“完成”的定义（Definition of Done）：质量的共同承诺
在Scrum框架中，“完成的定义”（Definition of Done，简称DoD）是一个至关重要的概念，它是确保产品增量质量和透明度的基石。如果一个组织没有明确且统一的DoD，那么对于“完成”这个词的理解就会因人而异，导致沟通混乱、期望错位和集成困难。
DoD是一份共享的、正式的清单，它描述了当一个产品待办列表项或一个产品增量被声称为“完成”时，必须满足的所有条件。这个清单是由Scrum团队共同创建和维护的。对于一个软件产品，DoD可能包含以下内容：代码已经过同行评审（Peer Review）、所有单元测试和集成测试都已通过、代码已经成功合并到主干、相关的技术文档已经更新、并通过了产品负责人的验收等。
DoD的存在，确保了每个人对质量都有一个共同的理解和承诺。 当开发者说一个功能“完成了”，他们指的不是“我的代码写完了”，而是“这个功能已经达到了我们团队共同承诺的可发布质量标准”。这极大地提升了透明度，使得产品负责人和干系人在评审会上看到的，是一个真正意义上“完成”的、潜在可交付的产品，而不是一个半成品。它强制团队将质量“内建”于开发过程的每一个环节，而不是留到最后才去考虑。随着团队的成熟，他们应该不断地挑战和完善自己的DoD，追求更高的质量标准，这也是持续改进的体现。
六、Scrum 流程详解：一个 Sprint 的生命周期之旅
为了将上述所有概念串联起来，让我们以一个典型的为期两周的Sprint为例，走一遍它的生命周期之旅。
故事始于产品待办列表，这是一个由产品负责人精心维护的、按价值排序的需求列表。在Sprint规划会上，产品负责人向开发者团队阐述了最重要的几个待办列表项，并提出了一个期望的Sprint目标，比如“实现用户基础的购物车功能”。开发者团队根据自己的速率和对工作的理解，从列表顶部拉取若干个他们承诺能在这个Sprint内完成的待-办列表项。然后，他们会将这些待办列表项分解成更小的、可执行的任务，并制定出一个初步的行动计划。这些被选中的待办列表项和行动计划，共同构成了Sprint待办列表。
Sprint正式开始后，开发者团队便投入到紧张的工作中。每天早上，他们会召开一个15分钟的每日站会，快速同步信息：“我昨天做了什么来帮助团队达成Sprint目标？我今天要做什么？有什么障碍阻碍了我或团队？”。在整个Sprint期间，团队成员紧密协作，共同将Sprint待办列表中的任务一项项完成。每完成一项，他们都会对照**“完成的定义”** 来进行检验，确保其质量。所有这些“完成”的工作，共同构成了本次Sprint的产品增量。
在Sprint的最后一天，团队会召开Sprint评审会。他们会邀请产品负责人、公司管理层、市场人员等关键干系人，向他们演示这个新增了购物车功能的、可工作的软件版本。干系人们会提出反馈和新的想法，产品负责人则会根据这些反馈，来调整和优化未来的产品待办列表。评审会结束后，Scrum团队会立即进入Sprint回顾会。在这个私密的会议里，他们会一起反思这两周的协作过程：“我们的沟通是否顺畅？我们的估算是否准确？有没有什么流程可以改进，让我们下一个Sprint做得更好？”。会议的产出是一两个具体的改进项，团队会承诺在下一个Sprint中去实践。当回顾会结束，这个Sprint也就正式画上了句号，而下一个Sprint，又将无缝地开启新的循环。
常见问答（FAQ）
问：Scrum Master和传统的项目经理有什么本质区别？
答：这是一个非常核心且常见的困惑。最本质的区别在于他们的工作重心和领导方式。传统的项目经理（Project Manager）通常是“指挥控制型”的，他们负责制定详细计划、分配任务、跟踪进度并对项目成败负总责，权力相对集中。而Scrum Master则是“服务型领导”，他们不直接管理团队或分配任务，其核心职责是作为教练和引导者，帮助团队理解和用好Scrum框架，移除团队遇到的障碍，并保护团队不受外界干扰。项目经理关注的是“项目”本身（范围、时间和成本），而Scrum Master关注的是“人”和“流程”，他们通过赋能团队，让团队能够自管理、自组织地去高效交付价值。
问：Scrum是否只适用于软件开发项目？
答：虽然Scrum起源于软件开发领域，并且在该领域得到了最广泛的应用，但它本身是一个通用的、用于管理复杂工作的框架，绝不局限于软件开发。如今，Scrum已经被成功地应用于市场营销、产品设计、人力资源、教育、甚至是科学研究等多个领域。任何符合“工作复杂、需求不确定、需要通过迭代和协作来探索最佳解决方案”特点的项目或产品，都可以从Scrum的经验主义方法中受益。关键在于理解其背后的哲学思想，并根据具体领域的特点来灵活应用其角色、事件和工件。
问：一个Sprint的周期应该是多长？两周是最佳选择吗？
答：Scrum指南规定一个Sprint的长度是固定的，且最长不超过一个月。并没有一个“放之四海而皆准”的最佳长度，团队需要根据自身的具体情况来选择。选择的依据主要包括：需求的稳定程度、业务环境的变化速度、以及团队能够持续交付一个“完成的”增量所需的时间。周期短（如一周）的好处是反馈循环快，能够更灵活地应对变化；但缺点是用于规划和回顾等事件的开销占比较高。周期长（如四周）的好处是团队有更长的时间来完成更复杂的工作，会议开销占比较低；但缺点是风险暴露慢，适应性较差。目前，两周是业界最普遍的选择，因为它在灵活性和工作节奏之间取得了一个较好的平衡。建议新团队可以从两周开始尝试，然后通过回顾会来检视这个节奏是否合适，并进行调整。
问：如果在Sprint期间，出现了非常紧急的、未在计划内的工作（例如线上重大故障），应该如何处理？
答：这是一个考验团队敏捷应对能力的现实场景。首先，Scrum Master需要保护团队，判断这个“紧急工作”是否真的达到了必须立即中断当前Sprint的程度。如果是一个可以容忍到下个Sprint再处理的问题，就应该礼貌地请需求方与产品负责人沟通，将其放入产品待办列表并排序。如果确认是一个“十万火急”、必须马上处理的事件（如生产环境瘫痪），Scrum团队可以采取以下几种方式：一种是，如果工作量不大，开发者团队可以在与产品负责人协商后，从当前Sprint待办列表中移除一个同等规模的、优先级较低的任务，来为这个紧急任务腾出空间。另一种是，如果紧急工作的规模巨大，足以让整个Sprint目标变得不切实际，那么产品负责人有权取消（Cancel）当前的Sprint。这是一个非常重大的决定，需要慎重使用。取消后，团队会立即召开一个新的Sprint规划会，来应对这个新的、更高优先级的现实。
问：我们团队刚开始用Scrum，感觉会议太多，各种流程很繁琐，效率反而比以前更低了，这是为什么？
答：这是许多团队在Scrum转型初期都会遇到的“阵痛期”，通常被称为“ScrumBut”（我们用Scrum，但是…）或“机械式Scrum”阶段。效率降低的原因可能有很多：第一，对Scrum事件的目的理解不清，导致会议超时、跑题，变成了低效的汇报会。例如，每日站会开成了项目经理的质询会。第二，团队成员尚未适应新的协作模式，自管理能力不足，仍然习惯于等待指令。第三，组织环境的阻碍，例如，产品负责人权力不足，无法拒绝来自各方的需求干扰。要度过这个阶段，关键在于：寻求专业的Scrum Master或敏捷教练的指导，他们能帮助团队正确地理解和执行Scrum；坚持开好Sprint回顾会，坦诚地暴露问题，并持续进行小范围的改进实验；以及获得管理层的理解和支持，为Scrum的推行创造一个有利的“土壤”。Scrum的真正威力，需要团队在度过初期的不适后，才能逐渐显现出来。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：百晓生，转转请注明出处：https://www.chuangxiangniao.com/p/636693.html
微信扫一扫 
支付宝扫一扫 
