2025年apm考试试题及答案

2025年apm考试试题及答案一、单项选择题（每题2分，共20分）1.某敏捷团队在迭代规划会上发现，当前用户故事的验收标准仅描述了“系统应显示用户信息”，未明确“用户信息包含姓名、手机号、地址”。根据敏捷最佳实践，最合理的改进措施是：A.由产品负责人在迭代中补充验收标准B.在迭代回顾会上讨论验收标准的完善方法C.立即邀请相关利益相关者补充详细验收标准D.将该用户故事拆分为“显示用户姓名”“显示用户手机号”等子故事答案：C解析：用户故事的验收标准需在迭代规划前明确，以确保开发团队对交付物有共同理解。若发现标准模糊，应立即与产品负责人（PO）及相关利益者确认，避免开发偏差。2.以下哪项不符合Scrum框架中“开发团队”的职责？A.自组织完成迭代目标B.每日站会中同步进展与障碍C.参与用户故事的估算与拆分D.直接与外部客户协商需求变更答案：D解析：Scrum中，产品负责人（PO）是唯一负责管理产品待办列表（ProductBacklog）的角色，开发团队需通过PO与外部客户沟通需求变更，避免需求混乱。3.某团队采用看板方法管理研发流程，当前在制品（WIP）限制为5。若系统测试阶段有3个任务，开发阶段有2个任务，以下哪种情况会触发流程改进？A.开发阶段新增1个紧急任务B.系统测试阶段完成1个任务，开发阶段完成1个任务C.产品负责人要求将WIP限制调整为6D.开发阶段有1个任务因技术阻塞停滞3天答案：A解析：看板WIP限制旨在控制流程负载，防止多任务处理降低效率。当前开发阶段已有2个任务（达到WIP上限），新增任务会突破限制，需先处理现有任务或调整WIP后再接收新任务。4.敏捷团队在迭代评审会上展示成果时，客户提出“希望增加数据导出功能”。团队最恰当的回应是：A.立即将该需求加入当前迭代待办列表B.记录需求并评估对后续迭代的影响，由PO纳入产品待办列表C.告知客户当前迭代已锁定范围，无法调整D.与客户协商减少现有功能以腾出资源开发新需求答案：B解析：迭代评审会是收集反馈的时机，但需求变更需通过PO评估优先级和可行性，纳入产品待办列表，而非直接修改当前迭代目标。5.用户故事“作为教师，我需要查看学生作业提交状态，以便及时提醒未提交的学生”中，“以便及时提醒未提交的学生”对应用户故事的哪个部分？A.角色（Role）B.目标（Goal）C.动机（Motivation）D.功能（Function）答案：C解析：用户故事的标准结构为“作为<角色>，我需要<功能>，以便<动机>”，其中“以便”后是用户完成功能的深层目的，即动机。6.关于敏捷估算，以下说法正确的是：A.故事点（StoryPoint）是绝对工作量单位，1个故事点=8小时B.规划扑克（PlanningPoker）通过匿名估算减少权威影响C.估算应精确到小时级，以提高计划准确性D.新团队应使用历史数据进行估算，避免偏差答案：B解析：规划扑克通过团队成员匿名出牌（估算值）再讨论的方式，避免团队中权威意见主导估算结果，促进更客观的评估。故事点是相对估算单位，不与小时直接挂钩；敏捷提倡相对估算而非精确到小时；新团队缺乏历史数据，应通过协作估算逐步建立基准。7.某团队在迭代中发现，由于前端与后端开发进度不匹配，多次出现集成延迟。最有效的改进措施是：A.增加每日站会时长，详细讨论各模块进度B.使用持续集成（CI）工具，每日自动集成并测试C.要求后端团队优先完成接口开发D.在迭代规划时拆分用户故事为前后端独立任务答案：B解析：持续集成通过自动化工具频繁集成代码，尽早发现集成问题，减少后期返工。拆分任务或调整优先级可能缓解问题，但CI是解决集成延迟的根本方法。8.Scrum中“冲刺回顾会”的主要目的是：A.展示迭代成果并收集反馈B.评估迭代目标完成情况C.改进团队流程与协作方式D.规划下一个迭代的待办列表答案：C解析：冲刺回顾会（SprintRetrospective）是团队反思当前迭代流程、协作中的问题，并制定改进计划的会议，核心是持续改进。9.以下哪项最符合敏捷“响应变化”的价值观？A.严格遵循项目计划，避免需求变更B.在项目后期接受需求变更，成本更低C.通过迭代开发快速适应需求变化D.要求客户在项目启动前冻结需求答案：C解析：敏捷宣言强调“响应变化高于遵循计划”，迭代开发通过短周期交付，使团队能快速响应客户需求变更，降低变更成本。10.看板方法与Scrum的主要区别在于：A.看板没有固定迭代周期，Scrum以固定冲刺周期驱动B.看板强调团队自组织，Scrum依赖产品负责人C.看板关注流程可视化，Scrum关注角色与事件D.看板适用于产品开发，Scrum适用于维护型项目答案：A解析：看板是基于流程的方法，通过限制在制品实现持续流动，无固定时间盒；Scrum以固定长度的冲刺（Sprint）为时间盒，驱动迭代开发。二、简答题（每题8分，共40分）1.简述敏捷团队“自组织”（Self-Organizing）的含义及其对项目成功的意义。答案：自组织团队指团队成员自主决定如何完成工作，而非由外部指令驱动。其核心包括：①团队共同承担目标责任，自主拆分任务、分配工作；②成员根据技能互补协作，灵活调整角色；③主动识别问题并解决，而非依赖管理层干预。意义：自组织团队能提高成员参与感与责任感，激发创新；减少层级沟通成本，快速响应变化；团队更了解自身能力，估算与计划更准确；长期来看，团队能力持续提升，适应复杂多变的项目环境。2.说明用户故事“INVEST”原则的具体内容，并举例说明违反其中一项原则的后果。答案：INVEST原则是用户故事的质量标准：Independent（独立）：故事应可独立开发，不依赖其他故事；Negotiable（可协商）：故事是沟通的起点，非合同式的详细需求；Valuable（有价值）：对用户或业务有明确价值；Estimable（可估算）：团队能合理估算工作量；Small（小）：大小适合在一个迭代内完成；Testable（可测试）：有明确验收标准，可验证是否完成。示例：若用户故事“实现系统所有数据的导出功能”违反“Small”原则，故事过大无法在迭代内完成，会导致迭代目标不清晰，进度无法跟踪，团队可能因任务堆积而无法交付可发布增量。3.对比Scrum中的“产品待办列表”（ProductBacklog）与“冲刺待办列表”（SprintBacklog）的作用与特点。答案：产品待办列表：是产品需求的动态列表，由产品负责人（PO）管理，包含所有待实现的功能、改进、缺陷等。特点：持续更新，按商业价值排序，需求可能粗略（需逐步细化），反映产品长期目标。冲刺待办列表：是当前冲刺中需完成的具体任务列表，由开发团队自组织创建。特点：仅覆盖当前冲刺，任务细化到开发级（如编码、测试），开发团队负责更新进度，目标是完成冲刺目标。两者关系：冲刺待办列表从产品待办列表中选取高优先级需求转化而来，是产品待办列表在当前冲刺的具体执行计划。4.敏捷团队在迭代中遇到“技术债务”（TechnicalDebt）积累的问题，可采取哪些措施缓解？答案：①预留时间处理：在迭代规划时，将技术债务修复作为高优先级任务，分配20%左右的团队资源；②重构（Refactoring）：在开发新功能时，对旧代码进行优化，保持代码质量；③自动化测试：增加单元测试、集成测试覆盖率，减少因代码修改导致的缺陷；④团队培训：提升成员技术能力（如设计模式、代码规范），从源头减少低质量代码；⑤可视化技术债务：通过看板或燃尽图跟踪债务规模，向PO说明其对交付速度的影响，争取资源支持。5.解释“持续交付”（ContinuousDelivery）与“持续部署”（ContinuousDeployment）的区别，并说明其对敏捷开发的价值。答案：持续交付（CD）：确保代码在任何时候都可快速、可靠地部署到生产环境，但部署决策由人工控制（如根据业务需求选择发布时间）。持续部署（ContinuousDeployment）：代码通过自动化测试后自动部署到生产环境，无需人工干预。对敏捷的价值：两者均通过自动化流水线（构建、测试、部署）缩短反馈周期，使团队能快速交付价值；持续交付降低发布风险，确保每次提交都可发布；持续部署进一步提升交付速度，适合需求变化极快的场景（如互联网产品）。三、案例分析题（每题20分，共40分）案例一：某科技公司为教育机构开发“智能作业管理系统”，团队采用Scrum框架，冲刺周期2周。当前是第5个冲刺，已完成用户登录、作业发布等核心功能。第5个冲刺目标为“实现作业批改与统计功能”，包含以下用户故事：US1：教师可查看学生作业提交状态（故事点8）US2：教师可对作业进行文字批注（故事点13）US3：系统自动统计班级作业完成率（故事点5）冲刺第3天，开发团队发现US2涉及复杂的富文本编辑器集成，原估算不足，实际工作量可能达到20个故事点；同时，PO收到客户紧急需求“增加作业截止时间提醒功能”（故事点3）。冲刺第7天，测试团队反馈US1存在数据库查询性能问题，需2天修复；US3的统计逻辑与客户实际需求有偏差，需重新设计（预计增加3个故事点）。问题：1.分析当前冲刺面临的主要问题及原因。2.提出至少3项针对性改进措施，并说明理由。答案：1.主要问题及原因：需求估算偏差：US2的故事点估算不准确，未充分考虑富文本编辑器集成的复杂性，可能因团队缺乏相关经验或需求细化不足。紧急需求插入：PO在冲刺中期接收新需求，违反Scrum“冲刺期间目标不变”的原则，可能干扰团队专注度。测试反馈延迟：性能问题与需求偏差在冲刺中期才暴露，说明迭代中的持续测试（如每日集成测试）未有效执行，或验收标准在规划时未明确。2.改进措施及理由：①重新评估冲刺目标：与PO协商，将US2标记为“部分完成”（如先实现基础批注功能），优先完成US1（修复性能）和US3（调整逻辑），确保交付可用增量。理由：Scrum强调“可发布的增量”，而非100%完成所有故事，保持交付价值比追求完美更重要。②处理紧急需求：由PO将“截止时间提醒”需求加入产品待办列表，评估其优先级，若高于当前冲刺目标，可终止当前冲刺（SprintTermination）并启动新冲刺。理由：紧急需求需通过PO纳入正规流程，避免干扰当前冲刺执行。③加强迭代中的测试与反馈：在每日站会后增加15分钟“快速测试同步”，开发人员提交代码后立即触发自动化测试（如性能测试），尽早发现问题；在冲刺规划时与客户确认US3的统计逻辑（如是否包含补交作业），明确验收标准。理由：持续测试可缩短反馈周期，减少后期返工；需求细化可提高估算准确性。案例二：某医疗科技公司团队采用看板方法开发“远程问诊系统”，当前流程为：需求澄清→开发→测试→预发布→生产部署，各阶段WIP限制分别为4、5、3、2、1。近期团队发现：①测试阶段经常堆积5-6个任务，开发阶段任务完成后需等待测试；②预发布阶段因环境配置问题，任务平均停留时间7天（目标3天）；③团队成员抱怨“总在救火，没时间优化代码”。问题：1.分析看板流程中的瓶颈及根本原因。2.提出至少4项改进措施，并说明如何通过看板方法落地。答案：1.瓶颈及根本原因：测试阶段是瓶颈：WIP限制为3，但实际堆积5-6个任务，说明测试能力不足（如人员技能、工具效率）或开发阶段输出速度超过测试处理能力。预发布阶段延迟：环境配置问题导致任务滞留，反映基础设施（如测试环境、部署脚本）缺乏自动化，依赖人工操作。技术债务积累：团队忙于处理任务，无时间优化代码，可能因WIP限制未考虑技术改进任务，或流程中未预留“维护”阶段。2.改进措施及看板落地：①调整WIP限制：将测试阶段WIP从3降低至2，迫使开发阶段减缓输出速度（如开发完成任务后需等待测试有空位），同时增加1名测试人员或引入自动化测试工具（如Selenium），提升测试效率。理由：看板通过限制WIP暴露瓶颈，调整限制可引导流程平衡。②优化预发布流程：在看板中增加“环境准备”子阶段（WIP限制1），专门