PMP–敏捷Scrum

Scrum 的定义

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

简而言之，Scrum 需要 Scrum Master 营造一个环境，从而：

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

Scrum 是易于理解的。原封不动地去尝试， 并确定其哲学、理论和结构是否有助于实现目标和创造价值。 Scrum 框架故意不完整，仅定义了实施 Scrum 理论所需的部分。Scrum 建立在其使用者 的集体智慧之上。Scrum 的规则没有为人们提供详细的使用说明，而是指导他们之间的关系和互动。

在 Scrum 框架中，可以使用各种不同的过程、技术和方法。Scrum 可以将一些已有的实践包装进 来，也可以甄别出非必须的实践。Scrum 可以凸显当前管理、环境和工作技术的相对成效， 以便可以进行改进。

Scrum 理论

Scrum 基于经验主义和精益思维。 经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。

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

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

透明

涌现的过程和工作必须对执行工作的人员和接受工作的人员都是可见的。在 Scrum 中，重要的决策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。

透明使检视成为可能。没有透明的检视会产生误导和浪费。

检视

Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问 题。为了帮助检视， Scrum 以 5 个事件的形式提供了稳定的节奏。

检视使适应成为可能。没有适应的检视是毫无意义的。 Scrum 事件旨在激发改变。

适应

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

当所涉人员没有得到授权或不能自管理（self-managing）时，则适应将变得更加困难。 在通过检 视学到任何新东西时，Scrum Team 会做出相应调整。

Scrum 价值观

Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观：承诺，专注，开放，尊重和勇气
Scrum Team 致力于达成其目标并且相互支持。他们的主要关注点是 Sprint 的工作，以便尽可能地 向着这些目标获取最好的进展。 Scrum Team 及其利益攸关者对工作和挑战持开放态度。 Scrum Team 成员相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的人的尊重。 Scrum Team 成员有勇气做正确的事并处理那些棘手的问题。

这些价值观为 Scrum Team 的工作、行动和行为指引方向。做出的决定、采取的步骤以及使用
Scrum 的方式应强化这些价值观，而不是削弱或破坏它们。Scrum Team 成员通过 Scrum 事件和工 件来学习和探索这些价值观。当 Scrum Team 和与他们一起工作的人们体现这些价值观时， 基于经 验主义的 Scrum 的三个支柱：透明、检视和适应，就成为现实，并在每个人之间构建信任。

Scrum Team

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

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

Scrum Team 规模足够小以保持灵活，同时足够大以便可以在 一个 Sprint 中完成重要的工作， 通常 只有 10 人或更少。总的来说，我们发现较小的团队沟通更好，效率更高。如果 Scrum Team 变得 太大，则应考虑将他们重组为多个具有凝聚力的 Scrum Team，每个团队都专注于同一产品。因此，他们应该共享相同的 Product Goal 、Product Backlog 和 Product Owner。

Scrum Team 负责所有与产品相关的活动，包括与利益攸关者的协作、验证、维护、运营、实验、 研究和开发，以及可能需要进行的其他任何活动。组织组建并授权 Scrum Team 自行管理他们自己 的工作。以可持续的速度在 Sprint 中工作可以提高 Scrum Team 的专注度和一致性。

整个 Scrum Team 都有责任在每个 Sprint 中创建有价值的、 有用的 Increment 。 Scrum 在 Scrum Team 中定义了三种特定的职责：Developers 、Product Owner 和 Scrum Master。

Developers

Developers 是 Scrum Team 中致力于创建每个 Sprint 可用 Increment 的任何方面的人员。

Developers 所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。 但是， Developers始终要负责：
● 为 Sprint 创建计划， 即 Sprint Backlog；
● 通过遵循 Definition of Done 来注入质量；
● 每天根据 Sprint Goal 调整计划； 和，
● 作为专业人士对彼此负责。

Product Owner

Product Owner 负责将 Scrum Team 的工作所产生的产品价值最大化。 如何做到这一点可能在组 织、Scrum Team 和个体之间存在很大差异。

Product Owner 还负责对 Product Backlog 进行有效管理，包括：

● 开发并明确地沟通 Product Goal ；
● 创建并清晰地沟通 Product Backlog 条目（items）；
● 对 Product Backlog 条目进行排序； 和，
● 确保 Product Backlog 是透明的、可见的和可理解的。

