2026年敏捷项目考试试题及答案

2026年敏捷项目考试试题及答案一、单项选择题（每题1分，共20分）1.在Scrum框架中，以下哪项是ScrumMaster的核心职责？A.直接参与用户故事的开发编码B.管理产品待办列表（ProductBacklog）的优先级C.移除团队交付价值过程中的障碍D.决定冲刺（Sprint）的目标和时长答案：C2.看板方法（Kanban）中“限制在制品（WIPLimit）”的主要目的是？A.强制团队减少任务数量以提高效率B.确保每个任务在制品阶段的完成质量C.暴露流程中的瓶颈并促进流动D.简化团队的工作量统计答案：C3.极限编程（XP）的核心实践中，“持续集成（ContinuousIntegration）”强调的是？A.每天至少集成一次代码并进行自动化测试B.每周进行一次大规模集成测试C.仅在冲刺结束时集成所有功能D.由专门的集成团队负责代码合并答案：A4.敏捷团队在估算用户故事时，使用“规划扑克（PlanningPoker）”的主要优势是？A.快速得出精确的时间估算结果B.避免团队中权威人物对估算的过度影响C.直接转化为任务分解的具体小时数D.强制团队成员达成完全一致的估算值答案：B5.以下哪项不符合敏捷宣言（AgileManifesto）的价值观？A.可工作的软件重于详尽的文档B.遵循计划重于响应变化C.客户协作重于合同谈判D.个体与交互重于流程与工具答案：B6.在SAFe（规模化敏捷框架）中，“发布火车（ART）”的主要作用是？A.协调多个敏捷团队同步交付增量B.统一所有团队的开发工具和流程C.制定跨季度的详细项目计划D.替代产品负责人进行需求管理答案：A7.敏捷团队进行“冲刺回顾（SprintRetrospective）”时，核心目标是？A.评估冲刺目标的完成情况B.讨论并改进团队的工作流程和协作方式C.重新规划下一个冲刺的用户故事D.向利益相关者展示已完成的功能答案：B8.当敏捷团队遇到需求频繁变更时，正确的应对方式是？A.拒绝变更，要求客户待当前冲刺结束后再提出B.通过产品待办列表（ProductBacklog）重新排序需求，调整冲刺范围C.增加团队成员以应对额外的工作量D.延长当前冲刺的时长以容纳变更答案：B9.以下哪项是“用户故事（UserStory）”的标准模板？A.作为[角色]，我需要[功能]，以便[商业价值]B.系统需要[功能]，因为[技术需求]C.开发团队将[行动]，以实现[目标]D.客户希望[结果]，通过[方法]答案：A10.在Scrum中，“产品负责人（ProductOwner）”的核心职责不包括？A.确保产品待办列表的可见性和透明性B.与利益相关者沟通以明确需求优先级C.参与每日站会（DailyScrum）并分配任务D.确认冲刺产出的增量是否满足验收标准答案：C11.看板方法中的“服务等级协议（SLA）”主要用于？A.定义团队内部的任务处理时间承诺B.约束客户的需求变更频率C.规定开发工具的使用规范D.明确测试团队的缺陷修复时限答案：A12.敏捷估算中的“故事点（StoryPoint）”与“小时数（Hour）”的本质区别是？A.故事点基于相对复杂度，小时数基于绝对时间B.故事点仅用于Scrum，小时数仅用于看板C.故事点需要精确计算，小时数可以粗略估算D.故事点由产品负责人决定，小时数由开发团队决定答案：A13.当分布式敏捷团队（跨时区）进行每日站会时，最有效的调整方式是？A.要求所有成员在同一时区的固定时间参会B.使用异步工具（如留言、视频录制）共享状态，减少实时会议C.取消每日站会，改为每周一次线下会议D.由ScrumMaster汇总信息后同步给所有成员答案：B14.以下哪项属于敏捷团队“自组织（Self-Organizing）”的表现？A.团队成员主动协商任务分配，无需外部指令B.ScrumMaster制定详细的开发计划并监督执行C.产品负责人直接指导开发人员的编码细节D.团队严格遵循公司级项目管理流程答案：A15.在XP的“测试驱动开发（TDD）”中，正确的执行顺序是？A.编写测试用例→编写代码使测试通过→重构代码B.编写代码→编写测试用例→修复代码使测试通过C.设计功能→编写代码→编写测试用例D.重构代码→编写测试用例→验证功能答案：A16.敏捷团队在“冲刺评审（SprintReview）”中，主要参与者不包括？A.产品负责人B.开发团队C.关键利益相关者D.公司高层管理者答案：D（注：高层管理者非必须，但需根据具体场景判断，通常关键利益相关者包括用户、客户代表等）17.看板方法中“流动效率（FlowEfficiency）”的计算公式是？A.增值时间/总前置时间×100%B.完成任务数/总任务数×100%C.平均在制品数量/平均前置时间D.缺陷数/总功能数×100%答案：A18.当Scrum团队连续多个冲刺未能完成冲刺目标时，最可能的原因是？A.冲刺目标设定过于保守B.产品负责人未参与每日站会C.团队在估算用户故事时高估了自身产能D.ScrumMaster频繁干预团队决策答案：C19.以下哪项符合“敏捷可测试性（Testability）”的要求？A.所有测试由专门的测试团队在冲刺结束后执行B.用户故事包含明确的验收标准（AcceptanceCriteria）C.仅关注功能测试，忽略性能和安全测试D.测试用例在开发完成后一次性编写答案：B20.在SAFe的“团队层（TeamLevel）”中，核心实践不包括？A.使用Scrum或看板进行迭代开发B.执行系统演示（SystemDemo）C.进行团队级的冲刺计划和回顾D.管理团队级的待办列表答案：B（系统演示属于项目群层或大型解决方案层）二、简答题（每题8分，共40分）1.简述Scrum框架中的三大角色及其核心职责。答案：Scrum框架包含三大角色：（1）产品负责人（ProductOwner）：负责管理产品待办列表（ProductBacklog），定义需求优先级，确保开发团队交付的增量符合业务价值，与利益相关者沟通以明确需求。（2）开发团队（DevelopmentTeam）：自组织完成冲刺目标，负责将用户故事转化为可交付的增量，具备跨职能技能（如开发、测试、运维）。（3）ScrumMaster：服务型领导，确保团队遵循Scrum规则，移除交付障碍，辅导团队提升敏捷实践能力，促进透明化和持续改进。2.看板方法的六大实践是什么？请简要说明。答案：看板方法的六大实践包括：（1）可视化工作流程：将任务从“待办”到“完成”的全流程用看板面板直观展示，明确各阶段节点。（2）限制在制品（WIPLimit）：为每个流程阶段设置任务数量上限，避免多任务处理，暴露瓶颈。（3）管理流动：通过监控前置时间（LeadTime）和周期时间（CycleTime），优化任务在流程中的流动效率。（4）明确政策：定义每个流程阶段的进入/退出标准（如“完成的定义”DoD），确保团队对工作状态的共识。（5）使用反馈循环：通过每日站会、阶段评审等定期回顾流程，快速调整改进。（6）协作改进：鼓励团队全员参与流程优化，持续提升交付能力。3.敏捷估算中“故事点（StoryPoint）”和“小时数（Hour）”的适用场景有何不同？答案：（1）故事点：基于相对复杂度估算（如使用斐波那契数列：1,2,3,5,8...），关注任务的规模、风险和不确定性。适用于需求变化频繁、团队需要快速对齐认知的场景（如早期项目、探索性开发），避免因绝对时间估算导致的过度承诺。（2）小时数：基于绝对时间估算，明确任务所需工时。适用于需求稳定、团队对任务细节清晰（如维护性开发、技术债务处理），或需要与外部资源（如外包团队）协调的场景，但需注意小时数易受中断、技能差异等因素影响，需定期校准。4.简述敏捷团队“完成的定义（DefinitionofDone,DoD）”的作用及关键要素。答案：作用：DoD是团队对“可交付增量”的统一质量标准，确保每个用户故事在“完成”时满足所有必要条件（如测试通过、文档更新、部署可用等），避免“未完成”的任务累积，提升交付可靠性。关键要素：通常包括功能验证（通过所有验收测试）、非功能需求（性能、兼容性、安全性）、文档更新（用户手册、技术文档）、代码规范（代码审查、静态分析）、部署准备（可部署到测试/生产环境）等，具体根据团队和项目特点调整。5.当敏捷团队遇到“范围蔓延（ScopeCreep）”时，应如何应对？答案：（1）通过产品待办列表（ProductBacklog）管理需求：所有新需求需先进入待办列表，由产品负责人重新评估优先级，与现有需求比较业务价值。（2）在冲刺计划（SprintPlanning）中明确冲刺目标和范围，若需添加新需求，需评估是否影响当前目标，必要时与利益相关者协商调整目标或延长冲刺（仅在特殊情况下）。（3）利用“完成的定义”（DoD）严格验收已完成的用户故事，避免在开发过程中无限制扩展功能。（4）通过冲刺评审（SprintReview）向利益相关者展示当前增量，明确已完成和未完成的内容，管理预期。三、案例分析题（每题20分，共60分）案例1：某Scrum团队在第5个冲刺中遇到以下问题：冲刺开始时，产品负责人因紧急会议未能参与冲刺计划，导致冲刺目标仅基于部分需求制定；冲刺中期，客户提出一个高优先级需求，产品负责人直接要求开发团队暂停当前任务，优先开发新需求；冲刺结束时，原冲刺目标仅完成60%，团队成员因频繁切换任务感到疲惫，客户对交付结果不满。问题：请分析问题根源，并提出改进措施。答案：问题根源：（1）产品负责人未全程参与冲刺计划，导致冲刺目标偏离实际需求，团队对目标的共识不足；（2）产品负责人未通过产品待办列表管理需求变更，直接干预开发团队的当前任务，违反Scrum中“冲刺期间范围不变”的规则（除非重新协商目标）；（3）团队因多任务处理效率下降，且未通过每日站会及时暴露变更带来的风险。改进措施：（1）强制产品负责人参与冲刺计划，若无法到场需提前同步需求优先级和背景信息，确保团队理解目标的商业价值；（2）新需求需先进入产品待办列表，由产品负责人与团队评估对当前冲刺目标的影响：若新需求价值极高，可协商调整冲刺目标（如减少原有低优先级故事），并更新冲刺待办列表（SprintBacklog）；（3）ScrumMaster需介入，提醒产品负责人遵循Scrum规则，避免直接干预团队任务；（4）每日站会中，团队需主动沟通任务进展和阻碍（如需求变更带来的影响），ScrumMaster协助移除障碍；（5）在冲刺回顾中，团队需讨论需求变更的应对流程，制定“紧急需求插入”的规则（如仅允许在冲刺中期评估后调整，且需记录影响）。案例2：某科技公司采用看板方法管理软件开发，团队包括10名成员，分布在3个城市（北京、上海、成都）。近期团队反馈：任务在“开发”阶段堆积，前置时间（LeadTime）从2周延长至4周；远程成员因信息不同步，常重复开发或遗漏需求；团队对“完成的定义”（DoD）存在争议，部分成员认为“单元测试通过”即可，另一部分要求“集成测试通过”。问题：请结合看板方法和敏捷原则，提出解决方案。答案：解决方案：（1）针对“开发”阶段堆积：检查“开发”阶段的在制品（WIP）限制，若当前限制过高（如允许同时处理8个任务），可降低至3-5个，迫使团队聚焦完成而非启动；分析堆积原因（如开发资源不足、需求不清晰），若因需求模糊，需产品负责人增加与团队的需求澄清会议；引入“瓶颈解决机制”（如每天预留1小时专项解决开发阻塞问题），提升流动效率。（2）针对远程信息不同步：强化看板的可视化：使用在线看板工具（如Jira、Trello）实时更新任务状态，要求成员在任务变更时立即备注；调整每日站会形式：采用异步+同步结合（如远程成员提前录制1分钟视频说明进展，现场成员集中讨论），确保信息透明；建立“需求知识库”（如Confluence），存储需求文档、验收标准、常见问题解答，供所有成员随时查阅。（3）针对“完成的定义”争议：组织团队共识会议，基于项目实际需求（如客户对质量的要求、历史缺陷率）重新定义DoD；示例调整后的DoD：“单元测试通过（覆盖率≥80%）、集成测试通过、代码审查完成（至少2人评审）、用户文档更新”；将DoD写入看板的“完成”阶段入口标准，并在任务进入下一阶段前由团队共同确认，避免后期返工。案例3：某医疗软件团队采用Scrum开发电子病历系统，近期遇到以下挑战：合规性要求严格（如GDPR、HIPAA），部分用户故事需额外的安全测试和审计；领域专家（如医生、法律顾问）仅能每周参与1次会议，导