2025年acp考试试题及答案

2025年acp考试试题及答案一、单项选择题（每题2分，共60分）1.某敏捷团队在迭代规划会上，产品负责人提出新增一个用户故事，但该故事未包含在迭代待办列表中。团队当前剩余产能为5个故事点。已知该故事的估算为3个故事点，且用户故事验收标准清晰。此时团队最合理的做法是：A.直接将该故事加入迭代待办列表，调整每日任务分配B.拒绝加入，要求产品负责人将故事放入产品待办列表，下次迭代再讨论C.与产品负责人确认该故事的商业价值，若优先级高于当前迭代中的低价值故事，则替换D.要求产品负责人提供更多细节，重新估算后再决定答案：C解析：敏捷强调价值导向，当迭代中出现高优先级需求时，团队应与产品负责人评估其商业价值。若新故事价值高于当前迭代中的低价值项，可通过替换保持迭代价值最大化（《敏捷实践指南》第4章）。2.看板方法中，限制在制品（WIP）数量的主要目的是：A.减少多任务处理，提升流程可见性B.强制团队加快开发速度C.确保每个任务都能在迭代内完成D.降低团队成员的工作负荷答案：A解析：WIP限制通过减少同时进行的任务数量，避免上下文切换带来的效率损失，同时使流程瓶颈（如测试阶段堆积）更易被识别（《看板方法》第3章）。3.敏捷团队在迭代回顾会上，发现过去3次迭代中，自动化测试覆盖率从85%下降至60%，且生产环境缺陷率上升。团队讨论后认为主要原因是开发人员为追赶进度跳过了测试步骤。此时团队应优先采取的改进措施是：A.增加测试人员数量，分担测试压力B.调整迭代目标，降低故事点承诺量C.引入测试驱动开发（TDD）实践，将测试写入任务拆分标准D.要求项目经理加强进度监控，对未完成测试的成员进行考核答案：C解析：XP（极限编程）强调测试先行，TDD通过“红-绿-重构”循环确保测试与开发同步。将测试作为任务拆分的必要条件（如“完成=代码通过单元测试”）可从流程上避免跳过测试（《解析极限编程》第5章）。4.产品负责人在整理产品待办列表时，收到市场部门提出的新功能需求。该需求涉及3个用户角色，需调用外部支付接口，且可能影响现有会员系统的稳定性。产品负责人应首先：A.直接将需求加入待办列表，标记为“高优先级”B.与技术团队、市场部门共同进行需求细化（Refinement），拆分用户故事C.要求市场部门提供需求的商业价值评分（如MoSCoW法）D.召开需求评审会，邀请所有利益相关者投票决定优先级答案：B解析：需求细化是持续的过程，复杂需求需通过跨职能讨论拆分（如“作为会员用户，我需要使用微信支付完成充值”），明确依赖关系和风险（如支付接口兼容性），避免大而模糊的需求进入迭代（《敏捷产品管理》第6章）。5.某分布式敏捷团队（成员分布在上海、成都、西雅图）在每日站会上，经常出现沟通延迟（如西雅图成员因时差缺席早会）、信息传递遗漏的问题。团队应优先优化的实践是：A.调整站会时间为西雅图时区的工作时间，上海成员早起参会B.使用协作工具（如Miro）共享任务看板，会后上传会议纪要并@未参会成员C.减少站会频率，改为每2天一次，延长单次会议时间D.指定协调员负责汇总信息，会后单独向缺席成员同步答案：B解析：分布式团队需借助工具弥补地理差距。共享可视化看板（如Jira实时更新）可确保信息同步，会后上传纪要并@相关成员（如使用Slack）能减少信息遗漏，同时尊重不同时区的工作节奏（《远程团队敏捷实践》第2章）。6.迭代评审会上，客户对已交付的功能提出“操作流程不够直观”的反馈，并要求在下个迭代中增加引导动画。产品负责人认为该反馈属于优化需求，优先级低于下阶段核心功能。此时最合理的处理方式是：A.拒绝客户要求，说明当前迭代目标已锁定B.将引导动画作为用户故事加入产品待办列表，评估其商业价值后排序C.立即调整下个迭代计划，将引导动画作为最高优先级任务D.要求客户提供详细的设计稿，否则不纳入开发范围答案：B解析：客户反馈需纳入产品待办列表，但需通过价值评估（如用户调研数据、客户痛点程度）确定优先级，避免因个别反馈打乱整体路线图（《敏捷开发与用户故事》第7章）。7.敏捷团队在估算用户故事时，使用计划扑克（PlanningPoker）进行估算。某故事讨论中，成员A给出8点，成员B给出2点，其他成员多为3-5点。此时团队应：A.取平均值（8+2+3+4+5）/5=4.4，记为4点B.要求A和B说明估算依据，重点讨论差异原因C.重新投票，要求成员统一意见后再确定点数D.参考历史类似故事的估算值，直接确定为5点答案：B解析：计划扑克的核心是通过差异讨论暴露认知偏差（如A可能考虑了外部接口调用的复杂性，B可能忽略了数据验证逻辑），最终达成共识而非追求数值一致（《敏捷估算与计划》第3章）。8.Scrum团队中，当开发团队成员因个人原因需请假3天时，最恰当的处理方式是：A.由ScrumMaster协调其他成员分担其任务，确保迭代目标不受影响B.开发团队自组织调整任务分配，并更新迭代燃尽图C.产品负责人调整迭代目标，降低故事点承诺量D.延长迭代周期3天，保证原目标完成答案：B解析：Scrum强调开发团队的自组织性，成员请假时应由团队自行调整任务（如重新分配、拆分任务），并通过燃尽图透明化进度变化（《Scrum指南》2020版）。9.某团队采用Scrum框架，连续3个迭代未能完成承诺的故事点。回顾会上，团队分析发现：需求变更频繁（平均每个迭代6次）、测试环境不稳定（每周故障2次）、成员间代码依赖导致等待时间长。此时应优先解决的问题是：A.与产品负责人协商建立需求变更控制流程（如迭代中期关闭需求变更）B.投入资源修复测试环境，建立自动化环境恢复机制C.引入持续集成（CI）实践，每日合并代码并运行自动化测试D.调整团队结构，按功能模块划分小团队减少依赖答案：C解析：代码依赖导致的等待属于“任务阻塞”，持续集成通过每日合并和自动化测试（如Jenkins流水线）可尽早发现集成问题，减少后期返工（《持续交付》第4章）。10.敏捷教练在观察团队时，发现开发人员习惯在完成编码后才将任务状态改为“开发完成”，而测试人员需等待所有编码完成后才开始测试，导致测试阶段堆积。此时应建议团队采用的改进措施是：A.拆分任务为“编码完成”和“测试完成”两个子任务，逐步推进B.要求开发人员在编码过程中同步编写测试用例，完成即提交测试C.引入“完成的定义”（DoD），明确“开发完成”需包含单元测试通过D.调整看板列，增加“待测试”状态，开发完成立即转移答案：C解析：DoD（完成的定义）是团队对“完成”的共同认知。若“开发完成”需包含单元测试通过，则测试人员可尽早介入，避免批量测试堆积（《Scrum精髓》第8章）。11.产品负责人在规划产品路线图时，需平衡短期交付与长期愿景。以下哪项最符合敏捷路线图的特点？A.详细列出未来12个月每个迭代的交付功能B.基于用户故事地图，标记关键里程碑（如MVP发布、核心功能上线）C.按技术模块划分，明确每个模块的开发顺序和时间节点D.以成本控制为核心，优先开发高收益低投入的功能答案：B解析：敏捷路线图强调愿景导向和灵活性，用户故事地图通过“活动-任务-故事”分层，标记关键里程碑（如“Q3完成支付功能”），而非固定迭代细节（《用户故事地图》第5章）。12.敏捷团队在迭代中发现，某个用户故事的技术实现难度远超预期（原估算3点，实际需8点）。此时团队应首先：A.继续开发，迭代结束后在回顾会上分析估算偏差原因B.立即与产品负责人沟通，调整迭代目标（如移除其他低优先级故事）C.拆分该故事为“基础功能”和“扩展功能”，先交付基础部分D.申请延长迭代周期，确保原目标完成答案：C解析：当故事估算偏差较大时，拆分故事（如“用户登录-基础验证”和“用户登录-第三方登录”）可确保部分价值交付，避免整个故事无法完成（《敏捷用户故事实战》第4章）。13.以下哪项符合敏捷团队“自组织”的特征？A.项目经理分配具体任务给每个成员B.团队共同决定如何完成迭代目标，自主选择工作方式C.技术主管制定编码规范，成员必须遵守D.产品负责人规定每日站会的讨论顺序答案：B解析：自组织团队有权决定“如何做”（How），而“做什么”（What）由产品负责人确定，这是敏捷团队的核心特征（《敏捷宣言原则》第9条）。14.看板方法中，“流动效率”的计算方式是：A.（增值时间）/（总前置时间）×100%B.（完成的故事点）/（迭代周期）C.（在制品数量）/（团队产能）D.（缺陷修复时间）/（总开发时间）答案：A解析：流动效率反映任务从启动到完成的有效时间占比，增值时间（如编码、测试）与总前置时间（包括等待、阻塞）的比值越高，流程越高效（《加速：构建高效能技术组织的科学方法》第3章）。15.某团队尝试引入Scrum，但发现每日站会经常演变成详细的问题讨论（超过15分钟），导致成员迟到或中途离场。ScrumMaster应采取的最佳措施是：A.设定严格的时间限制（如使用计时器），超时则中断讨论B.要求成员会前同步详细进度，站会上只汇报“三问”（昨天做了什么、今天计划做什么、障碍是什么）C.调整站会形式为“走查看板”，成员依次更新任务状态并快速说明障碍D.取消每日站会，改为每2天一次的较长会议答案：B解析：每日站会的核心是同步信息（三问），而非解决问题。会前通过工具（如Jira）更新任务状态，站会上仅口头同步关键信息，可避免冗长讨论（《Scrum敏捷实践指南》第5章）。16.XP（极限编程）中的“集体代码所有权”实践意味着：A.所有代码必须由至少两名成员共同编写B.团队任何成员都可以修改任何代码，且对代码质量共同负责C.代码仓库权限对所有成员开放，无需审批即可提交D.每周进行代码所有权轮换，成员负责不同模块答案：B解析：集体代码所有权强调团队对整体代码质量的责任，成员可修改任意代码（需通过测试），避免“代码孤岛”导致的维护困难（《解析极限编程》第4章）。17.产品负责人在与客户沟通时，客户提出“希望系统能支持大数据量的快速查询”，但未明确具体性能指标。产品负责人应：A.将需求记录为“优化查询性能”，加入待办列表B.要求客户提供具体的性能目标（如“10万条数据查询响应时间≤2秒”）C.与技术团队估算优化所需的故事点，直接排入迭代D.忽略该需求，因缺乏明确性无法开发答案：B解析：用户故事需符合INVEST原则（独立、可协商、有价值、可估算、小、可测试），“快速查询”需量化为具体指标（如响应时间），否则无法验证是否完成（《用户故事与敏捷方法》第3章）。18.敏捷团队在迭代中遇到技术债务问题（如某模块代码冗余，导致后续功能开发变慢）。团队应：A.优先完成当前迭代目标，技术债务留待后续迭代处理B.分配专门的“债务迭代”集中处理C.在每个迭代中预留10%-20%的产能用于偿还债务D.要求产品负责人降低迭代目标，腾出时间修复答案：C解析：技术债务需持续管理，在每个迭代中预留部分产能（如15%）用于重构、测试完善等，避免债务累积影响长期效率（《技术债务》第2章）。19.以下哪种情况最适合采用敏捷开发？A.需求明确、技术成熟的企业资源规划（ERP）系统B.需严格符合行业监管标准的医疗信息系统C.用户需求快速变化的移动社交应用D.硬件与软件高度耦合的工业控制系统答案：C解析：敏捷适用于需求不确定、需要快速迭代反馈的场景（如移动应用），而需求明确或高合规性项目更适合瀑布或混合模型（《敏捷与瀑布的权衡》第1章）。20.Scrum的三个工件不包括：A.产品待办列表（ProductBacklog）B.迭代待办列表（SprintBacklog）C.燃尽图（Burn-downChart）D.增量（Increment）答案：C解析：Scrum的核心工件是产品待办列表、迭代待办列表和增量，燃尽图是辅助工具而非工件（《Scrum指南》2020版）。21.敏捷团队在估算时，使用“故事点”而非“小时”的主要原因是：A.故事点更易计算，无需精确到小时B.故事点反映相对复杂度，避免因技能差异导致的估算偏差C.客户更关注功能价值，而非开发时间D.小时估算会鼓励成员磨洋工，影响效率答案：B解析：故事点是相对估算单位（如以简单故事为1点，复杂故事为8点），避免因成员技能、工具差异导致的绝对时间估算不准（《敏捷估算与计划》第2章）。22.迭代回顾会的主要目的是：A.评估迭代目标完成情况，表彰优秀成员B.分析流程中的问题，制定改进措施C.与产品负责人确认下个迭代的需求D.审查已交付功能的质量，修复缺陷答案：B解析：回顾会是团队反思“如何做得更好”的机会，重点是识别改进点并制定可行动的计划（如“下周开始每日10点同步测试环境状态”）（《Scrum精髓》第9章）。23.看板方法与Scrum的主要区别在于：A.看板没有固定迭代周期，Scrum有固定的SprintB.看板强调团队自组织，Scrum依赖ScrumMasterC.看板关注流程改进，Scrum关注迭代交付D.看板使用故事点估算，Scrum使用时间盒答案：A解析：看板是流程改进框架，支持连续流动（无固定迭代），而Scrum通过固定时间盒（Sprint）推动增量交付（《看板与Scrum：如何选择》第1章）。24.产品负责人的核心职责是：A.管理开发团队，确保按时交付B.编写用户故事，完成需求文档C.最大化产品价值，维护产品待办列表D.协调资源，解决团队障碍答案：C解析：产品负责人的核心是作为“商业代表”，通过排序产品待办列表（基于价值、风险等）最大化产品价值（《Scrum指南》2020版）。25.敏捷团队中，“客户协作高于合同谈判”是指：A.与客户保持频繁沟通，优先满足其当前需求而非严格按合同执行B.合同条款应模糊，以便灵活调整C.客户有权随时修改需求，团队必须接受D.合同应明确敏捷开发模式，减少变更成本答案：A解析：敏捷强调与客户的持续协作（如迭代评审、每日沟通），通过早期和持续交付获取反馈，而非依赖固定合同约束（《敏捷宣言》原则第3条）。26.某团队采用Scrum，Sprint周期为2周。在Sprint第5天，团队发现剩余故事点所需工时超过剩余可用工时。此时应：A.加班完成，确保Sprint目标达成B.与产品负责人沟通，调整Sprint待办列表（如移除低优先级故事）C.延长Sprint周期至3周D.降低已完成故事的验收标准答案：B解析：当Sprint中发现无法完成承诺时，开发团队应与产品负责人协商调整Sprint待办列表（如移除或降级某些故事），确保交付有价值的增量（《Scrum指南》2020版）。27.XP中的“持续集成”实践要求：A.每天至少集成一次代码，并运行自动化测试B.每个迭代结束后集成所有代码C.仅在功能完成后进行集成测试D.由专门的集成团队负责代码合并答案：A解析：持续集成强调频繁（每日多次）集成代码，通过自动化测试快速发现集成问题，避免后期大规模返工（《持续交付》第2章）。28.敏捷教练在辅导团队时，发现成员习惯等待产品负责人明确所有需求细节后再开始开发。此时应引导团队：A.要求产品负责人提供更详细的需求文档B.采用“逐步细化”（Just-in-Time）方式，在开发过程中与产品负责人确认细节C.建立需求冻结机制，迭代开始后不再修改需求D.增加需求评审会次数，确保需求明确答案：B解析：敏捷提倡“按需细化”（Just-in-Time），避免前期过度设计。开发过程中通过即时沟通（如站会后与产品负责人确认）获取必要细节，平衡效率与准确性（《敏捷需求管理》第4章）。29.以下哪项符合“敏捷团队规模”的最佳实践？A.5-9人，跨职能（包含开发、测试、设计等角色）B.10-15人，按职能划分（开发组、测试组、设计组）C.3人以下，适合小型项目D.20人以上，适合大规模复杂项目答案：A解析：Scrum推荐团队规模为5-9人（《Scrum指南》），跨职能团队（包含完成增量所需的所有技能）可减少依赖，提升自组织能力。30.迭代评审会的参与者不包括：A.产品负责人B.开发团队C.客户或利益相关者D.ScrumMaster（仅观察，不参与讨论）答案：D解析：ScrumMaster在评审会中作为促进者，需参与讨论以确保会议有效，而非仅观察（《Scrum敏捷实践指南》第6章）。二、多项选择题（每题3分，共30分。每题至少2个正确选项，错选、漏选均不得分）31.敏捷价值观包括以下哪些内容？A.个体与交互高于流程与工具B.可工作的软件高于详尽的文档C.客户协作高于合同谈判D.响应变化高于遵循计划答案：ABCD解析：敏捷宣言的四大价值观（《敏捷宣言》原文）。32.Scrum的三个角色是：A.产品负责人（ProductOwner）B.ScrumMasterC.开发团队（DevelopmentTeam）D.项目经理（ProjectManager）答案：ABC解析：Scrum的核心角色为产品负责人、ScrumMaster和开发团队（《Scrum指南》2020版）。33.以下哪些是XP（极限编程）的实践？A.测试驱动开发（TDD）B.持续集成（CI）C.结对编程（PairProgramming）D.每日站会（DailyScrum）答案：ABC解析：每日站会是Scrum的实践，XP的核心实践包括TDD、CI、结对编程、集体代码所有权等（《解析极限编程》）。34.看板方法的三大支柱是：A.可视化工作流程B.限制在制品（WIP）C.度量与优化流程D.固定迭代周期答案：ABC解析：看板的三大支柱是可视化、WIP限制、流程度量与优化（《看板方法》）。35.敏捷估算常用的方法有：A.计划扑克（PlanningPoker）B.故事点（StoryPoints）C.类比估算（AnalogousEstimating）D.三点估算（Three-PointEstimating）答案：ABCD解析：敏捷估算中，计划扑克是工具，故事点是单位，类比估算（参考历史故事）和三点估算（最乐观、最可能、最悲观）是常用方法（《敏捷估算与计划》）。36.迭代回顾会中，团队可使用的改进工具包括：A.5Why分析法（连续问“为什么”找出根本原因）B.鱼骨刺图（因果图，分析问题成因）C.行动计划表（明确谁、何时、做什么）D.燃尽图（展示迭代进度）答案：ABC解析：燃尽图用于展示迭代进度，回顾会更关注流程改进，5Why、鱼骨刺图、行动计划表是常用工具（《敏捷回顾会实践》）。37.产品待办列表的排序依据包括：A.商业价值（如ROI）B.风险（如技术实现难度）C.依赖关系（如需先完成A才能开发B）D.客户紧急程度答案：ABCD解析：产品负责人需综合商业价值、风险、依赖、紧急程度等因素排序待办列表（《敏捷产品管理》）。38.敏捷团队的“完成的定义”（DoD）应包含以下哪些内容？A.代码通过单元测试B.完成用户文档更新C.通过产品负责人验收D.部署到生产环境答案：ABC解析：DoD是团队对“完成”的共同标准，通常包括测试通过、文档更新、验收等，部署到生产环境可能因发布策略不同而变化（《Scrum精髓》）。39.以下哪些做法符合“敏捷团队协作”的原则？A.成员主动帮助其他角色完成任务（如开发人员协助测试）B.定期组织团队建设活动，增强信任C.遇到问题时，立即召开全员会议讨论解决方案D.通过共享文档（如Confluence）实时同步信息答案：ABD解析：敏捷提倡跨职能协作（A）、建立信任（B）、透明沟通（D），而频繁全员会议可能影响效率（C不符合）（《敏捷团队协作》）