Product Owner 可以自己做上述工作，或者也可以将职责委托他人。 然而无论如何， Product Owner 是负最终责任的人。

为保证 Product Owner 取得成功，整个组织必须尊重他们的决定。这些决定在 Product Backlog 的 内容和顺序中可见，并在 Sprint Review 时透过可检视的 Increment 予以体现。

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 Masters 是真正的领导者，服务于 Scrum Team 和作为更大范围的组织。 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 是所有其他事件的容器。 Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些 事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的 机会。Scrum 使用事件来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。
最理想的是，所有事件都在同一时间同一地点举行，以便减少复杂性。

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 都可以视为一个短期的项目。

存在各种各样的实践来预测进展，例如，燃尽图（burn-downs）、燃起图（burn-ups）或累积流 图（cumulative flows）。尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生什么是未知的。只有已经发生的事情才能用来做前瞻性的决策。

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

Sprint Planning

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

Product Owner 要确保与会者准备好讨论最重要的 Product Backlog 条目 ，以及它们如何映射到 Product Goal 。Scrum Team 还可以邀请其他人参加 Sprint Planning 以提供建议。

Sprint Planning 处理以下话题：

话题一：为什么这次 Sprint 有价值？
Product Owner 提议产品如何在当前的 Sprint 中增加其价值和效用。然后，整个 Scrum Team 将共 同制定一个 Sprint Goal ，用以沟通当前 Sprint 对利益攸关者有价值的原因。必须在 Sprint Planning 结束之前最终确定 Sprint Goal 。

话题二：这次 Sprint 能完成（Done）什么？
通过与 Product Owner 讨论， Developers 从 Product Backlog 中选择一些条目，放入当前 Sprint 中。 Scrum Team 可以在此过程中精化这些 Product Backlog 条目，从而增加理解和信心。

选择在 Sprint 中可以完成多少任务可能会有挑战。 但是，Developers 对他们以往的表现，他们在 即将到来的 Sprint 内的产能以及对他们的 Definition of Done 了解得越多，他们对 Sprint 预测就越 有信心。

话题三：如何完成所选的工作？
对于每个选定的 Product Backlog 条目，Developers 都会规划必要的工作，以便创建符合 Definition of Done 的 Increment。这通常是通过将 Product Backlog 条目分解为一天或更短的较小条目来完成 的。Developers 自行决定如何完成这一工作。没有人告诉他们如何将 Product Backlog 条目转化为 价值的 Increment。

Sprint Goal 、这次 Sprint 所选出的 Product Backlog 条目加上如何交付它们的计划称之为 Sprint Backlog。

Sprint Planning 是有时间盒限定的，以一个月的 Sprint 来说最多为 8 个小时。对于更短的 Sprint， Sprint Planning 所需时间通常会更短。

Daily Scrum

Daily Scrum 的目的是检视达成 Sprint Goal 的进展，并根据需要调整适应 Sprint Backlog ，以调整即 将进行的计划工作。

Daily Scrum 是一个属于 Scrum Team 的 Developers 的 15 分钟的事件。为了降低复杂性，它在Sprint 的每个工作日都在同一时间同一地点举行。如果 Product Owner 或 Scrum Master 正在积极处 理 Sprint Backlog 条目，那么他们将作为 Developers 参与其中。

Developers 可以选择他们想要的任何举行 Daily Scrum 的结构和技术，只要他们专注于实现 Sprint Goal 的进展，并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。

Daily Scrum 改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。

Daily Scrum 并不是唯一一次允许 Developers 调整计划的时间。他们可以在一天中任何时间碰面， 详细讨论如何调整适应或重新规划 Sprint 的剩余工作。

Sprint Review

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

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

Sprint Review 是 Sprint 的倒数第二个事件，Sprint Review 是有时间盒限定的，以一个月的 Sprint 来 说，最多为 4 个小时。 对于更短的 Sprint ，Sprint Review 通常所需的时间更短。

Sprint Retrospective

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

Scrum Team 检视最近 Sprint 中有关个体、交互、过程、 工具和他们的 Definition of Done 的情况如 何。被检查的元素通常随工作领域而变化。识别使他们误入歧途的假设，并探究其起源。 Scrum Team 讨论在 Sprint 期间哪些进展顺利，遭遇到哪些问题以及这些问题是如何解决（或未解决）的。

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

