2025年apm考試試題及答案一、單項選擇題（每題2分，共20分）1.某敏捷團隊在迭代規(guī)劃會上發(fā)現(xiàn)，當前用戶故事的驗收標準僅描述了“系統(tǒng)應(yīng)顯示用戶信息”，未明確“用戶信息包含姓名、手機號、地址”。根據(jù)敏捷最佳實踐，最合理的改進措施是：A.由產(chǎn)品負責人在迭代中補充驗收標準B.在迭代回顧會上討論驗收標準的完善方法C.立即邀請相關(guān)利益相關(guān)者補充詳細驗收標準D.將該用戶故事拆分為“顯示用戶姓名”“顯示用戶手機號”等子故事答案：C解析：用戶故事的驗收標準需在迭代規(guī)劃前明確，以確保開發(fā)團隊對交付物有共同理解。若發(fā)現(xiàn)標準模糊，應(yīng)立即與產(chǎn)品負責人（PO）及相關(guān)利益者確認，避免開發(fā)偏差。2.以下哪項不符合Scrum框架中“開發(fā)團隊”的職責？A.自組織完成迭代目標B.每日站會中同步進展與障礙C.參與用戶故事的估算與拆分D.直接與外部客戶協(xié)商需求變更答案：D解析：Scrum中，產(chǎn)品負責人（PO）是唯一負責管理產(chǎn)品待辦列表（ProductBacklog）的角色，開發(fā)團隊需通過PO與外部客戶溝通需求變更，避免需求混亂。3.某團隊采用看板方法管理研發(fā)流程，當前在制品（WIP）限制為5。若系統(tǒng)測試階段有3個任務(wù)，開發(fā)階段有2個任務(wù)，以下哪種情況會觸發(fā)流程改進？A.開發(fā)階段新增1個緊急任務(wù)B.系統(tǒng)測試階段完成1個任務(wù)，開發(fā)階段完成1個任務(wù)C.產(chǎn)品負責人要求將WIP限制調(diào)整為6D.開發(fā)階段有1個任務(wù)因技術(shù)阻塞停滯3天答案：A解析：看板WIP限制旨在控制流程負載，防止多任務(wù)處理降低效率。當前開發(fā)階段已有2個任務(wù)（達到WIP上限），新增任務(wù)會突破限制，需先處理現(xiàn)有任務(wù)或調(diào)整WIP后再接收新任務(wù)。4.敏捷團隊在迭代評審會上展示成果時，客戶提出“希望增加數(shù)據(jù)導(dǎo)出功能”。團隊最恰當?shù)幕貞?yīng)是：A.立即將該需求加入當前迭代待辦列表B.記錄需求并評估對后續(xù)迭代的影響，由PO納入產(chǎn)品待辦列表C.告知客戶當前迭代已鎖定范圍，無法調(diào)整D.與客戶協(xié)商減少現(xiàn)有功能以騰出資源開發(fā)新需求答案：B解析：迭代評審會是收集反饋的時機，但需求變更需通過PO評估優(yōu)先級和可行性，納入產(chǎn)品待辦列表，而非直接修改當前迭代目標。5.用戶故事“作為教師，我需要查看學生作業(yè)提交狀態(tài)，以便及時提醒未提交的學生”中，“以便及時提醒未提交的學生”對應(yīng)用戶故事的哪個部分？A.角色（Role）B.目標（Goal）C.動機（Motivation）D.功能（Function）答案：C解析：用戶故事的標準結(jié)構(gòu)為“作為<角色>，我需要<功能>，以便<動機>”，其中“以便”后是用戶完成功能的深層目的，即動機。6.關(guān)于敏捷估算，以下說法正確的是：A.故事點（StoryPoint）是絕對工作量單位，1個故事點=8小時B.規(guī)劃撲克（PlanningPoker）通過匿名估算減少權(quán)威影響C.估算應(yīng)精確到小時級，以提高計劃準確性D.新團隊應(yīng)使用歷史數(shù)據(jù)進行估算，避免偏差答案：B解析：規(guī)劃撲克通過團隊成員匿名出牌（估算值）再討論的方式，避免團隊中權(quán)威意見主導(dǎo)估算結(jié)果，促進更客觀的評估。故事點是相對估算單位，不與小時直接掛鉤；敏捷提倡相對估算而非精確到小時；新團隊缺乏歷史數(shù)據(jù)，應(yīng)通過協(xié)作估算逐步建立基準。7.某團隊在迭代中發(fā)現(xiàn)，由于前端與后端開發(fā)進度不匹配，多次出現(xiàn)集成延遲。最有效的改進措施是：A.增加每日站會時長，詳細討論各模塊進度B.使用持續(xù)集成（CI）工具，每日自動集成并測試C.要求后端團隊優(yōu)先完成接口開發(fā)D.在迭代規(guī)劃時拆分用戶故事為前后端獨立任務(wù)答案：B解析：持續(xù)集成通過自動化工具頻繁集成代碼，盡早發(fā)現(xiàn)集成問題，減少后期返工。拆分任務(wù)或調(diào)整優(yōu)先級可能緩解問題，但CI是解決集成延遲的根本方法。8.Scrum中“沖刺回顧會”的主要目的是：A.展示迭代成果并收集反饋B.評估迭代目標完成情況C.改進團隊流程與協(xié)作方式D.規(guī)劃下一個迭代的待辦列表答案：C解析：沖刺回顧會（SprintRetrospective）是團隊反思當前迭代流程、協(xié)作中的問題，并制定改進計劃的會議，核心是持續(xù)改進。9.以下哪項最符合敏捷“響應(yīng)變化”的價值觀？A.嚴格遵循項目計劃，避免需求變更B.在項目后期接受需求變更，成本更低C.通過迭代開發(fā)快速適應(yīng)需求變化D.要求客戶在項目啟動前凍結(jié)需求答案：C解析：敏捷宣言強調(diào)“響應(yīng)變化高于遵循計劃”，迭代開發(fā)通過短周期交付，使團隊能快速響應(yīng)客戶需求變更，降低變更成本。10.看板方法與Scrum的主要區(qū)別在于：A.看板沒有固定迭代周期，Scrum以固定沖刺周期驅(qū)動B.看板強調(diào)團隊自組織，Scrum依賴產(chǎn)品負責人C.看板關(guān)注流程可視化，Scrum關(guān)注角色與事件D.看板適用于產(chǎn)品開發(fā)，Scrum適用于維護型項目答案：A解析：看板是基于流程的方法，通過限制在制品實現(xiàn)持續(xù)流動，無固定時間盒；Scrum以固定長度的沖刺（Sprint）為時間盒，驅(qū)動迭代開發(fā)。二、簡答題（每題8分，共40分）1.簡述敏捷團隊“自組織”（Self-Organizing）的含義及其對項目成功的意義。答案：自組織團隊指團隊成員自主決定如何完成工作，而非由外部指令驅(qū)動。其核心包括：①團隊共同承擔目標責任，自主拆分任務(wù)、分配工作；②成員根據(jù)技能互補協(xié)作，靈活調(diào)整角色；③主動識別問題并解決，而非依賴管理層干預(yù)。意義：自組織團隊能提高成員參與感與責任感，激發(fā)創(chuàng)新；減少層級溝通成本，快速響應(yīng)變化；團隊更了解自身能力，估算與計劃更準確；長期來看，團隊能力持續(xù)提升，適應(yīng)復(fù)雜多變的項目環(huán)境。2.說明用戶故事“INVEST”原則的具體內(nèi)容，并舉例說明違反其中一項原則的后果。答案：INVEST原則是用戶故事的質(zhì)量標準：Independent（獨立）：故事應(yīng)可獨立開發(fā)，不依賴其他故事；Negotiable（可協(xié)商）：故事是溝通的起點，非合同式的詳細需求；Valuable（有價值）：對用戶或業(yè)務(wù)有明確價值；Estimable（可估算）：團隊能合理估算工作量；Small（?。捍笮∵m合在一個迭代內(nèi)完成；Testable（可測試）：有明確驗收標準，可驗證是否完成。示例：若用戶故事“實現(xiàn)系統(tǒng)所有數(shù)據(jù)的導(dǎo)出功能”違反“Small”原則，故事過大無法在迭代內(nèi)完成，會導(dǎo)致迭代目標不清晰，進度無法跟蹤，團隊可能因任務(wù)堆積而無法交付可發(fā)布增量。3.對比Scrum中的“產(chǎn)品待辦列表”（ProductBacklog）與“沖刺待辦列表”（SprintBacklog）的作用與特點。答案：產(chǎn)品待辦列表：是產(chǎn)品需求的動態(tài)列表，由產(chǎn)品負責人（PO）管理，包含所有待實現(xiàn)的功能、改進、缺陷等。特點：持續(xù)更新，按商業(yè)價值排序，需求可能粗略（需逐步細化），反映產(chǎn)品長期目標。沖刺待辦列表：是當前沖刺中需完成的具體任務(wù)列表，由開發(fā)團隊自組織創(chuàng)建。特點：僅覆蓋當前沖刺，任務(wù)細化到開發(fā)級（如編碼、測試），開發(fā)團隊負責更新進度，目標是完成沖刺目標。兩者關(guān)系：沖刺待辦列表從產(chǎn)品待辦列表中選取高優(yōu)先級需求轉(zhuǎn)化而來，是產(chǎn)品待辦列表在當前沖刺的具體執(zhí)行計劃。4.敏捷團隊在迭代中遇到“技術(shù)債務(wù)”（TechnicalDebt）積累的問題，可采取哪些措施緩解？答案：①預(yù)留時間處理：在迭代規(guī)劃時，將技術(shù)債務(wù)修復(fù)作為高優(yōu)先級任務(wù)，分配20%左右的團隊資源；②重構(gòu)（Refactoring）：在開發(fā)新功能時，對舊代碼進行優(yōu)化，保持代碼質(zhì)量；③自動化測試：增加單元測試、集成測試覆蓋率，減少因代碼修改導(dǎo)致的缺陷；④團隊培訓(xùn)：提升成員技術(shù)能力（如設(shè)計模式、代碼規(guī)范），從源頭減少低質(zhì)量代碼；⑤可視化技術(shù)債務(wù)：通過看板或燃盡圖跟蹤債務(wù)規(guī)模，向PO說明其對交付速度的影響，爭取資源支持。5.解釋“持續(xù)交付”（ContinuousDelivery）與“持續(xù)部署”（ContinuousDeployment）的區(qū)別，并說明其對敏捷開發(fā)的價值。答案：持續(xù)交付（CD）：確保代碼在任何時候都可快速、可靠地部署到生產(chǎn)環(huán)境，但部署決策由人工控制（如根據(jù)業(yè)務(wù)需求選擇發(fā)布時間）。持續(xù)部署（ContinuousDeployment）：代碼通過自動化測試后自動部署到生產(chǎn)環(huán)境，無需人工干預(yù)。對敏捷的價值：兩者均通過自動化流水線（構(gòu)建、測試、部署）縮短反饋周期，使團隊能快速交付價值；持續(xù)交付降低發(fā)布風險，確保每次提交都可發(fā)布；持續(xù)部署進一步提升交付速度，適合需求變化極快的場景（如互聯(lián)網(wǎng)產(chǎn)品）。三、案例分析題（每題20分，共40分）案例一：某科技公司為教育機構(gòu)開發(fā)“智能作業(yè)管理系統(tǒng)”，團隊采用Scrum框架，沖刺周期2周。當前是第5個沖刺，已完成用戶登錄、作業(yè)發(fā)布等核心功能。第5個沖刺目標為“實現(xiàn)作業(yè)批改與統(tǒng)計功能”，包含以下用戶故事：US1：教師可查看學生作業(yè)提交狀態(tài)（故事點8）US2：教師可對作業(yè)進行文字批注（故事點13）US3：系統(tǒng)自動統(tǒng)計班級作業(yè)完成率（故事點5）沖刺第3天，開發(fā)團隊發(fā)現(xiàn)US2涉及復(fù)雜的富文本編輯器集成，原估算不足，實際工作量可能達到20個故事點；同時，PO收到客戶緊急需求“增加作業(yè)截止時間提醒功能”（故事點3）。沖刺第7天，測試團隊反饋US1存在數(shù)據(jù)庫查詢性能問題，需2天修復(fù)；US3的統(tǒng)計邏輯與客戶實際需求有偏差，需重新設(shè)計（預(yù)計增加3個故事點）。問題：1.分析當前沖刺面臨的主要問題及原因。2.提出至少3項針對性改進措施，并說明理由。答案：1.主要問題及原因：需求估算偏差：US2的故事點估算不準確，未充分考慮富文本編輯器集成的復(fù)雜性，可能因團隊缺乏相關(guān)經(jīng)驗或需求細化不足。緊急需求插入：PO在沖刺中期接收新需求，違反Scrum“沖刺期間目標不變”的原則，可能干擾團隊專注度。測試反饋延遲：性能問題與需求偏差在沖刺中期才暴露，說明迭代中的持續(xù)測試（如每日集成測試）未有效執(zhí)行，或驗收標準在規(guī)劃時未明確。2.改進措施及理由：①重新評估沖刺目標：與PO協(xié)商，將US2標記為“部分完成”（如先實現(xiàn)基礎(chǔ)批注功能），優(yōu)先完成US1（修復(fù)性能）和US3（調(diào)整邏輯），確保交付可用增量。理由：Scrum強調(diào)“可發(fā)布的增量”，而非100%完成所有故事，保持交付價值比追求完美更重要。②處理緊急需求：由PO將“截止時間提醒”需求加入產(chǎn)品待辦列表，評估其優(yōu)先級，若高于當前沖刺目標，可終止當前沖刺（SprintTermination）并啟動新沖刺。理由：緊急需求需通過PO納入正規(guī)流程，避免干擾當前沖刺執(zhí)行。③加強迭代中的測試與反饋：在每日站會后增加15分鐘“快速測試同步”，開發(fā)人員提交代碼后立即觸發(fā)自動化測試（如性能測試），盡早發(fā)現(xiàn)問題；在沖刺規(guī)劃時與客戶確認US3的統(tǒng)計邏輯（如是否包含補交作業(yè)），明確驗收標準。理由：持續(xù)測試可縮短反饋周期，減少后期返工；需求細化可提高估算準確性。案例二：某醫(yī)療科技公司團隊采用看板方法開發(fā)“遠程問診系統(tǒng)”，當前流程為：需求澄清→開發(fā)→測試→預(yù)發(fā)布→生產(chǎn)部署，各階段WIP限制分別為4、5、3、2、1。近期團隊發(fā)現(xiàn)：①測試階段經(jīng)常堆積5-6個任務(wù)，開發(fā)階段任務(wù)完成后需等待測試；②預(yù)發(fā)布階段因環(huán)境配置問題，任務(wù)平均停留時間7天（目標3天）；③團隊成員抱怨“總在救火，沒時間優(yōu)化代碼”。問題：1.分析看板流程中的瓶頸及根本原因。2.提出至少4項改進措施，并說明如何通過看板方法落地。答案：1.瓶頸及根本原因：測試階段是瓶頸：WIP限制為3，但實際堆積5-6個任務(wù)，說明測試能力不足（如人員技能、工具效率）或開發(fā)階段輸出速度超過測試處理能力。預(yù)發(fā)布階段延遲：環(huán)境配置問題導(dǎo)致任務(wù)滯留，反映基礎(chǔ)設(shè)施（如測試環(huán)境、部署腳本）缺乏自動化，依賴人工操作。技術(shù)債務(wù)積累：團隊忙于處理任務(wù)，無時間優(yōu)化代碼，可能因WIP限制未考慮技術(shù)改進任務(wù)，或流程中未預(yù)留“維護”階段。2.改進措施及看板落地：①調(diào)整WIP限制：將測試階段WIP從3降低至2，迫使開發(fā)階段減緩輸出速度（如開發(fā)完成任務(wù)后需等待測試有空位），同時增加1名測試人員或引入自動化測試工具（如Selenium），提升測試效率。理由：看板通過限制WIP暴露瓶頸，調(diào)整限制可引導(dǎo)流程平衡。②優(yōu)化預(yù)發(fā)布流程：在看板中增加“環(huán)境準備”子階段（WIP限制1），專門