共计 5616 个字符，预计需要花费 15 分钟才能阅读完成。
Scrum 根底
Scrum 一词来源于英式橄榄球，是争球的一种形式，Scrum 框架借用这个词比喻产品开发团队是一个整体合作的团队，独特进行冲刺，达成团队指标。
Scrum 最后是为了治理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在寰球范畴内已失去了广泛应用，这是两位次要的创始人 Jeff Sutherland 与 Ken Schwaber。
Scrum 已被用于开发软件、硬件、嵌入式软件、交互性能网络、主动驾驶、学校、政府、市场、治理组织经营，以及简直咱们 (作为个体和群体) 日常生活中所应用的所有。
Scrum 基于经验过程管制实践，或称之为经验主义。经验主义主张常识源自理论教训以及 以后已知状况下做出的决定所取得。Scrum 驳回一种迭代、增量式的办法来优化对将来的 预测和管制危险。
通明、检视和适应是经验过程管制的三大支柱，撑持起每一个经验过程的施行。
Scrum 5 个价值观
承诺、勇气、专一、凋谢、尊重，是 Scrum 的 5 个价值观。
Scrum 3 个角色
Product Owner
产品负责人外围职责是为产品的胜利负责：
- 为产品的愿景布局负责
- 治理并排序 PBL
- 为产品需要的 ROI 负责
- 承受或回绝迭代交付成绩
Scrum Master
Scrum Master 为 Scrum 的胜利施行负责：
- 执行 Scrum 框架
- 帮团队打消阻碍
- 爱护团队不受外界烦扰
- 率领团队继续改良
Team
团队为产品性能交付负责：
- 小团队 5- 9 人
- 跨职能、无角色
- 自组织、自治理
- 为迭代交付给出承诺
- 为达成承诺能够要求任何事件
Scrum 3 个工件
Product Backlog
产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需要变动的惟一 起源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表永远是不残缺的。最早开发的产品待办列表列举最后所知的以及了解最透彻 的需要。产品待办列表会随着产品及其应用环境的扭转而演进。产品待办列表是动静的，须要继续更新以反映出产品须要什么来放弃其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。
产品待办列表列出所有的个性、性能、需要、加强和修复等对将来要公布的产品进行的改 变。产品待办列表项具备这些属性: 形容、秩序、估算和价值。产品待办列表项通常包含 测试形容，将在“实现”时证实其完整性。
随着产品的应用、价值的获取和取得市场的反馈，产品待办列表会成长为更大和更详尽的 列表。因为需要永不进行扭转，所以产品待办列表就如一份活的工件。业务需要、市场形 势或者技术的变动都会引起产品待办列表的扭转。
排序越高的产品待办列表项通常比排序低的更清晰同时蕴含更多细节。依据更清晰的内容 和更详尽的细节信息就能做出更为精确的估算; 同样，排序越低，则细节信息越少。产品 待办列表项中那些行将会占用开发团队下一个 Sprint 大部分工夫的项会被加以精化，因 此，任一产品待办列表项都可能在 Sprint 的工夫盒期限内适当地“实现”。这些可能被 开发团队在一个 Sprint 中“实现”的产品待办列表项称为“准备就绪”，它们将作为 Sprint 打算会议中的待选产品列表项。产品待办列表项的足够通明水平通常要通过上述的 精化流动来取得。
开发团队负责所有估算工作。产品负责人能够通过帮忙开发团队更好地了解需要，并依据 状况衡量取舍来影响他们，然而最终估算是由开发团队决定的。
Sprint Backlog
Sprint 待办列表是一组为以后 Sprint 选出的产品待办列表项，同时加上交付产品增量和 实现 Sprint 指标的打算。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功 能以及交付那些性能到“实现”的增量中所需工作的预测。
Sprint 产品待办列表将开发团队用来达成 Sprint 指标的所有工作变得清晰可见。为了确 保继续改良，它至多包含一项在先前回顾会议中确定下来的高优先级过程改良。
Sprint 产品待办列表是领有足够细节的打算，任何进度的变动能够在每日 Scrum 站会中 清晰地看到。开发团队在 Sprint 期间批改 Sprint 待办列表，使得 Sprint 待办列表在 Sprint 期间涌现。涌现产生在开发团队按计划发展工作并学习到更多的对于哪些工作是达 成 Sprint 指标所必须的工作时。
当新工作呈现时，开发团队须要将其退出到 Sprint 待办列表中去。随着工作的执行或完 成，残余的工作量被估算并更新。当打算中的某个局部失去开发意义，就能够将其移除。在 Sprint 期间，只有开发团队能够扭转 Sprint 待办列表。Sprint 待办列表是高度可见 的，是对开发团队打算在以后 Sprint 内工作实现状况的实时反映，该列表由开发团队全 权负责。
PSPI
PSPI 是指潜在可交付的产品增量，是一个 Sprint 实现的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增 量的价值总和。在 Sprint 的最初，新的增量必须是“实现”的，这意味着它必须可用并 且达到了 Scrum 团队“实现”的定义的规范。增量是在 Sprint 完结时反对经验主义的可检视的和已实现的产品组成部分。增量是迈向愿景或指标的一步。无论产品负责人是否决 定公布它，增量必须可用。
Scrum 5 个会议
Sprint Planning
Sprint 中要做的工作在 Sprint 打算会议中来做打算。这份工作打算是由整个 Scrum 团队 独特合作实现的。
Sprint 打算会议是限时的，以一个月的 Sprint 来说最多 8 小时为下限。对于较短的 Sprint，会议工夫通常会缩短。Scrum Master 要确保会议顺利举办，并且每个参会者都理 解会议的目标。Scrum Master 要教诲 Scrum 团队恪守工夫盒的规定。
Sprint 打算会议答复以下问题:
- 接下来的 Sprint 交付的增量中要蕴含什么内容?
- 要如何实现交付增量所需的工作?
话题一: 这次 Sprint 能做什么?
开发团队预测在这次 Sprint 中要开发的性能。产品负责人解说 Sprint 的指标以及达成该 指标所需实现的产品待办列表项。整个 Scrum 团队协同工作来了解 Sprint 的工作。
Sprint 会议的输出是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的 预测以及开发团队的以往体现。开发团队本人决定抉择产品待办列表项的数量。只有开发 团队能够评估接下来的 Sprint 能够实现什么工作。
在 Sprint 打算会议中，Scrum 团队还草拟一个 Sprint 指标。Sprint 指标是在这个 Sprint 通过实现产品待办列表要达到的目标，同时它也为开发团队提供指引，使得开发团队明确 开发增量的目标。
话题二: 如何实现所选的工作?
在设定了 Sprint 指标并选出这个 Sprint 要实现的产品待办列表项之后，开发团队将决定 如何在 Sprint 中把这些性能构建成“实现”的产品增量。这个 Sprint 中所选出的产品待 办列表项加上交付它们的打算称之为 Sprint 待办列表。
开发团队通常从设计整个零碎开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 打算会议中，开发团队曾经挑选出足够量的工作，以此来预估他们在行将到来的 Sprint 中可能实现。在 Sprint 打算会议的最初，开发团队布局出在 Sprint 最后几天内所要做的工作，通常以 一天或更少为一个单位。开发团队自组织地支付 Sprint 待办产品列表中的工作，支付工 作在 Sprint 打算会议和 Sprint 期间按需进行。
产品负责人可能帮忙解释分明所选定的产品待办列表项，并作出衡量。如果开发团队认为 工作过多或过少，他们能够与产品负责人从新协商所选的产品待办列表项。开发团队也可 以邀请其余人员加入会议，以取得技术或畛域常识方面的倡议。
在 Sprint 打算会议完结时，开发团队应该可能向产品负责人和 Scrum Master 解释他们将 如何以自组织团队的模式实现 Sprint 指标并开发出预期的产品增量。
Daily Scrum
每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件。每日 Scrum 站会在 Sprint
的每一天都举办。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制订计 划。通过检视上次每日 Scrum 站会以来的工作和预测行将到来的 Sprint 工作来优化团队 合作和性能。每日 Scrum 站会在同一时间同一地点举办，以便升高复杂性。
开发团队借由每日 Scrum 站会来检视实现 Sprint 指标的进度，并检视实现 Sprint 待办 列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 指标的可能性。每 天，开发团队应该晓得如何以自组织团队来协同工作以达成 Sprint 指标，并在 Sprint 结 束时开发出预期中的增量。
通常的模式是如下三个问题：
- 昨天，我为帮忙开发团队达成 Sprint 指标做了什么?
- 明天，我为帮忙开发团队达成 Sprint 指标筹备做什么?
- 是否有任何阻碍在妨碍我或开发团队达成 Sprint 指标?
Scrum Master 确保开发团队每日站会如期举行，但开发团队本人负责召开会议。Scrum Master 教诲开发团队将每日 Scrum 会议工夫管制在 15 分钟内。
每日 Scrum 站会是开发团队的外部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会烦扰会议进行。
每日 Scrum 站会增进交换沟通、缩小其余会议、发现开发过程中须要移除的阻碍、突显 并促成疾速地做决策、进步开发团队的认知水平。这是一个进行检视与适应的要害会议。
Sprint Review
Sprint 评审会议在 Sprint 快完结时举办，用以检视所交付的产品增量并按需调整产品待
办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同探讨在这次 Sprint 中所完 成的工作。依据实现状况和 Sprint 期间产品待办列表的变动，所有参会人员协同探讨接 下来可能要做的事件来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示 增量的目标是为了获取反馈并促成单干。
对于长度为一个月的 Sprint 来说，评审会议工夫最长不超过 4 小时。对于较短的 Sprint 来说，会议工夫通常会缩短。Scrum Master 要确保会议举办，并且每个参会者都明确会议 的目标。Scrum Master 教诲每位参会者恪守工夫盒的规定。
Sprint 评审会议蕴含以下内容:
- 产品负责人邀请 Scrum 团队和次要的利益攸关者加入会议;
- 产品负责人阐明哪些产品待办列表项曾经“实现”和哪些没有“实现”;
- 开发团队探讨在 Sprint 期间哪些工作做的很好，遭逢到什么问题以及问题是如何解决的;
- 开发团队演示“实现”的工作并解答对于所交付增量的问题;
- 产品负责人探讨以后的产品待办列表的状况。他 / 她依据到目前为止的进度来预测可能的指标交付日期(如果有需要的话);
- 参会的所有人就下一步的工作进行探讨，这样，Sprint 评审会议就可能为接下了的 Sprint 打算会议提供有价值的输出信息;
- 评审市场或潜在的产品应用形式所带来的接下来要做的最有价值的货色的扭转; 同时，
- 为下个预期产品性能或产品能力版本的公布评审时间表、估算、后劲和市场。
Sprint 评审会议的后果是一份订正后的产品待办列表，说明很可能进入下个 Sprint 的产 品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
Sprint Retrospective
Sprint 回顾会议是 Scrum 团队检视本身并创立下一个 Sprint 改良打算的机会。
回顾会议产生在 Sprint 评审会议完结之后，下个 Sprint 打算会议之前。对于长度为一个 月的 Sprint 来说，回顾会议工夫最长不超过 3 小时。对于较短的 Sprint 来说，会议时 间通常会缩短。Scrum Master 要确保会议举办，并且每个参会者都明确会议的目标。
Scrum Master 确保会议是踊跃的和富有成效的。Scrum Master 教诲大家恪守工夫盒的规 则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员加入该会议。
Sprint 回顾会议的目标在于:
- 检视前一个 Sprint 中对于人、关系、过程和工具的状况如何;
- 找出并加以排序做得好的和潜在须要改良的次要方面; 同时，
- 制订改良 Scrum 团队工作形式的打算。
Scrum Master 激励 Scrum 团队在 Scrum 的过程框架内改良开发过程和实际，使得他们 能在下个 Sprint 中更高效更欢快。在每个 Sprint 回顾会议中，如果实用并且不与产品或 组织规范相冲突，Scrum 团队打算不同的形式通过改良工作过程或调整“实现”的定义来提 高产品质量。
在 Sprint 回顾会议完结时，Scrum 团队应该明确接下来的 Sprint 中须要施行的改良。在 下一个 Sprint 中施行这些改良是基于 Scrum 团队对本身的检视而做出的适当调整。尽管 改良能够在任何工夫执行，Sprint 回顾会议提供了一个专一于检视和适应的正式机会。
PBL Grooming
这在规范的 Scrum 框架中并未呈现的会议，然而在实际过程中十分重要，能够确保咱们在开始下一个 Sprint 之前，可能把 PBL 提前梳理好，所以这个会议个别会产生在一个 Sprint 两头，通常是由 PO 发动的，大略整体会占用团队 5 -10% 的精力。
这是一个继续 的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表梳理过程中，产品待办列表项被从新评审和批改。Scrum 团队决定如何来实现精化以及何时 来实现。精化的工作通常占用开发团队不超过 10% 的产能。然而，产品负责人或者其余 人在产品负责人的斟酌下，产品待办列表项能够在任何工夫来更新。
参考资料：
- Scrum.org 官方网站
- 《Scrum 指南》2017 中文版
- 《京东麻利实际指南》赵卫 王立杰 2020
玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022 年 3 月 5 - 6 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入
