最常问的 Scrum Master 面试题

以下是最常问的 Scrum Master 面试题及其最佳答案。

1) 您对 Scrum 有何理解？

Scrum 是一个敏捷框架，用于开发、交付和维护复杂产品。它主要用于软件开发，但也可用于研究、销售、市场营销和高级技术等其他领域。它的设计目的是帮助团队协同工作。

Scrum 通常用于十人或更少成员的团队，他们将工作分解，设定小的目标，并在称为 Sprint 的固定时间迭代中完成，通常为两周，最长不超过一个月。

2) 什么是每日站会 (Daily Scrum)？

Scrum 团队会进行一个每日 15 分钟的固定时间会议，以跟踪他们的任务进度。这个例程称为每日站会。在 Sprint 结束时，团队会举行 Sprint 评审来展示已完成的工作，并进行 Sprint 回顾以持续改进。

3) Scrum 的主要用途是什么？

Scrum 可以使团队能够从经验中学习，在处理问题时进行自我组织，反思成功与失败，并进行改进。

4) 什么是敏捷软件开发？

在软件开发中，敏捷是一系列方法和行为的总称，它鼓励迭代开发和自组织团队之间的协作。这种实践涉及通过自组织、跨职能团队及其最终用户的协作努力来发现需求和开发解决方案。

敏捷主要关注适应性规划、进化式开发、早期交付和持续改进。它还鼓励对变化做出灵活的响应。

5) Scrum 中有哪些不同的角色？

以下是 Scrum 中的三个不同角色：

• 产品负责人 (Product Owner): 第一个角色是产品负责人。这是一个负责通过确定产品功能、将这些功能排序到列表中、关注即将到来的 Sprint 以及其他事项来增加投资回报率的个人。这些功能会不断重新排序和细化。
• Scrum Master: Scrum Master 负责帮助团队学习如何应用 Scrum 以确保最高的业务价值。Scrum Master 的职责是清除障碍，保护团队免受干扰，并使他们能够采纳敏捷实践。
• Scrum 团队 (Scrum Team): Scrum 团队是由一群个体组成的，他们共同努力按时满足利益相关者的需求。

6) Scrum 团队的主要职责是什么？

Scrum 团队是一个自组织的团队，由五到七名成员组成（始终少于十名成员）。

以下是 Scrum 团队的一些关键职责：

• 在每个 Sprint 中必须开发并交付可工作的产品。
• 必须确保团队成员所分配工作的归属感和透明度。
• Scrum 团队必须提供正确而简洁的信息，以确保每日站会成功。
• 团队成员之间的协作是必须的。

7) Agile 和 Scrum 有何区别？

以下是 Agile 和 Scrum 之间的主要区别列表：

8) 除了 Scrum 之外，还有哪些敏捷框架？

除了 Scrum 之外，其他一些敏捷框架包括 Kanban（使用看板）、测试驱动开发 (TDD) 和特性驱动开发 (FDD)。

9) Scrum 过程中的工件 (Artifacts) 是什么？

Scrum 过程主要有三个工件，如下所述：

• 产品待办列表 (Product Backlog): 产品待办列表包含新功能、功能变更、错误修复、基础设施变更以及确保我们能够获得个体产出的其他活动。
• Sprint 待办列表 (Sprint Backlog): Sprint 待办列表是产品待办列表的一个子集。它包含团队为实现 Sprint 目标而重点关注的任务。团队首先识别他们已从产品待办列表中完成的任务，然后将其添加到 Sprint 待办列表中。
• 产品增量 (Product Increment): 产品增量是 Sprint 中完成的所有产品待办列表项以及先前 Sprint 增量价值的组合。产出必须处于可用状态，无论产品负责人是否发布它。

10) 产品待办列表和 Sprint 待办列表之间的主要区别是什么？

以下是产品待办列表和 Sprint 待办列表之间的主要区别：

11) 您对 Scrum Master 有何理解？/ Scrum Master 是谁？

Scrum Master 是一个独特的职位，负责促进和支持团队内部 Scrum 的使用。

12) Scrum Master 做什么？/ Scrum Master 的角色是什么？

以下是 Scrum Master 的主要角色列表：

