2025年(軟件工程)敏捷開發(fā)試題及答案一、單項選擇題（每題2分，共20分）1.在Scrum框架中，下列哪項活動的主要目標(biāo)是“檢視并調(diào)整產(chǎn)品待辦列表”？A.Sprint計劃會議B.Sprint評審會議C.Sprint回顧會議D.每日站會答案：B解析：Sprint評審會議的核心是向利益相關(guān)者展示增量，收集反饋，并據(jù)此調(diào)整產(chǎn)品待辦列表。2.極限編程（XP）提倡“持續(xù)集成”，其首要目的是：A.降低單元測試覆蓋率要求B.盡早暴露集成缺陷C.減少版本發(fā)布頻率D.避免客戶現(xiàn)場參與答案：B解析：持續(xù)集成通過頻繁地將代碼合并到主干，使集成缺陷在引入當(dāng)天即可被發(fā)現(xiàn)。3.用戶故事“作為一名網(wǎng)約車司機(jī)，我希望在高峰期收到動態(tài)加價提醒，以便提高收入”中，屬于“驗收準(zhǔn)則”最佳示例的是：A.提醒必須包含彩色圖標(biāo)B.提醒在訂單派發(fā)前3秒內(nèi)彈出C.提醒文案不超過20個漢字D.當(dāng)加價倍數(shù)≥1.5倍時，系統(tǒng)推送彈窗且司機(jī)可一鍵確認(rèn)答案：D解析：驗收準(zhǔn)則需可衡量、可驗證，D同時給出了觸發(fā)條件與預(yù)期結(jié)果。4.在DevOps部署流水線中，下列哪項通常發(fā)生在“構(gòu)建”階段之后、“發(fā)布”階段之前？A.靜態(tài)代碼掃描B.容量預(yù)估C.灰度發(fā)布D.用戶培訓(xùn)答案：A解析：靜態(tài)代碼掃描屬于質(zhì)量門禁，在構(gòu)建后制品進(jìn)入倉庫前完成。5.敏捷團(tuán)隊使用“燃起圖”（Burn-upChart）的主要意義是：A.顯示已完成與剩余工作量，直觀反映范圍變更B.對比個人績效C.預(yù)測團(tuán)隊情緒D.計算迭代速率答案：A解析：燃起圖通過兩條曲線分別展示完成量與總量，可一眼看出范圍增加或削減。6.根據(jù)2021年修訂的《敏捷實踐指南》，對“WIP限制”描述正確的是：A.僅適用于看板方法B.限制在制品數(shù)量旨在降低上下文切換C.限制值一旦設(shè)定永不改變D.限制越寬松越能提升流速答案：B解析：限制在制品可減少多任務(wù)并行，提高聚焦與交付速度。7.在LeSS（Large-ScaleScrum）框架中，以下角色為“單產(chǎn)品負(fù)責(zé)人”模式的是：A.需求領(lǐng)域負(fù)責(zé)人B.區(qū)域產(chǎn)品負(fù)責(zé)人C.總產(chǎn)品負(fù)責(zé)人D.技術(shù)負(fù)責(zé)人答案：C解析：LeSSHuge才引入?yún)^(qū)域產(chǎn)品負(fù)責(zé)人，基礎(chǔ)LeSS僅一名總產(chǎn)品負(fù)責(zé)人。8.敏捷合同若采用“中途可終止”條款，對甲方的最大價值是：A.降低乙方利潤B.提前獲得部分價值并減少沉沒成本C.增加變更請求費用D.強(qiáng)制使用特定技術(shù)棧答案：B解析：該條款讓甲方在發(fā)現(xiàn)價值足夠或方向錯誤時可隨時停止，降低風(fēng)險。9.下列哪項最能體現(xiàn)“個體與互動高于流程與工具”？A.每日站會超時15分鐘，團(tuán)隊自發(fā)決定改為走動式B.強(qiáng)制使用統(tǒng)一IDEC.要求所有溝通必須錄屏留痕D.用JIRA字段限制故事描述字?jǐn)?shù)答案：A解析：團(tuán)隊基于實際互動效果調(diào)整流程，體現(xiàn)敏捷價值觀。10.在行為驅(qū)動開發(fā)（BDD）中，“Given-When-Then”最適用于：A.編寫性能測試腳本B.描述可執(zhí)行場景C.估算故事點D.制定預(yù)算答案：B解析：BDD用自然語言+可執(zhí)行代碼描述場景，使業(yè)務(wù)、開發(fā)、測試對齊。二、多項選擇題（每題3分，共15分，多選少選均不得分）11.以下哪些實踐有助于縮短“從代碼提交到生產(chǎn)”的LeadTime？A.特性開關(guān)B.自動化回歸測試C.主干開發(fā)D.手動部署審批E.藍(lán)綠發(fā)布答案：ABCE解析：特性開關(guān)與主干開發(fā)減少分支合并時間；自動化測試與藍(lán)綠發(fā)布降低發(fā)布風(fēng)險；手動審批反而延長。12.在Scrum中，導(dǎo)致Sprint目標(biāo)無法達(dá)成的常見原因有：A.產(chǎn)品負(fù)責(zé)人在Sprint中期添加高優(yōu)先級需求B.每日站會淪為狀態(tài)匯報C.團(tuán)隊在迭代最后兩天才集成代碼D.Sprint待辦列表在計劃會后即凍結(jié)E.回顧會議未產(chǎn)出行動項答案：ABCE解析：D為正確做法，列表在計劃會后不應(yīng)隨意變更。13.以下指標(biāo)可直接反映敏捷團(tuán)隊“交付價值”的有：A.故事點完成率B.客戶凈推薦值（NPS）C.生產(chǎn)缺陷逃逸率D.人均加班時長E.業(yè)務(wù)收益達(dá)成率答案：BE解析：NPS與業(yè)務(wù)收益直接關(guān)聯(lián)價值；故事點與缺陷為過程或質(zhì)量指標(biāo)。14.關(guān)于“用戶故事地圖”（UserStoryMapping），正確說法有：A.橫向為時間順序，縱向為優(yōu)先級B.可用于識別MVPC.由產(chǎn)品負(fù)責(zé)人獨立完成D.有助于防止“功能煙囪”E.輸出只能是物理便簽答案：ABD解析：故事地圖強(qiáng)調(diào)協(xié)作，非單人活動；輸出可為電子工具。15.在持續(xù)交付中，以下屬于“部署腳本”應(yīng)具備的特征有：A.冪等性B.可回滾C.硬編碼密鑰D.版本化E.手動交互式輸入答案：ABD解析：腳本需冪等、可回滾、受版本控制；密鑰應(yīng)加密管理，避免交互。三、判斷題（每題1分，共10分，正確打“√”，錯誤打“×”）16.敏捷團(tuán)隊禁止在Sprint進(jìn)行中調(diào)整質(zhì)量定義。答案：×解析：DoD可在回顧會后共同調(diào)整，但不應(yīng)臨時降低以掩蓋進(jìn)度。17.結(jié)對編程一定比單人編程消耗雙倍人力，因而成本更高。答案：×解析：研究表明缺陷減少、知識共享帶來的后期節(jié)省可抵消成本。18.看板方法強(qiáng)調(diào)“流動效率”優(yōu)于“資源效率”。答案：√解析：流動效率關(guān)注價值端到端快速流動，資源效率易局部優(yōu)化。19.在LeSS框架中，所有團(tuán)隊共享同一個Sprintbacklog。答案：√解析：LeSS強(qiáng)調(diào)一個產(chǎn)品、一個待辦、一個增量。20.敏捷估算中，使用“理想人天”可避免日歷假期干擾。答案：√解析：理想人天排除會議、假期，便于對比規(guī)模。21.產(chǎn)品負(fù)責(zé)人必須參加每日站會并匯報進(jìn)度。答案：×解析：PO非強(qiáng)制，但可旁聽；站會由開發(fā)團(tuán)隊主導(dǎo)。22.“混沌工程”屬于敏捷測試的一種實踐。答案：√解析：通過主動注入故障驗證系統(tǒng)彈性，是持續(xù)測試的延伸。23.敏捷倡導(dǎo)“可工作的軟件”意味著文檔不再必要。答案：×解析：左值強(qiáng)調(diào)“高于”而非“取代”，輕量但高價值文檔仍需要。24.在Spike試驗中，必須產(chǎn)出生產(chǎn)就緒代碼。答案：×解析：Spike目標(biāo)是獲取知識，可丟棄代碼。25.采用“發(fā)布火車”（PIPlanning）時，所有團(tuán)隊必須按同一節(jié)奏發(fā)布。答案：×解析：團(tuán)隊可獨立發(fā)布，但需對齊系統(tǒng)增量。四、簡答題（每題10分，共30分）26.某金融支付團(tuán)隊采用兩周Sprint，但每輪結(jié)束均出現(xiàn)“集成地獄”：合并沖突多、回歸缺陷激增。請從“技術(shù)實踐”與“流程”兩方面給出至少五條改進(jìn)措施，并說明預(yù)期收益。答案：技術(shù)實踐：1)推行主干開發(fā)+特性開關(guān)：開發(fā)人員每日向主干提交小步代碼，沖突概率指數(shù)級下降；開關(guān)允許功能按需灰度，減少長分支。2)引入契約測試：服務(wù)間用CDC（Consumer-DrivenContract）測試，提前發(fā)現(xiàn)接口破壞，回歸缺陷預(yù)計降低40%。3)自動化構(gòu)建門禁：提交即觸發(fā)靜態(tài)掃描、單元測試、安全檢測，失敗即拒絕合并，確保主干始終可部署。流程：4)每日舉行“集成雷達(dá)”站會：16:00固定時段，全員聚焦主干健康，發(fā)現(xiàn)紅線立即修復(fù)，平均修復(fù)時間從48h降至4h。5)Sprint中設(shè)置“集成日”：第8天凍結(jié)新功能，僅允許集成、修復(fù)，提前暴露風(fēng)險；經(jīng)驗表明可將最后兩天缺陷峰值削平70%。預(yù)期收益：合并沖突減少80%，回歸缺陷減少50%，Sprint交付率從60%提升至95%，發(fā)布頻率由月發(fā)布提升到周發(fā)布。27.請用“影響地圖”（ImpactMapping）為“提升校園外賣平臺夜間訂單量”目標(biāo)拆解至少兩層，并寫出對應(yīng)用戶故事及驗收準(zhǔn)則。答案：目標(biāo)：半年內(nèi)將夜間（22:00-06:00）訂單占比從8%提升到15%。一級Actor：在校大學(xué)生、宿舍管理員、平臺騎手。二級Impact（大學(xué)生）：縮短等待時間、降低配送費、獲得夜宵優(yōu)惠。三級Deliverable：1)夜間智能調(diào)度算法2.02)夜間券包活動3)騎手夜班補(bǔ)貼系統(tǒng)用戶故事：“作為經(jīng)常通宵復(fù)習(xí)的大學(xué)生，我希望在下單后30分鐘內(nèi)收到熱騰騰夜宵，以便繼續(xù)學(xué)習(xí)。”驗收準(zhǔn)則：a)系統(tǒng)承諾ETA≤30分鐘，超時自動賠付5元券；b)凌晨0-4點間，騎手接單到取餐平均時長≤10分鐘；c)用戶可實時查看騎手位置，誤差≤50米；d)若因平臺原因取消，用戶立得8折券，24小時內(nèi)到賬。28.某B2BSaaS公司計劃從“項目制”轉(zhuǎn)型為“產(chǎn)品制敏捷”，但銷售部門擔(dān)心“需求響應(yīng)變慢”。請給出轉(zhuǎn)型路線圖，并說明如何衡量“響應(yīng)速度”與“價值產(chǎn)出”雙贏。答案：路線圖：階段1（0-3月）：建立統(tǒng)一產(chǎn)品愿景，成立跨部門“產(chǎn)品委員會”，銷售、客戶成功、技術(shù)共創(chuàng)新backlog；采用雙軌開發(fā)，維護(hù)老項目同時孵化新平臺。階段2（3-6月）：引入季度OKR，將銷售線索轉(zhuǎn)化為假設(shè)，用MVF（MinimumViableFeature）驗證；設(shè)置“客戶代表”嵌入Scrum團(tuán)隊，每兩周演示。階段3（6-12月）：逐步停用項目分支，所有新功能走產(chǎn)品主干；建立“客戶洞察池”，用NPS、續(xù)費率、ARPU衡量價值；銷售獎金與年度經(jīng)常性收入（ARR）掛鉤，而非一次性簽單。衡量雙贏：響應(yīng)速度：從需求提出到上線平均天數(shù)（LeadTime）、關(guān)鍵需求占比（SLA30天內(nèi)上線≥80%）。價值產(chǎn)出：季度ARR增長、客戶留存率、功能采用率≥60%。當(dāng)兩項指標(biāo)同時改善>15%，即視為轉(zhuǎn)型成功。五、案例分析題（25分）背景：“云健康”是一家在線問診平臺，2024年底注冊用戶500萬，日活30萬。技術(shù)團(tuán)隊80人，分為8個Scrum小隊。近三輪Sprint出現(xiàn)以下癥狀：1)線上事故頻發(fā)，P1級故障平均每月3起；2)新功能上線后用戶留存不升反降；3)各小隊velocity持續(xù)走高，但CTO發(fā)現(xiàn)“代碼冗余率”同步攀升；4)測試人員抱怨“回歸測試用例爆炸”，自動化覆蓋率停滯在45%。CTO決定2025年Q1啟動“敏捷健康度”整改，并任命你為首席敏捷教練。請回答：29.請使用“因果回路圖”思路，畫出導(dǎo)致“velocity升高但質(zhì)量下降”的關(guān)鍵回路，并指出杠桿解。（文字描述即可，8分）答案：回路描述：R1（正反饋）：管理層以velocity為績效→團(tuán)隊追求更多故事點→壓縮測試與重構(gòu)時間→缺陷遺留→線上事故→緊急補(bǔ)丁→進(jìn)一步壓縮新功能時間→velocity虛高。B1（負(fù)反饋）：缺陷增加→測試用例增加→手工回歸時間變長→交付周期拉長→velocity下降，但被R1壓制。杠桿解：1)將績效指標(biāo)從“故事點”改為“事故逃逸率+客戶留存”；2)引入“質(zhì)量門禁”：新增代碼需≥80%單元測試覆蓋，并通過SonarA級；3)建立“紅隊”機(jī)制：每周隨機(jī)抽1小時對任一小隊做混沌注入，發(fā)現(xiàn)P1獎勵而非懲罰，強(qiáng)化“缺陷預(yù)防”文化。30.設(shè)計一套“質(zhì)量風(fēng)險畫布”（QualityRiskCanvas），要求包含至少6個維度，并給出每個維度的探針問題。（9分）答案：1)業(yè)務(wù)價值：該功能失敗是否導(dǎo)致收入下降>5%？2)用戶影響：失敗是否影響>10%日活或關(guān)鍵人群（老年人）？3)技術(shù)復(fù)雜度：是否涉及分布式事務(wù)或第三方接口？4)代碼新鮮度：近30天新增或修改行數(shù)占比>30%？5)歷史缺陷密度：該模塊過去3月缺陷/千行>3？6)測試左移程度：是否有契約測試、API測試覆蓋？每個維度打分1-5，綜合≥20分的需求強(qiáng)制走“強(qiáng)化測試路徑”：結(jié)對編程+灰度+Canaries。31.請為測試團(tuán)隊制定“自動化測試攀登計劃”，使覆蓋率從45%提升到80%，時間跨度12周，并給出每周里程碑與度量指標(biāo)。（8分）答案：周1-2：基線建立?統(tǒng)計現(xiàn)有金字塔比例（單元:接口:UI=30:10:5）?引入測試數(shù)據(jù)管理工具，搭建Pipeline新Stage“auto-test”度量：pipeline成功率≥95%，平均運行時間≤15分鐘。周3-4：單元層沖刺?采用TDD，對新增核心業(yè)務(wù)寫測試先寫代碼?每日合并覆蓋率報告，紅代碼禁止合并度量：單元覆蓋率從30%提升到50%。周5-8：接口層攀登?使用Pact