Sprint Retrospective 结束 Sprint 。它是有时间盒限定的，以一个月的 Sprint 来说，最多为 3 个小 时。对于更短的 Sprint ， Sprint Retrospective 通常所需的时间更短。

Scrum 工件

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

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

● 对于 Product Backlog 而言，它是 Product Goal。
● 对于 Sprint Backlog 而言，它是 Sprint Goal 。
● 对于 Increment 而言，它是 Definition of Done。

这些承诺的存在是为了强化经验主义和 Scrum Team 及其利益攸关者的 Scrum 价值观。

Product Backlog

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

能够被 Scrum Team 在一个 Sprint 中完成（Done）的 Product Backlog 条目被认为准备就绪，在Sprint Planning 事件中可供选择。它们通常在精化活动后获得这种透明度。Product Backlog 精化是 将 Product Backlog 条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为Product Backlog 条目增添细节，例如描述、优先顺序和规模。这些属性通常随工作领域而变化。

将要做这项工作的 Developers 负责使其适当的大小。Product Owner 可以通过帮助 Developers 理解 和权衡取舍来影响他们。

承诺： 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 的可执行计划（如何做）组成。

Sprint Backlog 是 Developers 为其制定的计划。它是 Developers 在 Sprint 期间为实现 Sprint Goal 而 计划完成的工作，是一个高度可视且实时的工作画面。因此，随着学到更多， Sprint Backlog 在整 个 Sprint 期间会进行更新。它应该有足够的细节，以便他们可以在 Daily Scrum 中检视其进展。

承诺： Sprint Goal

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

Sprint Goal 在 Sprint Planning 事件中确定，然后添加到 Sprint Backlog 中。当 Developers 在 Sprint 期间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同，他们将与 Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次 Sprint Backlog 的范围。

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。
Definition of Done 通过使每一个人对作为 Increment 的一部分、什么样的工作算是已完成的工作有 一个共同的理解来创建透明。如果一个 Product Backlog 条目不符合 Definition of Done ，那么它就 不能发布，甚至不能在 Sprint Review 中展示它。相反， 它返回到 Product Backlog 中以供将来考虑。

如果 Increment 的 Definition of Done 是组织标准的一部分，那么所有 Scrum Team 都必须以此为最
低标准来遵守。如果它不是组织标准的一部分，那么 Scrum Team 必须制定适合于该产品的 Definition of Done 。

Developers 需要遵守 Definition of Done。如果有多个 Scrum Team 在同一产品上一起工作，那么他 们必须一起制定并遵守同样的 Definition of Done 。

一、敏捷思想理念总结

1 、2001 年敏捷宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观:

• 个体与互动 重于 流程和工具
• 工作的软件 重于 详尽的文档
• 客户协作 重于 合同谈判
• 响应变化 重于 遵循计划
  也就是说，尽管右项有其价值，我们更重视左项的价值。

2 、敏捷 12 原则：

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意

• 欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化

• 经常地交付可工作的软件，相隔几个星期或一两个月，倾向于采取较短的周期

• 业务人员和开发人员必须相互合作，项目中的每一天都不例外

• 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达 成目标

• 不论团队内外，传递信息效果最好效率也是最高的方式是面对面的交谈

• 可以工作的软件进度的首要度量标准

• 敏捷过程提倡可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定延续

• 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强

• 以简洁为本，它是极力减少不必要工作量的艺术

• 最好的架构、需求和设计出自自组织团队

• 团队定期地反思如何能够提高成效，并依此调整自身的举止表现

3 、敏捷核心实践和原则

包括但不限于以下：

• 在迭代中尽早演示交付的价值
• 用户故事反映商业价值和优先级
• 客户持续改进
• 所有需求的验收测试 回顾
• 可持续的节奏或速度 沟通
• 高度可视化

敏捷不包含什么

• 预先的设计和需求收集
• 项目完工预测
• 死亡行军项目：项目团队为弥补估算差距无偿加班
• 强迫使用工具，例如任务管理工具
• 自上而下管理和控制
• 大量文件，特别的状态报告，软件架构图，软件需求规格说明书，测试计划

敏捷益处

• 强调协同合作，团队授权，频繁过程演示
• 轻量级，依靠白板，概要卡片和便利性工具
• 吸引开发者的开发重点
• 更快的上市时间和高优先级特征驱动开发生命周期,
• 关注,拉而不是推
• 容易理解
• 满足客户的需要