• Scrum Master 负责理解 Scrum 的理论、实践、规则和价值观。
• 他/她必须保持纪律，并确保团队遵循 Scrum 的价值观、原则和实践。
• 清除可能限制项目进度的干扰和障碍。
• 确保团队在 Sprint 中交付价值。

13) 您对 Scrum 中的用户故事 (User Story) 有何理解？

用户故事是 Scrum（敏捷软件开发）中使用的工具，它从最终用户的角度捕获功能的描述。用户故事用于创建对用户需求的简化描述。

14) 在 Scrum 中，每日站会 (Daily Stand-up sessions) 会发生什么？

在 Scrum 中，每天会举行一次站会或讨论，通常持续 15 分钟。这些每日站会用于了解以下内容：

• 哪些任务进展顺利？
• 哪些任务已完成？
• 哪些任务待处理？
• 它还指出了团队面临的障碍。
• 这次会议还有助于理解项目的整体范围和状态。
• 进一步的讨论可以在站会后进行。

15) 什么是 Scrum-ban？

Scrum-ban 是 Scrum 和 Kanban 的结合。它是一种用于满足团队需求、最小化工作批量和采用拉动式系统的方法论。它包含了 Scrum 的结构以及 Kanban 的灵活性和可视化。

16) 为什么 Scrum 测试人员鼓励自动化测试来开发项目？

Scrum 倾向于使用自动化性能或回归测试，以便尽快交付软件。

17) 您对 Sprint 0 和 Spike 有何理解？

Sprint 0: Sprint 0 指定了用于创建产品待办列表粗略骨架的少量工作。它还为估算产品发布提供了见解。Sprint 0 需要以下原因：

• 它用于创建项目骨架，以及研究 Spike。
• 保持设计最小化。
• 它用于开发一些用户故事。
• 它之所以使用，是因为其低速度和轻量级。

Spike: Spike 是一系列活动，涉及极限编程 (XP) 的研究、设计、调查、创建 POC 等。它主要用于降低技术方法的风险并获得知识，以更好地理解需求并提高可靠性。

18) Scrum 中的用户故事地图 (User-Story Mapping) 是什么？

在 Scrum 中，用户故事地图用于以易于理解系统功能、系统待办列表、发布计划和为客户提供价值的方式来表示和组织用户故事。用户故事根据其优先级在水平轴上排列。在垂直轴上，用户故事按复杂性递增的级别表示。

19) 谁编写用户故事？

通常，产品负责人负责确保敏捷用户故事的产品待办列表存在。但这并不意味着产品负责人是唯一可以编写它们的人。因此，任何人都可以编写用户故事。

编写用户故事的过程

当产品讨论开始时，团队会讨论需求，并将其记录在用户故事中。产品待办列表始终是动态的，永不固定，所以如果有人觉得有遗漏的需求或有什么可以为客户增加价值的，他们可以将其添加为待办列表中的用户故事。没有规则或指南规定只有产品负责人可以编写用户故事。编写故事的人应该理解它的含义以及如何编写，因为有一个固定的格式。

20) 编写用户故事有什么好处？

编写用户故事最大的好处是，如果任何人编写用户故事，它会给这些成员一种归属感，因为如果他们参与了编写过程，他们就能与之建立联系。我们可以在整个敏捷开发过程中编写用户故事。

21) 您对“Scrum of Scrums”有何理解？

“Scrum of Scrums”这个术语用于扩展敏捷技术，以控制和协调多个 Scrum 团队。在团队协作处理复杂任务的情况下，它是最有效的。

它还确保建立所需的透明度、协作、适应和采纳，并部署和交付产品。

22) Sprint 的一般周期是多久？

Sprint 通常是一个月或更短的时间，在此期间会创建可用且可能已发布的增量产品。但 Sprint 的持续时间可以短至一周或两周。

23) 您对 Sprint 回顾 (Sprint Retrospective) 有何理解？

Sprint 回顾是一种在 Sprint 评审后举行的会议。在这里，团队会讨论过去的错误、潜在问题以及处理这些问题的新方法。这些数据会纳入新 Sprint 的规划中。

24) 使用 Scrum 的主要缺点或劣势是什么？

以下是使用 Scrum 的一些最大缺点或劣势列表：

• Scrum 需要一个经验丰富的团队。
• Scrum 团队需要协作并致力于提供精确的结果。
• 缺乏经验的团队或经验不足的 Scrum Master 可能导致项目失败。
• 我们必须很好地定义任务；否则，项目可能会提供不准确的结果。
• Scrum 更适合小型项目，但很难扩展到更大、更复杂的项目。

