Scrum指南

257 阅读9分钟

看了遍Scrum中文指南,将其精简了一下方便以后学习。

Scrum 的定义

Scrum 是一个轻量的框架,它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值。

简而言之,Scrum 需要 Scrum Master 营造一个环境,从而:

  • ✅一名Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。
  • ✅Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。
  • ✅Scrum Team 和利益攸关者检视结果并为下一个 Sprint 进行调整。
  • ✅重复

Scrum 理论

Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。 Scrum 让一群共同拥有所有技能和专长的人员参与进来完成工作,并根据需要分享或获得所需技能。

Scrum 将 4 个正式事件组合在一起以在一个容器型事件 Sprint 中进行检视和适应。这些事件之所以起作用,是因为它们实现了基于经验主义的 Scrum 的三个支柱:透明、检视和适应。

透明

在 Scrum 中,重要的决策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。透明使检视成为可能。没有透明的检视会产生误导和浪费。

检视

Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视,以便发现潜在的不良的差异或问题。为了帮助检视,Scrum 以 5 个事件的形式提供了稳定的节奏。检视使适应成为可能。没有适应的检视是毫无意义的。Scrum 事件旨在激发改变。

适应

如果过程的任何方面超出可接受的范围或所得的产品不可接受,就必须对当下的过程或过程处理的内容加以调整。 调整工作必须尽快执行以最小化进一步的偏差。

Scrum 价值观

Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观:承诺, 专注, 开放, 尊重和勇气。

这些价值观为 Scrum Team 的工作、行动和行为指引方向。

Scrum Team

Scrum 的基本单位是小团队,称为 Scrum Team。 Scrum Team 由一名 Scrum Master,一名 Product Owner 和 Developers 组成。在Scrum Team 中,没有子团队或层次结构。Scrum Team 是具有凝聚力的专业团体,一次专注于一个目标,即 Product Goal。

Scrum Team 是跨职能的(cross-functional),这意味着团队成员具有在每个 Sprint 中创造价值而所需的全部技能。他们也是自管理的,这意味着他们在团队内部决定谁做什么、何时做以及如何做。

Developers

Developers 是 Scrum Team 中致力于创建每个 Sprint 可用 Increment 的任何方面的人员,比如开发人员,测试人员,业务分析人员等。

Developers 所需的特定技能通常很广泛,并且会随着工作领域的不同而变化。但是, Developers 始终要负责:

  • ✅为Sprint创建计划,即 Sprint Backlog;
  • ✅通过遵循 Definition of Done 来注入质量;
  • ✅每天根据 Sprint Goal 调整计划;
  • ✅作为专业人士对彼此负责;

Product Owner

Product Owner 负责将 Scrum Team 的工作所产生的产品价值最大化。

Product Owner 还负责对 Product Backlog 进行有效管理,包括:

  • ✅开发并明确地沟通 Product Goal ;
  • ✅创建并清晰地沟通 Product Backlog 条目(items);
  • ✅对 Product Backlog 条目进行排序;
  • ✅确保 Product Backlog 是透明的、可见的和可理解的;

Product Owner 是一个人,而不是一个委员会。在 Product Backlog 中,Product Owner 可以代表许多利益攸关者的期望要求。那些想要改变 Product Backlog 的人可以尝试去说服 Product Owner 来做到这一点。

Scrum Master

Scrum Master 负责按照 Scrum 指南的游戏规则来建立 Scrum。他们通过帮助 Scrum Team 和组织内的每个人理解 Scrum 理论和实践来做到这一点。Scrum Master 对 Scrum Team 的效能负责。他们通过让 Scrum Team 在 Scrum 框架内改进其实践来做到这一点。

Scrum Master 以多种方式服务于 Scrum Team ,包括:

  • ✅作为教练在自管理和跨职能方面辅导 Scrum Team 成员;
  • ✅帮助 Scrum Team 专注于创建符合Definition of Done的高价值 Increment;
  • ✅促使移除 Scrum Team 工作进展中的障碍;
  • ✅确保所有 Scrum 事件都发生并且是积极的、富有成效的,并且在时间盒(timebox)内完成。

Scrum Master 以多种方式服务于 Product Owner,包括:

  • ✅帮助找到有效定义 Product Goal 和管理 Product Backlog 的技巧;
  • ✅帮助 Scrum Team 理解为何需要清晰且简明的 Product Backlog 条目;
  • ✅帮助建立针对复杂环境的基于经验主义的产品规划(empirical product planning);和,
  • ✅当需要或被要求时,引导利益攸关者协作。

Scrum Master 以多种方式服务于组织,包括:

  • ✅带领、培训和作为教练辅导组织采纳 Scrum;
  • ✅在组织范围内规划并建议 Scrum 的实施;
  • ✅帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法(empirical approach);和,
  • ✅消除利益攸关者和 Scrum Teams 之间的隔阂。

Scrum 事件

Sprint 是所有其他事件的容器。

Sprint

Sprint 是 Scrum 的核心,在这里创意(idea)转化为价值。

它们是固定时长的事件,为期一个月或更短,以保持一致性。前一个 Sprint 结束后,下一个新的 Sprint 紧接着立即开始。实现 Product Goal 所需的所有工作,包括 Sprint Planning、Daily Scrum、Sprint Review 和 Sprint Retrospective,都发生在 Sprint 内。