二、敏捷里的“3355”-Scrum 角色 工件 活动

SCRUM 整体框架视图
（3 种角色、 5 个仪式、 3 个工件、 5 个价值观）

(开放Openness, 专注Focus, 勇气Courage, 承诺Commitment, 尊重Respect)

1 、Scrum 概述

Scrum 是用于管理产品开发的单个团队过程框架。该框架包含 Scrum 角色、事件、 工件和规则，采用迭代方法来交付工作产品。

1）Scrum 流行的原因：

• Scrum 提供简单和可证明的结果
• 它包含其他敏捷工程技术
• 它强调小型团队和团队授权
• 欢迎需求的变更
• 它允许单一来源的优先项目工作开展
• Scrum 会议包括日常状态会议
• 提供团队在冲刺阶段一个潜在的可交付增量承诺

2）Scrum 三大支柱

透明性：

• 过程或项目的各个方面必须是对结果负责任的，透明的；
• 运用信息发射源,让这些关键信息,如产品待办事项列表,冲刺待办事项、障碍、 - 风险和项 目进展对所有的利益相关者是透明的。

检视：

• 团队根据项目目标定期检查他们的绩效和进展；
• 他们不断寻找问题和计划的偏离。

调整：

• 基于观察期间的检查,采取必要的变更流程, 以避免问题再次发生,提高项目交付成功率。

2 、Scrum 角色

Scrum 团队由 5 到 9 个（7±2）团队成员组成。有三种类型角色：

• 产品负责人（PO）：产品负责人定义项目愿景、需求和优先级，对产品成功负责。
• Scrum Master：负责团队，并移除障碍，帮助他们实现产品负责人所设定的目标。
• 开发团队：自组织、跨职能。他们协同工作, 以确定如何最好地满足产品负责人的目标。

团队中有“鸡 ”和“猪 ”的角色，“猪 ”的角色包括 scrum master ，PO, team；“鸡 ” 的角色是指团队成员以外的管理角色

Scrum 角色的关键点

1）产品负责人：

• 清晰地表达产品待办列表项
• 对产品待办列表项进行排序，最好地实现目标和使命
• 优化开发团队所执行工作的价值
• 确保产品待办列表对所有人可见、透明、清晰，并且显示 Scrum 团队的下一步工作
• 确保开发团队对产品待办列表项有足够的理解

2）Scrum Master：

Scrum Master 负责确保所有人都能正确地理解并实施 Scrum 。因此，Scrum Master 要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。
Scrum Master 是 Scrum 团队中的服务型领导。Scrum Master 帮助 Scrum 团队外的人员了解他 们如何与 Scrum 团队交互是有益的，通过改变他们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。Scrum Master 在期望设定和管理中扮演重要角色， 以此去创建高绩效 团队。
A）Scrum Master的职责是：

• 在项目生命周期早期定义基本规则；
• 确保团队理解干系人期望；
• 同团队沟通项目愿景，有利于确保团队；
• 认识到他们的目标同项目总目标紧密一致；
• 以连贯的单元模式工作；
• 对愿景给予承诺。

B）Scrum Master制定的基本规则包括：

• 设定Scrum仪式的开始-结束时间；
• 保持对主题的专注减少分散；
• 会议期间杜绝中断；
• 允许团队成员特别是初级成员言论自由；
• 在制定决策前应广泛搜集所有成员意见。

3）团队：

• 有自主权选择如何最好地满足目标，并且为之负责。

3 、Scrum 三个工件

Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调 整的机会。Scrum 中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同 的理解。
1 产品待办列表（Product Backlog）

• 产品需求列表；

• 产品负责人对该列表进行优先级排序；

• 待办事项列表中的条目以用户故事的形式呈现；

  2 Sprint 待办列表（Sprint Backlog）

• 是产品待办列表的子表，只记录当前迭代的工作；

• 将用户故事拆分成任务，团队成员主动领取任务；

• 团队成员可以添加、删减或者更改迭代中的任务。

3 产品增量（PSPI：Potentially Shippable Product Increment）

• 团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付。
• 每次交付的用户故事必须符合验收条件。

4 、Scrum 会议(5 个仪式)

① 冲刺计划会议：