25) 是否可以更改需求？

是的，任何人都可以对 Scrum 进行更改。Scrum 需要客户和利益相关者的大量反馈来改进产品。因此，更改可以用于使项目更好、更快。

26) 您如何处理 Scrum 团队？

我们应该遵循以下步骤来处理 Scrum 团队：

• 我们必须识别并解决问题的根本原因。
• 我们必须建立完全的归属感。
• 尝试化解分歧。
• 我们必须进行持续监控并提供完全的可见性。
• 我们必须强调能够补充项目的焦点领域。
• 必须有一个共同的理解来指导团队。

27) 用户故事 (User Stories)、史诗 (Epics) 和任务 (Tasks) 之间有什么区别？

以下是用户故事、史诗和任务之间的区别：

• 用户故事 (User Stories): 用户故事用于为团队提供业务需求的简单解释，这些需求来自最终用户的角度。
• 史诗 (Epics): 史诗是相关用户故事的集合，通常很大且复杂。
• 任务 (Tasks): 任务是 Scrum 中用于跟踪工作的最小单元。它是用户故事的进一步分解。通常，一个人或两个人组成的团队会处理一项任务。

28) 您对 Scrum 中的 Sprint 和 Velocity 有何理解？

在 Scrum 中，Sprint 是用于描述固定时间迭代的术语。在 Sprint 过程中会创建一个特定的产品模块或功能。Sprint 的持续时间可以是一周或两周。另一方面，Velocity 是一个用于衡量团队在 Sprint 中已完成工作量的指标。它指定了 Sprint 中完成的用户故事的数量。

29) 产品负责人有哪些不同的职责？

以下是产品负责人的一些基本职责列表：

• 产品负责人负责定义项目的愿景。
• 产品负责人必须预测客户的需求并创建适当的用户故事。
• 产品负责人对项目的进度负责。
• 产品负责人必须回答所有产品相关的问题。

30) Scrum 中的燃尽图 (Burnup) 和燃尽图 (Burndown Chart) 是什么？

燃尽图 (Burnup Chart): 燃尽图是用于跟踪已完成工作量的工具。它还代表了 Sprint/项目需要完成的总工作量。

燃尽图 (Burndown Chart): 燃尽图用于表示通过用户故事的工作。它显示了每个迭代的总工作量与已完成工作量的对比。

31) 您如何估算 Scrum 项目中的用户故事？

在 Scrum 项目中，用户故事的估算可以根据其难度进行。使用特定的量表来评估用户故事的难度。以下是一些量表类型：

• 数字大小 (1 - 10)
• T 恤尺码 (S, M, L, XL…)
• 斐波那契数列 (1, 2, 3, 5, 8…)
• 犬种 (大丹犬, 帕格…)

32) 您如何处理范围蔓延 (Scope Creep)？

范围蔓延 (Score creep) 这个术语用于指不受控制的变更，在未检查其对范围、时间、成本等的影响的情况下被添加。

我们必须遵循以下步骤来妥善处理它：

• 我们必须密切关注日常工作。
• 清晰理解并与团队沟通愿景，确保他们保持一致。
• 定期捕获、审查项目需求，以强调已批准给团队和客户的需求。
• 我们必须确保任何引入的变更都经过变更控制，并根据批准的变更请求实施它们。
• 避免过度开发 (gold plating)。

33) Scrum 中有哪些不同类型的风险？您如何处理它们？

以下是 Scrum 中一些重要的风险类型：

• 预算：它指出了超出预算的风险。
• 人员（团队）：它指出团队成员必须具备适当的技能和能力。
• Sprint（持续时间和可交付成果）：它用于指定持续时间和工作范围的添加。
• 产品（用户故事、史诗）：它指出了所有定义不清的用户故事和史诗。
• 知识和能力：它用于指定适当的资源。
• 风险管理涉及识别、评估、分析、定义和实施风险应对措施、监控和管理它们。
• 团队从项目开始到完成一直在持续地进行上述所有工作。

注意：重要的是要理解风险的影响基于风险实际发生时的接近程度。

34) MVP 和 MMP 的全称是什么？它们的使用是什么？

