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日登陆深圳，将“多团队敏捷协同”基因内化在研发流程中，为规模化提升研发效能保驾护航！!⛴公众号回复“乌托邦”可参加