2025年(软件工程)敏捷开发试题及答案

2025年(软件工程)敏捷开发试题及答案一、单项选择题（每题2分，共20分）1.在Scrum框架中，下列哪项活动的主要目标是“检视并调整产品待办列表”？A.Sprint计划会议B.Sprint评审会议C.Sprint回顾会议D.每日站会答案：B解析：Sprint评审会议的核心是向利益相关者展示增量，收集反馈，并据此调整产品待办列表。2.极限编程（XP）提倡“持续集成”，其首要目的是：A.降低单元测试覆盖率要求B.尽早暴露集成缺陷C.减少版本发布频率D.避免客户现场参与答案：B解析：持续集成通过频繁地将代码合并到主干，使集成缺陷在引入当天即可被发现。3.用户故事“作为一名网约车司机，我希望在高峰期收到动态加价提醒，以便提高收入”中，属于“验收准则”最佳示例的是：A.提醒必须包含彩色图标B.提醒在订单派发前3秒内弹出C.提醒文案不超过20个汉字D.当加价倍数≥1.5倍时，系统推送弹窗且司机可一键确认答案：D解析：验收准则需可衡量、可验证，D同时给出了触发条件与预期结果。4.在DevOps部署流水线中，下列哪项通常发生在“构建”阶段之后、“发布”阶段之前？A.静态代码扫描B.容量预估C.灰度发布D.用户培训答案：A解析：静态代码扫描属于质量门禁，在构建后制品进入仓库前完成。5.敏捷团队使用“燃起图”（Burn-upChart）的主要意义是：A.显示已完成与剩余工作量，直观反映范围变更B.对比个人绩效C.预测团队情绪D.计算迭代速率答案：A解析：燃起图通过两条曲线分别展示完成量与总量，可一眼看出范围增加或削减。6.根据2021年修订的《敏捷实践指南》，对“WIP限制”描述正确的是：A.仅适用于看板方法B.限制在制品数量旨在降低上下文切换C.限制值一旦设定永不改变D.限制越宽松越能提升流速答案：B解析：限制在制品可减少多任务并行，提高聚焦与交付速度。7.在LeSS（Large-ScaleScrum）框架中，以下角色为“单产品负责人”模式的是：A.需求领域负责人B.区域产品负责人C.总产品负责人D.技术负责人答案：C解析：LeSSHuge才引入区域产品负责人，基础LeSS仅一名总产品负责人。8.敏捷合同若采用“中途可终止”条款，对甲方的最大价值是：A.降低乙方利润B.提前获得部分价值并减少沉没成本C.增加变更请求费用D.强制使用特定技术栈答案：B解析：该条款让甲方在发现价值足够或方向错误时可随时停止，降低风险。9.下列哪项最能体现“个体与互动高于流程与工具”？A.每日站会超时15分钟，团队自发决定改为走动式B.强制使用统一IDEC.要求所有沟通必须录屏留痕D.用JIRA字段限制故事描述字数答案：A解析：团队基于实际互动效果调整流程，体现敏捷价值观。10.在行为驱动开发（BDD）中，“Given-When-Then”最适用于：A.编写性能测试脚本B.描述可执行场景C.估算故事点D.制定预算答案：B解析：BDD用自然语言+可执行代码描述场景，使业务、开发、测试对齐。二、多项选择题（每题3分，共15分，多选少选均不得分）11.以下哪些实践有助于缩短“从代码提交到生产”的LeadTime？A.特性开关B.自动化回归测试C.主干开发D.手动部署审批E.蓝绿发布答案：ABCE解析：特性开关与主干开发减少分支合并时间；自动化测试与蓝绿发布降低发布风险；手动审批反而延长。12.在Scrum中，导致Sprint目标无法达成的常见原因有：A.产品负责人在Sprint中期添加高优先级需求B.每日站会沦为状态汇报C.团队在迭代最后两天才集成代码D.Sprint待办列表在计划会后即冻结E.回顾会议未产出行动项答案：ABCE解析：D为正确做法，列表在计划会后不应随意变更。13.以下指标可直接反映敏捷团队“交付价值”的有：A.故事点完成率B.客户净推荐值（NPS）C.生产缺陷逃逸率D.人均加班时长E.业务收益达成率答案：BE解析：NPS与业务收益直接关联价值；故事点与缺陷为过程或质量指标。14.关于“用户故事地图”（UserStoryMapping），正确说法有：A.横向为时间顺序，纵向为优先级B.可用于识别MVPC.由产品负责人独立完成D.有助于防止“功能烟囱”E.输出只能是物理便签答案：ABD解析：故事地图强调协作，非单人活动；输出可为电子工具。15.在持续交付中，以下属于“部署脚本”应具备的特征有：A.幂等性B.可回滚C.硬编码密钥D.版本化E.手动交互式输入答案：ABD解析：脚本需幂等、可回滚、受版本控制；密钥应加密管理，避免交互。三、判断题（每题1分，共10分，正确打“√”，错误打“×”）16.敏捷团队禁止在Sprint进行中调整质量定义。答案：×解析：DoD可在回顾会后共同调整，但不应临时降低以掩盖进度。17.结对编程一定比单人编程消耗双倍人力，因而成本更高。答案：×解析：研究表明缺陷减少、知识共享带来的后期节省可抵消成本。18.看板方法强调“流动效率”优于“资源效率”。答案：√解析：流动效率关注价值端到端快速流动，资源效率易局部优化。19.在LeSS框架中，所有团队共享同一个Sprintbacklog。答案：√解析：LeSS强调一个产品、一个待办、一个增量。20.敏捷估算中，使用“理想人天”可避免日历假期干扰。答案：√解析：理想人天排除会议、假期，便于对比规模。21.产品负责人必须参加每日站会并汇报进度。答案：×解析：PO非强制，但可旁听；站会由开发团队主导。22.“混沌工程”属于敏捷测试的一种实践。答案：√解析：通过主动注入故障验证系统弹性，是持续测试的延伸。23.敏捷倡导“可工作的软件”意味着文档不再必要。答案：×解析：左值强调“高于”而非“取代”，轻量但高价值文档仍需要。24.在Spike试验中，必须产出生产就绪代码。答案：×解析：Spike目标是获取知识，可丢弃代码。25.采用“发布火车”（PIPlanning）时，所有团队必须按同一节奏发布。答案：×解析：团队可独立发布，但需对齐系统增量。四、简答题（每题10分，共30分）26.某金融支付团队采用两周Sprint，但每轮结束均出现“集成地狱”：合并冲突多、回归缺陷激增。请从“技术实践”与“流程”两方面给出至少五条改进措施，并说明预期收益。答案：技术实践：1)推行主干开发+特性开关：开发人员每日向主干提交小步代码，冲突概率指数级下降；开关允许功能按需灰度，减少长分支。2)引入契约测试：服务间用CDC（Consumer-DrivenContract）测试，提前发现接口破坏，回归缺陷预计降低40%。3)自动化构建门禁：提交即触发静态扫描、单元测试、安全检测，失败即拒绝合并，确保主干始终可部署。流程：4)每日举行“集成雷达”站会：16:00固定时段，全员聚焦主干健康，发现红线立即修复，平均修复时间从48h降至4h。5)Sprint中设置“集成日”：第8天冻结新功能，仅允许集成、修复，提前暴露风险；经验表明可将最后两天缺陷峰值削平70%。预期收益：合并冲突减少80%，回归缺陷减少50%，Sprint交付率从60%提升至95%，发布频率由月发布提升到周发布。27.请用“影响地图”（ImpactMapping）为“提升校园外卖平台夜间订单量”目标拆解至少两层，并写出对应用户故事及验收准则。答案：目标：半年内将夜间（22:00-06:00）订单占比从8%提升到15%。一级Actor：在校大学生、宿舍管理员、平台骑手。二级Impact（大学生）：缩短等待时间、降低配送费、获得夜宵优惠。三级Deliverable：1)夜间智能调度算法2.02)夜间券包活动3)骑手夜班补贴系统用户故事：“作为经常通宵复习的大学生，我希望在下单后30分钟内收到热腾腾夜宵，以便继续学习。”验收准则：a)系统承诺ETA≤30分钟，超时自动赔付5元券；b)凌晨0-4点间，骑手接单到取餐平均时长≤10分钟；c)用户可实时查看骑手位置，误差≤50米；d)若因平台原因取消，用户立得8折券，24小时内到账。28.某B2BSaaS公司计划从“项目制”转型为“产品制敏捷”，但销售部门担心“需求响应变慢”。请给出转型路线图，并说明如何衡量“响应速度”与“价值产出”双赢。答案：路线图：阶段1（0-3月）：建立统一产品愿景，成立跨部门“产品委员会”，销售、客户成功、技术共创新backlog；采用双轨开发，维护老项目同时孵化新平台。阶段2（3-6月）：引入季度OKR，将销售线索转化为假设，用MVF（MinimumViableFeature）验证；设置“客户代表”嵌入Scrum团队，每两周演示。阶段3（6-12月）：逐步停用项目分支，所有新功能走产品主干；建立“客户洞察池”，用NPS、续费率、ARPU衡量价值；销售奖金与年度经常性收入（ARR）挂钩，而非一次性签单。衡量双赢：响应速度：从需求提出到上线平均天数（LeadTime）、关键需求占比（SLA30天内上线≥80%）。价值产出：季度ARR增长、客户留存率、功能采用率≥60%。当两项指标同时改善>15%，即视为转型成功。五、案例分析题（25分）背景：“云健康”是一家在线问诊平台，2024年底注册用户500万，日活30万。技术团队80人，分为8个Scrum小队。近三轮Sprint出现以下症状：1)线上事故频发，P1级故障平均每月3起；2)新功能上线后用户留存不升反降；3)各小队velocity持续走高，但CTO发现“代码冗余率”同步攀升；4)测试人员抱怨“回归测试用例爆炸”，自动化覆盖率停滞在45%。CTO决定2025年Q1启动“敏捷健康度”整改，并任命你为首席敏捷教练。请回答：29.请使用“因果回路图”思路，画出导致“velocity升高但质量下降”的关键回路，并指出杠杆解。（文字描述即可，8分）答案：回路描述：R1（正反馈）：管理层以velocity为绩效→团队追求更多故事点→压缩测试与重构时间→缺陷遗留→线上事故→紧急补丁→进一步压缩新功能时间→velocity虚高。B1（负反馈）：缺陷增加→测试用例增加→手工回归时间变长→交付周期拉长→velocity下降，但被R1压制。杠杆解：1)将绩效指标从“故事点”改为“事故逃逸率+客户留存”；2)引入“质量门禁”：新增代码需≥80%单元测试覆盖，并通过SonarA级；3)建立“红队”机制：每周随机抽1小时对任一小队做混沌注入，发现P1奖励而非惩罚，强化“缺陷预防”文化。30.设计一套“质量风险画布”（QualityRiskCanvas），要求包含至少6个维度，并给出每个维度的探针问题。（9分）答案：1)业务价值：该功能失败是否导致收入下降>5%？2)用户影响：失败是否影响>10%日活或关键人群（老年人）？3)技术复杂度：是否涉及分布式事务或第三方接口？4)代码新鲜度：近30天新增或修改行数占比>30%？5)历史缺陷密度：该模块过去3月缺陷/千行>3？6)测试左移程度：是否有契约测试、API测试覆盖？每个维度打分1-5，综合≥20分的需求强制走“强化测试路径”：结对编程+灰度+Canaries。31.请为测试团队制定“自动化测试攀登计划”，使覆盖率从45%提升到80%，时间跨度12周，并给出每周里程碑与度量指标。（8分）答案：周1-2：基线建立•统计现有金字塔比例（单元:接口:UI=30:10:5）•引入测试数据管理工具，搭建Pipeline新Stage“auto-test”度量：pipeline成功率≥95%，平均运行时间≤15分钟。周3-4：单元层冲刺•采用TDD，对新增核心业务写测试先写代码•每日合并覆盖率报告，红代码禁止合并度量：单元覆盖率从30%提升到50%。周5-8：接口层攀登•使用Pact