MVP 代表最小可行产品 (Minimum Viable Product)。这是一个精益创业概念，用于强调在产品开发过程中学习的影响。它允许通过向目标客户和用户展示初始版本来测试和理解想法。要做到这一点，一个人必须收集所有相关数据并从中学习。它主要用于生产产品、提供给用户访问，并观察产品的使用方式、感知和理解方式。它还提供了更多关于客户或用户需求的洞察。

MMP 代表最小可售产品 (Minimal Marketable Product)。它用于指定产品的描述，该产品将具有最少的功能来满足用户的需求。它还有助于组织减少上市时间。

35) Scrum Master 是一个管理层职位吗？

是的，Scrum Master 是一个管理层职位，但它不完全是经理职位。Scrum Master 的角色是管理 Scrum 过程，而不是 Scrum 团队，甚至不是开发团队。如果 Scrum Master 不是管理职位，他/她可能没有能力消除障碍。

36) Scrum Master 如何跟踪 Sprint 的进展？

以下是 Scrum Master 用来跟踪 Sprint 进展的一些方法：

• 每日站会
• Scrum 回顾
• Sprint 计划
• 逃逸缺陷
• 缺陷密度
• Sprint 燃尽图
• 团队速度

37) 风险管理的各个阶段是什么？

以下是风险管理的五个不同阶段：

• 风险识别
• 风险分类
• 风险响应
• 风险审查
• 风险关闭

38) “准备就绪定义” (Definition of Ready) 包含什么？

“准备就绪定义”是团队和产品负责人之间关于“准备就绪”意味着什么的合作协议。产品待办列表包含团队可以处理的项目列表，但检查这些项目是否处于准备状态很重要，因为它们需要被纳入 Sprint。首先，团队必须明确需要做什么以及完成用户故事或 PBI 所需的工作量。“准备就绪定义”可能因产品或团队而异。

39) 定义用户故事准备就绪状态的参数有哪些？

以下是可以用来定义用户故事准备就绪状态的一些参数列表：

• PBI 应处于已批准或同等状态，团队才能进行开发。
• 团队应识别用户故事的依赖项。
• 应存在并由团队理解验收标准。
• 验收标准应包含足够详细的功能，以便团队能够开发和测试它们。
• 应向团队提供性能标准，以便他们能够很好地理解。
• PBI 应以 Actor->Action->Outcome 的格式编写。
• 团队应了解演示用户故事的含义。

40) DoD 的意思是什么？它的用途是什么？

DoD 代表“完成定义” (Definition of Done)。它指定了一系列可交付成果，包括编写的代码、代码注释、单元测试、集成测试、设计文档、发布说明等。它由定义工作质量的任务列表组成。它用于决定 Sprint 待办列表中的一项活动是否完成。

DoD 有助于 Scrum 识别可交付成果以实现项目目标。

以下是其主要用途列表：

• 定义交付迭代所需的步骤。
• 使用合适的工具，如燃尽图，使流程更有效。
• 在整个项目生命周期中确保及时的反馈。
• 确保对产品待办列表项进行走查并得到正确理解。
• 确保 DoD 被定义为以任务为导向。
• 创建产品待办列表项的清单。
• 让产品负责人参与 Sprint 和 Sprint 回顾期间的评审。

41) 您对“仆人式领导” (Servant Leader) 一词有何理解？Scrum Master 如何成为仆人式领导？

“仆人式领导”一词主要指领导者应展现的服务导向。Scrum Master 应充当协调员、指导者、导师等。通过使用这种技术，团队可以增加参与度和赋权。

42) 如何协调多个团队？

有很多方法可以协调多个团队。其中最常用的策略之一是 Scrum of Scrums (SoS) 会议。在会议中，每个 Scrum 团队的代表讨论进度、绩效、问题、风险等。团队应预先定义会议的频率。通常，Scrum Master 会代表一个特定的 Scrum 团队，此外还有首席 Scrum Master（负责协调和协作所有 Scrum），他/她负责促进这些会议。

43) Scrum Master 如何提高开发团队的生产力？

Scrum Master 可以通过促进团队的决策和消除障碍来快速提高开发团队的生产力。Scrum Master 不管理开发团队。但是，Scrum Master 通过推广团队的选择、消除障碍以及保护他们免受外部干扰来提供帮助。