在 Sprint 期间:

● 不能做出危及 Sprint Goal 的改变;

● 不能降低质量;

● Product Backlog 按需进行精化(refined),和

● 随着学到更多,可以与 Product Owner 就范围加以澄清和重新协商。

Sprint 通过确保至少每个月一次对达成 Product Goal 的进展进行检视和适应,来实现可预测性。当 Sprint 的长度拉得太长时,Sprint Goal 可能会失效,复杂性可能会上升,同时风险可能会增加。可以使用较短的 Sprint 来产生更多的学习周期,并将成本与工作投入(effort)的风险限制在更短的一段时间内。每个 Sprint 都可以视为一个短期的项目。

如果 Sprint Goal 已过时,那么就可以取消 Sprint。只有Product Owner 有取消 Sprint 的权力。

Sprint Planning

Sprint Planning 通过安排在 Sprint 中要做的工作来启动 Sprint。最终的计划是由整个 Scrum Team 协作创建的。

Sprint Planning 处理以下话题:

话题一:为什么这次 Sprint 有价值?

话题二:这次 Sprint 能完成(Done)什么?

话题三:如何完成所选的工作?

Daily Scrum

Daily Scrum 的目的是检视达成 Sprint Goal 的进展,并根据需要调整适应 Sprint Backlog,以调整即将进行的计划工作。Developers 可以选择他们想要的任何举行 Daily Scrum 的结构和技术,只要他们专注于实现 Sprint Goal 的进展,并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。

Sprint Review

Sprint Review 的目的是检视 Sprint 的成果并确定未来的适应性。Scrum Team 向关键利益攸关者展示他们的工作结果,并讨论 Product Goal 的进展情况。

在 Sprint Review 期间,Scrum Team 和利益攸关者将评审在这次 Sprint 中完成了什么,以及环境发生了什么变化。基于这些信息,与会者可以就下一步的工作进行协作。 Product Backlog 也可能会进行调整以适应新的机会。Sprint Review 是一个工作会议,Scrum Team 应避免将其仅限于展示。

Sprint Retrospective

Sprint Retrospective 的目的是规划提高质量和效能的方法。

Scrum Team 识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个 Sprint 的 Sprint Backlog 中。

Scrum 工件

Scrum 的工件代表工作或价值。 它们旨在最大限度地提高关键信息的透明度。 因此,为适应而检视它们的每个人对工件都有相同的基础。

每个工件都包含一个承诺,以确保它提供可增强透明度并聚焦于可度量进展的信息:

  • ✅对于 Product Backlog 而言,它是 Product Goal。
  • ✅对于 Sprint Backlog 而言,它是 Sprint Goal 。
  • ✅对于 Increment 而言,它是 Definition of Done。

Product Backlog

Product Backlog 是一份涌现的和有序的清单,它列出了改进产品所需的内容。它是 Scrum Team 所承担工作的唯一来源。

承诺: Product Goal

Product Goal 描述了产品的未来状态,可以作为 Scrum Team 制定计划的目标。Product Goal 在 Product Backlog 中。Product Backlog 的其余部分涌现,用来定义“做什么”将实现 Product Goal。

Product Goal 是 Scrum Team 的长期目标。他们必须先实现(或放弃)一个目标,然后再开始下一个目标。

Sprint Backlog

Sprint Backlog 由 Sprint Goal (为什么做)、为 Sprint 选择的 Product Backlog 条目(做什么)以及交付 Increment 的可执行计划(如何做)组成。它是 Developers 在 Sprint 期间为实现 Sprint Goal 而计划完成的工作,是一个高度可视且实时的工作画面。

承诺: Sprint Goal

Sprint Goal 是 Sprint 的单个目标。尽管Sprint Goal 是 Developers 的承诺,但它为实现该目标所需的确切工作方面提供了灵活性。 Sprint Goal 还创造了连贯性和专注点,鼓励 Scrum Team 一起工作而不是分开独自行动。

Increment

一个 Increment 是迈向 Product Goal 的一块坚实垫脚石。每个 Increment 都是之前所有的Increment 累加起来的,并经过彻底地验证,以确保整合在一起的所有 Increment 都能工作。为了提供价值,Increment 必须是可用的。在一个 Sprint 中可以创建多个 Increment。 Increment 的总和在 Sprint Review 中展示,从而支持经验主义。 但是,Increment 可以在 Sprint 结束之前交付给利益攸关者。Sprint Review 决不应该被视为发布价值的关口。

一项工作除非符合 Definition of Done ,否则不能将其视为 Increment 的一部分。

承诺: Definition of Done

Definition of Done 是当 Increment 符合产品所需的质量度量标准时对其状态的正式描述。

当一个 Product Backlog 条目符合 Definition of Done 时,就会产生一个 Increment。

结束语

Scrum 是免费的,并在本指南中提供。本文概述的 Scrum 框架是不可改变的。虽然仅实施部分的 Scrum 是可能的,但其结果就不是 Scrum 了。Scrum 仅以完整形式而存在,唯其如此才能有效成为其他技术、方法和实践的容器。