2025年Scrum框架专项突破测试卷

2025年Scrum框架专项突破测试卷考试时间：______分钟总分：______分姓名：______一、请简述敏捷宣言的四个核心价值观，并分别举例说明如何在Scrum实践中体现这些价值观。二、Scrum中有哪些核心角色？请分别描述每个角色的主要职责。说明ScrumMaster和产品负责人（ProductOwner）在促进团队和产品成功方面，各自扮演的关键不同角色。三、解释Scrum中的“Sprint”。一个Sprint的典型时间长度是多少？Sprint开始时必须明确什么？Sprint结束时必须交付什么？请说明Sprint评审会议和Sprint回顾会议的主要目的和区别。四、产品待办列表（ProductBacklog）是什么？它由谁负责维护？请描述产品负责人管理产品待办列表的主要活动，例如添加、移除或重新排序项。解释“产品待办列表排序”的重要性，并说明产品负责人可能使用哪些因素来排序。五、Sprint待办列表（SprintBacklog）是如何创建的？请说明Sprint计划会议的目的、参与者以及预期的产出物。开发团队如何在Sprint期间管理Sprint待办列表？ScrumMaster在Sprint计划会议中扮演什么角色？六、什么是Increment（增量）？请说明Scrum中“完成”的定义（DefinitionofDone,DoD）的重要性。为什么Scrum强调交付“潜在可用的Increment”？七、请描述每日Scrum（DailyScrum）的目的、时间和标准时长。谁主持每日Scrum？请说明ScrumMaster在促进每日Scrum方面的作用。如果开发团队成员发现他们偏离了Sprint目标，每日Scrum应该如何帮助他们？八、产品负责人如何准备Sprint评审会议？请说明Sprint评审会议的目的、参与者以及预期的活动流程。在Sprint评审会议上，开发团队的角色是什么？产品负责人可以接受哪些类型的反馈？九、请描述Sprint回顾会议的目的、时间和标准时长。Sprint回顾会议通常涉及哪些活动？请说明开发团队和产品负责人在Sprint回顾会议中可能讨论的主题。如何确保Sprint回顾会议的成果能够转化为具体的改进措施？十、解释Scrum中的“透明度”原则。请列举Scrum框架中至少三个体现透明度的工件或实践。为什么透明度对于Scrum的成功至关重要？十一、ScrumMaster的主要职责是什么？请描述ScrumMaster如何帮助产品负责人有效地管理工作和个人。ScrumMaster如何促进开发团队的自组织和跨功能性？ScrumMaster与组织中的其他角色（如项目经理、部门经理）如何互动？十二、开发团队有哪些特定的角色和责任？请说明为什么开发团队应该是自组织的。什么是跨功能性？开发团队的跨功能性如何帮助实现Sprint目标？十三、请解释Scrum中的“检查”（Inspection）和“适应”（Adaptation）原则。在Scrum实践中，这些原则是如何体现的？例如，Sprint评审会议和Sprint回顾会议分别体现了这两个原则中的哪一个或哪几个方面？十四、什么是“任务板”（TaskBoard）？它属于Scrum工件吗？请说明任务板在Scrum实践中的潜在用途，并讨论其可能带来的好处和风险。十五、假设你是一个Scrum团队的开发团队成员。在Sprint中期，产品负责人提出希望对产品待办列表中的一个高优先级用户故事进行重大修改。请描述你会如何响应这一情况，并说明这涉及到Scrum框架中的哪些实践或原则？试卷答案一、敏捷宣言的四个核心价值观是：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。*解析思路：考察对敏捷宣言核心内容的记忆。要求不仅列出四个价值观，还要理解每个价值观的含义，并能结合Scrum实践给出例子。例如，个体和互动高于流程和工具，体现在Scrum强调人（团队成员、PO、SM）的沟通和协作，而非仅仅遵循严格的流程；工作的软件高于详尽的文档，体现在每个Sprint交付可工作的软件增量，以此作为沟通的基础，而非过度依赖文档；客户合作高于合同谈判，体现在PO与客户或利益相关者紧密合作，持续获取反馈并调整产品待办列表；响应变化高于遵循计划，体现在Scrum的Sprint周期和滚动式规划，能够根据反馈灵活调整计划。二、Scrum的核心角色有：产品负责人（ProductOwner）、ScrumMaster、开发团队（DevelopmentTeam）。*产品负责人（ProductOwner）：负责最大化产品待办列表的价值；管理产品待办列表；确保开发团队理解产品待办列表中的项；代表客户或产品所有者的利益。*ScrumMaster：服务的艺术，帮助大家理解Scrum；移除Scrum实施过程中的障碍；促进Scrum团队和Scrum组织采用Scrum。*开发团队（DevelopmentTeam）：负责在每个Sprint中创建一个“潜在可用的Increment”；它是自组织的；它是跨职能的。*解析思路：考察对Scrum三大角色的定义和职责的掌握。要求准确列出所有核心角色，并对每个角色的主要职责进行清晰描述。重点在于区分他们的不同职责，特别是ScrumMaster侧重于帮助团队理解和实践Scrum、移除障碍、促进adoption，而产品负责人侧重于产品本身的价值和产品待办列表的管理。三、Sprint是一个固定的、时间有限的周期（通常为1-4周），期间团队致力于完成一系列承诺的任务，交付一个“潜在可用的Increment”，并完成计划好的所有Sprint活动。*一个Sprint的典型时间长度：1到4周。*Sprint开始时必须明确：Sprint目标（SprintGoal）和Sprint待办列表（SprintBacklog）。*Sprint结束时必须交付：一个“潜在可用的Increment”（PotentiallyShippableIncrement）。*Sprint评审会议的目的：检查Sprint的成果，并根据需要调整产品待办列表。*Sprint回顾会议的目的：参与者反思如何在Sprint中工作，以便在下一个Sprint中改进。*区别：Sprint评审会议是展示Sprint成果、收集反馈并获取对产品待办列表的共识，关注“交付什么”；Sprint回顾会议是团队反思过程、识别改进机会并制定改进计划，关注“如何改进”。*解析思路：考察对Sprint基本概念和流程的理解。要求准确回答关于Sprint时长、启动条件、结束交付物以及两个关键会议的目的和区别。区分Sprint评审（关注结果和产品待办列表）与Sprint回顾（关注过程和改进）是关键。四、产品待办列表（ProductBacklog）是按优先级排序的用户故事、需求、需求增量、任务或其他任何可选项的列表，它描述了产品需要完成的工作。*由谁负责维护：产品负责人（ProductOwner）。*产品负责人管理产品待办列表的主要活动：*添加：根据产品愿景、市场需求、反馈等，向产品待办列表中添加新的项。*移除：从产品待办列表中移除不再相关或不再必要的项。*重新排序：根据业务价值、依赖关系、风险、开发成本等因素，调整产品待办列表中项的优先级。*细化：在需要时，将高优先级的项分解为更小的、更易于理解的子项。*产品待办列表排序的重要性：确保开发团队首先处理对产品价值最大的工作，从而最大化Sprint的价值和投资回报。*排序因素：通常包括业务价值、客户优先级、依赖关系、风险降低、开发成本、技术难度、依赖其他项的完成等。*解析思路：考察对产品待办列表定义、所有权、管理活动及排序重要性的理解。要求清晰说明PO的职责范围，并列举常见的排序因素及其原因。五、Sprint待办列表（SprintBacklog）是开发团队为完成Sprint目标而选择的ProductBacklog项，以及为交付潜在可用的Increment所需的所有计划工作（如任务分解）。*如何创建：在Sprint计划会议（SprintPlanningMeeting）中，开发团队与产品负责人一起，从产品待办列表中选择要在当前Sprint中完成的项，并对这些项进行分解、估算工作量，从而创建Sprint待办列表。*Sprint计划会议的目的：确定Sprint目标，选择Sprint待办列表中的项，并为Sprint待办列表中的项制定计划。*参与者：开发团队、产品负责人、ScrumMaster（通常观察者）。*预期的产出物：Sprint目标、Sprint待办列表、开发团队对Sprint待办列表中项的初步计划（通常是任务分解和工作量估算）。*开发团队如何在Sprint期间管理Sprint待办列表：开发团队负责在整个Sprint期间跟踪Sprint待办列表的进度，根据每日Scrum的反馈和实际情况，可能需要调整计划（如重新排序、增加或减少任务工作量）。他们确保所有承诺的工作都能在Sprint结束时完成。*ScrumMaster在Sprint计划会议中的角色：促进会议的进行，确保团队理解Sprint目标和产品待办列表项，帮助团队移除障碍，确保会议在时间结束时结束。*解析思路：考察对Sprint待办列表构成、创建过程（特别是Sprint计划会议的作用）、团队在Sprint中的管理职责以及ScrumMaster在会议中的角色的理解。六、Increment（增量）是Sprint完成后产生的“潜在可用的产品增量和所有previousIncrements的集合”。它应该是产品待办列表中所有项的综合，并且满足Scrum中“完成”的定义。*“完成”的定义（DoD）的重要性：DoD为开发团队提供了清晰的标准，确保他们交付的是高质量、可用的软件。它使得开发团队可以预测工作，使得产品负责人可以可靠地评审，并确保Sprint的交付物是“潜在可用的”。它促进了透明度和协作。*为什么强调交付“潜在可用的Increment”：因为Scrum旨在通过短迭代快速响应变化和获取反馈。交付一个“潜在可用的Increment”意味着它达到了一定的质量标准，可以在不损害其他功能的情况下被演示、潜在地部署或使用，从而允许团队获取早期反馈，并在后续Sprint中基于这些反馈进行改进和调整。*解析思路：考察对Increment定义、DoD重要性的理解，以及为什么强调交付“潜在可用”的特性。需要解释DoD的作用（提供标准、促进协作、透明度）以及“潜在可用”的含义和目的（快速反馈、迭代演进）。七、每日Scrum（DailyScrum）是一个简短的（15分钟）、日常的会议，在每天的同一时间举行，目的是让开发团队同步进度、创建计划以实现Sprint目标，并识别任何妨碍进展的障碍。*目的：同步团队成员关于Sprint目标的进展、计划当天的工作以及识别impediments（障碍）。*时间：通常在Sprint期间每天举行一次，时间固定。*标准时长：15分钟。如果会议超时，说明团队需要更有效地进行每日Scrum。*主持者：由开发团队自己选择一名成员主持，该成员轮流担任，称为“每日ScrumMaster”，但ScrumMaster仍然是该角色的服务型专家，负责确保会议按时开始并遵守规定时长。*ScrumMaster在促进每日Scrum方面的作用：确保团队每天在同一时间开始会议；如果团队未能遵守15分钟的时间限制，ScrumMaster需要找出原因并帮助团队改进；移除团队在每日Scrum中遇到的障碍；确保会议聚焦于Sprint目标和进度同步，而不是问题解决或详细讨论。*如果偏离目标，每日Scrum如何帮助：每日Scrum提供了一个结构化的机会，让团队成员快速暴露他们遇到的困难或阻碍（如技术难题、依赖问题、需求不明确等）。通过站会自下而上的信息流，团队可以共同识别问题，并讨论可能的解决方案或需要的支持，从而帮助团队重新聚焦并努力达成Sprint目标。*解析思路：考察对每日Scrum的核心目的、时间、时长、主持机制以及ScrumMaster角色的理解。特别要强调其“同步”、“计划当天”、“识别障碍”的功能，以及如何通过每日Scrum帮助团队解决偏离目标的问题。八、产品负责人（ProductOwner）在准备Sprint评审会议时，会确保Sprint待办列表中选定的项已经完成，并且符合“完成”的定义。他/她会准备演示材料（如演示文稿、用户故事地图、演示环境等），以便清晰地展示Sprint的成果。他/她还需要准备回答开发团队的问题，并收集来自利益相关者的反馈。*Sprint评审会议的目的：检查Sprint的成果，并根据需要调整产品待办列表。*参与者：开发团队、产品负责人、ScrumMaster、客户代表、其他利益相关者。*预期的活动流程：*开发团队演示他们完成的SprintIncrement，通常由开发团队成员轮流介绍他们所做的工作和贡献。*产品负责人解释Sprint目标以及为什么某些项被包含在Increment中或未包含。*利益相关者提供反馈，包括对Increment的演示、功能、设计等方面的意见。*产品负责人根据反馈，讨论并可能调整产品待办列表。*开发团队的角色：演示他们完成的SprintIncrement，回答利益相关者的问题，接受反馈。*产品负责人可以接受哪些类型的反馈：关于产品功能、用户体验、设计、技术实现、业务价值、市场适应性等方面的任何反馈。产品负责人是最终决定如何响应这些反馈的人。*解析思路：考察对Sprint评审会议准备、目的、参与者、流程以及各角色职责的理解。明确PO在准备和会议中的角色，以及PO可以接收的反馈范围。九、Sprint回顾会议是一个灵活的、面向未来的会议，目的是让参与Sprint的所有成员反思过去一个Sprint中的经验，识别改进机会，并创建一个改进计划，以在下一个Sprint中实施这些改进。*目的：反思如何在Sprint中工作，以便在下一个Sprint中改进。*时间：通常在Sprint评审会议之后、Sprint结束时举行。*标准时长：通常不超过1小时。对于较短的Sprint，会议时间也应相应缩短。*参与者：开发团队、产品负责人、ScrumMaster。*Sprint回顾会议通常涉及的活动：*开场：设定会议的基调，明确目标是改进，而非责备。*团队贡献：每个成员简要说明他们在Sprint中做了什么，以及他们认为自己做得好的地方。*反思：团队一起讨论以下问题：*我们做得好的地方是什么？（成功之处）*我们哪些地方可以做得更好？（挑战、困难、失败之处）*我们学到了什么？*识别改进机会：基于反思，团队识别出需要改进的具体领域。*创建改进计划：团队讨论并确定在下一个Sprint中要采取的具体行动步骤来改进这些领域。这些行动应该是具体的、可衡量的、可实现的、相关的、有时限的（SMART原则）。*如何确保成果转化为具体改进措施：关键在于会议的后半部分，即识别改进机会和创建改进计划。需要确保讨论具体化，而不是停留在笼统的抱怨或建议。改进计划应该是清晰、可执行、并且有明确的负责人和完成时间点。ScrumMaster可以引导团队确保计划是可行的，并帮助跟踪后续的改进实施情况。*解析思路：考察对Sprint回顾会议的目的、时间、参与者、核心活动流程的理解。重点在于解释会议如何通过反思（成功与失败）来识别改进机会，以及如何将反思转化为具体的、可操作的改进计划。十、透明度原则是指Scrum的工件、实践和事件必须是可见的，对于所有相关方来说都是可获得的。这意味着信息（如产品待办列表的状态、Sprint进度、完成的Increment、会议纪要等）应该被公开，以便所有需要了解情况的人都能看到。*Scrum框架中体现透明度的工件或实践：*工件：产品待办列表（及其优先级）、Sprint待办列表、Increment（完成的软件）、任务板（如果使用）、燃尽图、Sprint评审会议和Sprint回顾会议的记录。*实践/事件：每日Scrum（让进展可见）、Sprint评审会议（展示成果和获取反馈）、Sprint回顾会议（反思过程和识别改进）。*为什么透明度对于Scrum的成功至关重要：透明度是信任的基础。它使得所有相关方能够了解项目的状态、进展和挑战，从而做出更明智的决策。透明度有助于及早发现问题，并让团队能够共同协作解决问题。它支持检查和适应原则，因为只有信息是可见的，团队和组织才能有效地检查进展并根据需要进行调整。透明度促进了责任和问责制。*解析思路：考察对透明度原则的定义及其在Scrum中的具体体现。要求列举多个工件和实践作为例子，并阐述透明度为何是Scrum成功的关键因素（建立信任、支持决策、及早发现问题、支持检查适应、促进责任）。十一、ScrumMaster的主要职责是服务于Scrum团队、产品负责人和组织，以最大化Scrum的价值。具体职责包括：*服务的艺术：帮助大家理解Scrum理论和实践；移除Scrum实施过程中的障碍（Impediments）；促进Scrum团队和Scrum组织采用Scrum。*帮助产品负责人：协助产品负责人有效地管理工作和个人；帮助产品负责人有效地沟通；移除阻碍产品负责人工作的障碍。*促进开发团队：教导Scrum理论和实践；帮助开发团队理解“完成”的定义；移除开发团队遇到的障碍；促进开发团队的自组织和跨功能性；教练团队采用最佳实践（如测试驱动开发、持续集成等）。*与组织中的其他角色互动：作为Scrum框架内外的连接点，帮助Scrum团队理解组织中的角色和职责；帮助组织理解Scrum团队的工作方式和价值；在必要时，协助Scrum团队克服组织障碍，推动Scrum的规模化实施。*解析思路：考察对ScrumMaster角色“服务型专家”定位的理解。要求详细列举其核心职责，包括服务团队、支持PO、赋能开发团队，以及作为沟通桥梁和变革推动者的作用。十二、开发团队（DevelopmentTeam）是Scrum团队中负责创建产品Increment的成员集合。*特定的角色和责任：*自组织：他们决定如何最好地完成他们的工作，包括如何将产品待办列表中的项分解为更小的任务、如何分配任务给团队成员、如何安排工作时间、如何管理其进度等。他们不需要外部指令或监督来组织自己。*跨职能：开发团队拥有完成所有工作所需的所有技能。他们不需要依赖外部团队或资源来交付SprintIncrement。开发团队成员通常具备多种技术能力（如开发、测试、设计、文档编写等）。*承诺Sprint目标：在Sprint计划会议上，开发团队选择要完成的项，并承诺在Sprint结束时交付一个满足“完成”定义的、潜在可用的Increment。*负责SprintBacklog：开发团队负责在整个Sprint期间跟踪SprintBacklog的进度，确保所有承诺的工作都得到完成。*开发团队的跨功能性如何帮助实现Sprint目标：因为开发团队拥有完成工作所需的所有技能，他们可以独立地、高效地构建、测试和集成产品功能。这减少了对外部依赖的需求，加快了开发速度，并提高了产品质量。跨功能性使得团队能够灵活地应对需求变化和解决开发过程中出现的问题，从而更好地聚焦于实现Sprint目标。*解析思路：考察对开发团队核心特征（自组织、跨职能）及其职责的理解。要求解释自组织和跨职能的含义，并说明这些特征如何帮助团队更有效地实现Sprint目标。十三、*检查（Inspection）：指在Sprint周期结束时，检查ScrumIncrement是否满足“完成”的定义，并检查Sprint目标是否达成。Scrum通过Sprint评审会议进行主要的检查活动，通过Sprint回顾会议检查团队的过程。其他检查活动可能包括每日Scrum中对进度的检查、对产品待办列表项完成度的检查等。检查是识别变化需求或问题的过程。*适应（Adaptation）：指根据检查的结果，调整产品待办列表、Sprint待办列表或Sprint目标。Scrum通过Sprint评审会议后产品负责人调整产品待办列表、Sprint回顾会议后团队制定改进计划（可能影响下一个Sprint的工作方式）以及开发团队在Sprint中根据每日Scrum的反馈调整工作计划来实现适应。*Scrum中如何体现：*Sprint评审会议：体现了检查（检查Increment和目标达成情况）和适应（调整产品待办列表）。*Sprint回顾会议：体现了检查（检查团队过程的有效性）和适应（制定并承诺下一个Sprint的改进措施）。*每日Scrum：主要体现了检查（检查当天进度和障碍）。*解析思路：考察对检查和适应这两个Scrum原则的定义及其内在联系（检查是基础，适应是结果）的理解。要求结合Scrum的关键事件（评审会、回顾会、每日Scrum）说明这两个原则是如何在实践中应用的。十四、任务板（TaskBoard）是一个可视化工具，通常用于显示SprintBacklog中的项及其状态（例如，“待办”、“进行中”、“已完成”）。它可以帮助开发团队跟踪任务的进度，了解彼此的工作负载，并协调工作。*是否属于Scrum工件：任务板本身不是Scrum指南中明确定义的“工件”（如产品待办列表、Sprint待办列表、Increment）。Scrum指南鼓励使用各种可视化工具来辅助实践，任务板是其中最常用的一种。因此，可以说它是一个推荐的实践工具，但不是官方定义的核心工件。*潜在用途：*可视化进度：使团队成员和观察者能够一目了然地看到每个任务的状态和整体Sprint进度。*促进沟通：提供了一个共同的基础，方便团队成员讨论任务、分配工作、协调依赖。*提高透明度：增加了SprintBacklog的透明度，有助于识别瓶颈和延迟。*支持每日Scrum：为每日Scrum提供焦点，让团队成员快速了解当天需要做什么、完成了什么、遇到了什么问题。*好处：提高效率、增强协作、提升透明度、促进责任感、有助于进行有效的每日Scrum。*风险：可能导致任务过细化、团队关注任务而非用户故事本身、可能产生“为了填满板而填满板”的压力、可能成为沟通的障碍而不是促进沟通的