• Scrum 团队的所有成员出席，在此次会议中，开发团队识别当前冲刺开发交付的产品待办事项中的故事。
• 这个会议时间箱为：一个月的冲刺，会议时间 8 小时，4 个小时用于选择故事和4个小时估算分配。

② 每日站立会议 ：
由 Scrum Master 和开发团队参加，产品负责人可以自行选择是否参加。每日站立会议是快速专注的会议，用来分享迭代或迭代进展。
每个团队成员就他们将要完成的任务对其他人做口头承诺。 每个团队成员回答以下问题：

• “ 昨天做什么?”
• “今天将做什么?”
• “遇到了什么问题?“

每日立会只有猪的角色可以发言，鸡的角色不可以发言这次会议时间箱 15 分钟，每天发生在同一时间和地点。

③ 冲刺评审会议 ：（ review ）
这次会议是由 Scrum 团队的所有成员参加。
开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。
Sprint 评审会议的结果是一份修订的产品待办列表，确定很可能进入下个 Sprint 的产品待办 列表项。
这个会议时间箱为一个月的迭代，4 个小时，比冲刺计划会议的持续时间更短。
1 、冲刺评审是在迭代末期进行的时间盒（有指定时间限制）会议，此时不断变化的解决方案展示给利益相关者，他们的反馈得到收集。
该会议是：

• 针对冲刺末期召开；
• 被时间盒定义到四个小时，按月冲刺和较短的时间段；
• 冲刺评审会议由包括开发团队，产品负责人，Scrum Master ，和企业的利益相关者的整个团队出席；
• 这些冲刺评审会议被团队通过录音、快照来展示产品。

2 、 冲刺评审的益处
进行常规冲刺评审会议有助于：

• 产品根据利益相关者的需要在变化；
• 任何反馈或升级在即将到来的冲刺或发布中被记录和强调；
• 优先级排序的待办事项将被展示给利益相关者去评估是够满足他们的期望；
• 逐步完善未来的项目计划。

3 、 冲刺评审的重要性
在一个 2 周冲刺的项目中，没有组织冲刺会议将导致项目进度落后于整整一个月。 这是因为：

• 开发的需求没有满足利益相关者的期望；
• 为即将到来的冲刺所选择的需求，没有同利益相关者的需求保持一致。

④ 冲刺回顾会议 ：（ retrospective ）
是由 Scrum 团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括：什 么进行顺利，缺少什么，需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代，3 个小时，比迭代评审时间短。

如上图所示，所有的会议都会在每次迭代中重复。

冲刺回顾是针对迭代末期进行的时间盒（有指定时间限制）会议， 目的是认识团队可以如 何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议：

• 针对冲刺末期召开；
• 被时间盒定义到三~四个小时按月冲刺和较短的时间段；
• 由包括开发团队，产品负责人，ScrumMaster ，和企业的利益相关者的整个团队出席；
• 在冲刺回顾中，团队将认识到他们做的好的领域以及有待改进的领域。
• 来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。
• 细节包括：什么进行顺利，缺少什么，需要改变什么等等……

⑤ 待办事项梳理(Grooming)
Scrum 团队在冲刺中经常会面进行待办事项的梳理。
梳理或细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。
该会议有助于：

• 增加新用户故事；
• 丢弃不相关的用户故事；
• 估算新增加的用户故事；
• 重新估算用户故事；
• 对用户故事进行优先级重排序；
• 史诗分解成更小的用户故事。 需要记住的点：
• 梳理会议提供了调整估算范围的最佳时机；
• 利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理；
• 已经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相 关者来评审；
• 来自于运营和维护问题的反馈需要被考虑，新需求必须添加到产品待办事项中；
• 识别出的现有缺陷经过分析后，需要确保他们在梳理会议上被讨论。

三、其他常考知识点

1、敏捷教练

它是指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。
敏捷教练可以是内部教练或外部教练，教练需要：
1）跟不同团队共事时具备平衡视角；每个团队具备不同的进展节奏，可能会面临制约，需要帮助去克服；
2）忠于团队成员价值；
3）认识社会心理及团队复杂性；
4）运用有效方法解决团队面临的问题；
5）开发方法进行非侵入型干预从而改变团队动力；
6）学习真正需要什么才能让人们作为一个团队去工作。

2、仆人式领导

仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它 注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。仆人式领导的作 用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。仆人式领导按照以下顺序从事 项目工作：
1） 目的
与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目 层面而不是在人员层面优化。
2）人员
目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。
3）过程
不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价 值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。
4）特征
以下仆人式领导的特征让项目领导变得更加敏捷，促进团队的成功：
A. 提升自我意识；
B. 倾听；
C. 为团队服务；
D. 帮助他人成长；
E. 引导与控制；
F. 促进安全、尊重与信任；
G. 促进他人精力和才智提升

3、优先级技术-MoSCoW

MoSCoW 技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基于以下方面排序：
1）Must 必须有-这些需求是强制性的
2）Should 应该有-这些需求不是强制性的，但是高度渴望的
3）Could 可以有-这些需求如果满足会很好
4）Won ’t 不会有-当下可以不去满足，但是将来可以加入
在开始新一轮时间箱前，会有一个新的 MUSTs 加入。这些可能是新的需求，或者现有需求 被调整优先级进而转移成为 MUSTs。

4、Kanban 看板

看板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺或迭代的当下状 态。
1）看板是一个跟精益和及时制生产相关的概念。

• 任务板被细分成段来反映关键活动。
• 故事是由索引卡或代表的便利贴来表示。
• 卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。
• 看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。
  2）kanban 卡片
• Kanban 任务板上的每一张卡片就是 kanban 卡片。
• Kanban 卡片用来显示迭代过程。
• Kanban 任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。
• Kanban 卡片反映所有需要被跟踪的事物。例如：用户故事，缺陷，任务。
• 在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评估。
  3）简化的看板面板简化的看板面板有 3 列:
• 待完成
• 进展中
• 已完成
  任务用卡片表示，卡片状态展示在其中一列的下方。
  

5、五问法（五个为什么 5whys)

五问法是一种通过不断重复询问为什么来识别问题根本原因的技术。每个为什么的答案成为了识别下一个为什么的驱动力。
确切地说，不是强制的使用五个“为什么”来深入到问题的根源，“五 ”只是一个指示性 的数字。这种技术同鱼骨图结合起来使用提供了一个问题解决可视化过程。

6、DoD 完成的定义

它是团队需要满足的所有标准的核对单，只有可交付成果满足该核对单才能视为准备就绪可供客户使用。

7、信息发射源

信息发射源概念由 Alistair Cockburn 发明。根据他的理解，信息发射源的定义是：一个信息 发射源在任何人都可见的地方显示信息。有了信息发射源，大家不需要问任何问题。
信息发射源的特征有：
让团队成员可以看见项目和项目进展的当前状态； 大部分敏捷团队在过程中不同程度使用它。
最受欢迎的信息发射源有：
任务板；大型可视化表格，包括燃尽图；持续集成构建健康指标，包括街灯等。 信息发射源有助于对于成功验收、交付物的共识。
信息发射源用来促进干系人期望管理，对当下进行的工作可见、透明。 他们提供团队日常进展、工作质量、障碍和风险的视图。
敏捷项目中运用的一些信息发射源有：燃起图；燃尽图；看板或任务板；障碍日志

8、燃尽图&燃起图

• 燃起图
  燃起图根据工作范围展示已完成工作量。在特征驱动开发中又被称为“特征完工图
  

上图显示了在第五次迭代前后范围增加。

• 燃尽图
  燃尽图显示在一次迭代或发布中的剩余工作量。这些图可以用来追踪实际速度和预期速度 的对比，评估项目绩效。
  
  燃起图和燃尽图用来预测团队最可能的速度，团队按照这个速度去开发即将到来的冲刺或迭 代交付物，从而促进有效计划。

9、电梯演讲

10、时间箱

固定时间、固定活动
优势：专注、增加创造力、时间的价值实现程度、可用时间

11、MVP

最小可交付价值
最小可售单元
最小可行性产品

12、WIP（在制品）

在敏捷开发中，W IP 限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中 的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续 交付通道中的瓶颈是非常容易辨别的。
W IP 限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成 ”的工作 量。从根本上来讲，W IP 限制鼓励的是“完成 ”的文化。更重要的是，W IP 限制可以让阻碍 和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理 解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优势可以确保在最短 的时间内向用户交付有价值的增量，从而使得 W IP 限制成为敏捷开发中一个非常有价值的 工具。

13、用户故事