pmp敏捷考试试题及答案

pmp敏捷考试试题及答案第一部分：敏捷原则与思维模式一、单项选择题1.在一个敏捷项目中，开发团队正在处理一个复杂的软件模块。产品负责人（PO）希望团队能够更快地交付功能，并建议减少代码审查的时间以加快进度。作为敏捷管理专业人士，你应该如何回应？A.同意PO的建议，因为PO负责最大化产品价值B.拒绝PO的建议，并解释质量是不可协商的，减少代码审查会增加技术债务C.要求团队加班以在保持代码审查时间的同时加快速度D.将此问题记录在风险登记册中，并在下次迭代评审会议上讨论【答案】B【答案解析】根据敏捷原则，“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强”。虽然PO负责最大化产品价值，但这不能以牺牲质量为代价。减少代码审查虽然可能短期加快速度，但长期会增加缺陷率和维护成本（技术债务）。敏捷团队应当对质量负责。因此，拒绝该建议并解释原因是最合适的做法。A选项违背了质量原则；C选项加班不是敏捷推荐的可持续方式；D选项虽然记录风险，但当下的质量原则问题需要直接纠正。2.敏捷宣言强调“个体和互动高于流程和工具”。以下哪种情况最符合这一原则的应用？A.团队成员分散在不同地点，因此强制要求所有沟通必须通过Jira进行记录B.即使团队拥有最先进的自动化测试工具，每日站会依然侧重于面对面沟通障碍C.项目经理制定了详细的沟通管理计划，规定了所有邮件的抄送层级D.为了确保进度，团队专注于完善项目管理软件中的甘特图，而不是进行协作讨论【答案】B【答案解析】“个体和互动高于流程和工具”意味着虽然工具很重要，但人与人之间的直接沟通更为关键。B选项中，尽管有工具，团队依然重视面对面的沟通（或视频会议），这符合该原则。A、C、D选项都过分依赖工具或流程，而忽视了人与人之间直接、高效的互动，违背了敏捷宣言的价值观。3.一个新组建的敏捷团队正在经历“震荡”阶段。团队成员之间频繁发生冲突，对于技术架构的选择存在分歧。作为ScrumMaster，你应该采取什么行动？A.立即介入并替团队做出技术决策，以停止争吵B.忽略冲突，让团队自行解决，因为敏捷团队是自组织的C.引导团队进行讨论，帮助他们建立冲突解决机制和规范D.向高层汇报团队情况，请求更换不配合的成员【答案】C【答案解析】在团队组建的震荡阶段，冲突是正常的。ScrumMaster的角色是服务型领导，而不是独裁者。A选项剥夺了团队的自组织权利；B选项过于放任，ScrumMaster应当辅助团队；D选项是最后手段，且过早。C选项通过引导和辅导，帮助团队建立解决冲突的内部机制，既尊重了自组织，又履行了ScrumMaster的职责。4.在一次迭代回顾会议上，团队成员显得沉默寡言，不愿意分享真实的想法。为了改善这种情况，以下哪项措施最有效？A.取消回顾会议，因为团队认为没有问题需要讨论B.要求管理层参加回顾会议，迫使团队成员发言C.更改回顾会议的格式，例如使用“Start,Stop,Continue”卡片或匿名收集工具（如NPS）D.告诉团队如果不发言，将影响他们的绩效评估【答案】C【答案解析】回顾会议的核心是透明和持续改进。如果团队沉默，可能是由于心理安全感不足或会议形式枯燥。A选项放弃了改进机会；B选项管理层的存在会增加压力，降低开放性；D选项利用恐惧是违背敏捷价值观的。C选项通过改变形式和引入匿名机制，可以降低发言门槛，鼓励团队成员贡献想法，符合敏捷的实践。5.关于“最小可行产品（MVP）”的描述，以下哪项是正确的？A.MVP是包含所有预定功能的完整产品，只是质量未达标B.MVP是为了以最小effort获得最大学习价值而构建的产品版本，不一定是最终产品的完整功能集C.MVP一旦发布，就不能再进行任何修改D.MVP只用于内部测试，永远不应该发布给客户【答案】B【答案解析】MVP（MinimumViableProduct）的核心目的是验证假设和获取反馈，而非一次性交付所有功能。它包含了足以满足早期客户并以此提供反馈的最小功能集。A选项描述的是Alpha或Beta版可能的状态，但不是MVP的定义；C选项MVP是迭代的起点，后续会不断修改；D选项MVP通常需要发布给真实用户以获取市场反馈。第二部分：Scrum框架与角色职责二、单项选择题6.在Sprint规划会议上，团队估算故事点数。当讨论到一个用户故事时，团队意见分歧很大，估算值从3到13不等。此时应该怎么做？A.取平均值作为该故事的估算值B.由ScrumMaster决定最终的估算值C.选取最大值以确保安全D.进行讨论，如果短时间内无法达成一致，则暂时搁置，或者使用“扑克规划”技巧进一步讨论，甚至定义一个Spike（探索性任务）【答案】D【答案解析】当估算差异巨大时，说明团队对故事的理解或技术难度存在不同看法。简单的取平均（A）或由SM决定（B）都掩盖了问题。C选项会导致虚高估算。正确的做法是深入讨论，揭示差异背后的原因。如果故事信息不足，应该创建一个Spike任务来进行技术调研，以便在下个Sprint能更准确估算。D选项体现了敏捷对共识和信息的重视。7.产品负责人（PO）在Sprint进行到一半时，发现了一个高价值的新功能，并要求团队将其加入到当前的Sprint中。作为ScrumMaster，你应该如何处理？A.同意加入，因为PO负责管理待办事项列表的优先级B.拒绝加入，因为Sprint期间不允许增加新工作，除非Sprint被取消C.询问团队是否有剩余容量，如果有则加入D.让团队先完成当前工作，将该功能放入产品待办事项列表的顶部，等待下一个Sprint【答案】D【答案解析】根据Scrum指南，一旦Sprint开始，其目标就是固定的。为了保证团队的专注和保护Sprint目标，Sprint期间不能增加新的需求。PO有权调整优先级，但新需求必须放入ProductBacklog，而不是当前的SprintBacklog。A选项破坏了Sprint的稳定性；B选项虽然原则正确，但D选项更具体地指出了处理流程（放入Backlog顶部）；C选项破坏了Sprint的短周期承诺原则。8.关于Scrum中的“完成定义”，以下哪项描述是错误的？A.它是团队对于“增量”在何时可交付达成的一致共识B.它通常包含代码编写、单元测试、集成测试、代码审查等步骤C.不同的Sprint可以有不同的“完成定义”D.当“完成定义”未满足时，产品增量不能发布【答案】C【答案解析】DoD（DefinitionofDone）是Scrum团队的质量标准，用于提高透明度。通常情况下，DoD应当相对稳定，且适用于整个团队的交付物。如果每个Sprint的DoD都不同，会导致质量标准混乱，无法准确衡量进度。虽然随着团队的成熟，DoD可以演进，但在同一个项目阶段，它应当保持一致。A、B、D选项都是对DoD的正确描述。9.开发团队在Sprint评审会议上演示了新功能。一位关键干系人非常生气，因为他期望的一个功能没有包含在内。此时，谁应该负责与该干系人沟通并解释？A.ScrumMasterB.产品负责人C.开发团队D.项目经理【答案】B【答案解析】在Scrum中，产品负责人是最大化产品价值以及工作成果价值的主要负责人，也是管理干系人期望的关键角色。他们负责维护ProductBacklog的优先级，因此最清楚为什么某些功能还没做（优先级排序问题）。ScrumMaster负责流程，开发团队负责技术实现。因此，由PO出面解释优先级和发布计划是最合适的。10.ScrumMaster在每日站会中发现团队成员正在向管理层汇报昨天完成了什么以及今天计划做什么。这违反了站会的什么目的？A.同步计划B.识别障碍C.向管理层汇报进度D.促进自组织【答案】C【答案解析】每日站会是开发团队内部的会议，目的是制定接下来的24小时计划（同步），而不是向管理层汇报状态。如果变成了汇报会，团队会感到压力并隐藏真实问题，从而破坏了透明度和自组织。A和B是站会的正面目的，C是必须避免的行为，D是受影响的结果。第三部分：敏捷规划与估算三、单项选择题11.一个敏捷团队正在使用“故事点”进行估算。为什么故事点比“人天”更适合敏捷估算？A.故事点可以精确换算成具体的完成时间B.故事点关注的是工作的相对复杂度，而不是绝对耗时，这忽略了个体差异C.人天无法被管理层理解D.故事点必须遵循斐波那契数列，而人天不需要【答案】B【答案解析】敏捷估算强调相对估算而非绝对估算。人天（工时）容易受到估算人熟练度、环境干扰等因素影响，且容易让管理层将其视为承诺日期。故事点衡量的是复杂度、风险和努力程度的综合相对值，它剥离了“谁来做”和“具体多久”的绝对概念，更能体现工作量的本质。A选项错误，因为故事点不能直接换算成时间；C选项不是核心原因；D选项是常用的数列但不是本质原因。12.团队正在进行发布规划。如果团队的平均速度是30点每个Sprint，ProductBacklog中总共有300个点的待办事项，且团队希望在保持可持续pace的前提下工作。预计还需要多少个Sprint才能完成？A.10个B.9个C.11个D.无法确定，因为速度会波动【答案】D【答案解析】虽然数学计算是300/30=10，但在敏捷实践中，过去的表现不能完全预测未来。速度是波动的，需求也会变更（涌现），且团队构成可能变化。因此，给出一个精确的日期或Sprint数量是反敏捷的。正确的做法是给出一个概率范围或持续监控。在考试题目中，如果选项有“无法确定”或“依赖具体情况”，且涉及未来预测，通常选此类选项，因为敏捷拥抱变化。A、B、C都过于确定。13.在进行迭代规划时，团队需要确保在Sprint中放入高优先级的任务。如果团队在预估容量时，发现完成高优先级任务后，还有少量剩余时间，不足以放入下一个高优先级的大故事，应该怎么做？A.开始执行下一个高优先级的大故事，做多少算多少B.从ProductBacklog中找一个较小的低优先级故事填满时间C.提前结束Sprint，利用剩余时间进行技术探索或重构D.询问PO是否可以将大故事拆分，取其中一部分放入当前Sprint【答案】D【答案解析】敏捷团队应当专注于高价值交付。A选项违反了“不部分完成故事”的原则（INVEST原则中的S-Small，或者DoD）；B选项用低价值任务填充高价值时间是不合理的；C选项虽然可以做技术债务，但首选是最大化商业价值。D选项是最佳实践：与PO合作拆分大故事，提取一部分高价值的功能放入当前Sprint，既利用了容量，又交付了价值。14.以下哪项技术最适合用于帮助团队理解用户故事的范围并进行估算？A.甘特图B.关键路径法C.用户故事地图D.工作分解结构（WBS）【答案】C【答案解析】用户故事地图是一种可视化技术，它帮助团队理解用户旅程，排列Backlog的优先级，并确定发布范围。它非常适合敏捷环境下的规划和估算辅助。A、B、D都是传统瀑布模型的工具，虽然WBS在敏捷中也有变体，但UserStoryMapping是针对敏捷故事特性的最佳工具。15.关于“敏捷估算中的ConeofUncertainty（不确定性锥）”，以下说法正确的是？A.项目初期的不确定性最低，随着项目进行不确定性增加B.项目初期的不确定性最高，随着项目进行，不确定性逐渐降低C.敏捷通过前期详细设计消除不确定性锥D.不确定性锥只适用于瀑布模型，不适用于敏捷【答案】B【答案解析】不确定性锥是一个概念，指出在项目开始时，我们对项目的了解最少（不确定性最高）。随着迭代进行，我们不断获取反馈和知识，不确定性会逐渐降低。敏捷承认这一客观规律，因此不要求在初期进行精确的长期估算，而是通过迭代来降低不确定性。A选项相反；C选项敏捷不提倡前期大设计；D选项该概念适用于所有软件项目，敏捷利用它来指导规划策略。第四部分：敏捷执行、监控与质量四、单项选择题16.在一个使用看板的敏捷团队中，在制品限制被设置为“开发中”阶段为3。当前“开发中”已有3个任务，但有一个紧急的高优先级任务需要立即进入开发。团队应该怎么做？A.立即将紧急任务拉入“开发中”，使其变为4个B.停止拉动新任务，直到“开发中”的一个任务完成并移动到下一列C.扩充团队人数以增加容量D.将“开发中”的一个任务移回待办事项列，为紧急任务腾出空间【答案】B【答案解析】看板的核心机制是限制在制品（WIPLimit），目的是管理流动、减少多任务处理和提高质量。除非有明确的例外管理机制，否则不应随意打破WIP限制。A选项破坏了WIP限制，会导致多任务和效率下降；C选项不是即时解决方案；D选项随意中断正在进行的任务会造成浪费（上下文切换）。B选项遵守了WIP规则，通过加速完成现有任务（停止启动，开始完成）来腾出容量，这是看板的正确思维。17.敏捷团队在测试阶段发现了一个严重的Bug。为了修复它，团队可能无法完成当前Sprint的所有承诺。作为ScrumMaster，你应该建议？A.延长Sprint几天，直到Bug修复并完成所有任务B.在Sprint内与团队和PO协商，如果Bug威胁到Sprint目标，优先修复Bug，可能移除一个低优先级的Story来保证Sprint目标的达成C.隐藏Bug，在Sprint结束后作为技术债务处理D.立即取消Sprint【答案】B【答案解析】Sprint时长是固定的，不能延长（A错）。如果发现严重Bug影响目标，团队需要与PO沟通。B选项是敏捷的应对方式：在Sprint范围内协商，通过调整范围（移除价值最低的任务）来容纳必要的质量修复工作，从而保证Sprint目标的实现。C选项违背了质量原则；D选项取消Sprint通常是当Sprint目标变得毫无意义时才做的最后决定。18.团队正在使用TDD（测试驱动开发）。以下哪项描述准确反映了TDD的流程？A.先编写代码，然后编写测试用例验证代码B.先编写测试用例，编写代码使其通过，最后重构代码C.只编写测试用例，由QA人员编写代码D.先设计数据库，然后编写测试，最后编写代码【答案】B【答案解析】TDD的红-绿-重构循环是：先写一个失败的测试（红），写代码让测试通过（绿），然后重构代码。这能确保代码有测试覆盖且设计简洁。A选项是传统开发；C选项误解了TDD是开发人员的实践；D选项不是TDD的标准流程。19.敏捷团队如何通过“持续集成”（CI）来提升项目质量？A.每天由专人手动合并所有代码分支B.开发人员频繁地将代码集成到主干，每次集成都通过自动化构建和测试C.只有在Sprint结束时才进行代码集成D.将代码集成工作留给初级开发人员练习【答案】B【答案解析】持续集成的核心是频繁集成（通常每天多次）和自动化验证。B选项准确描述了CI。A选项手动合并效率低且易错；C选项集成频率太低，会导致“集成地狱”；D选项是对CI的误解。20.以下哪项指标最适合用于衡量敏捷团队的“流程效率”？A.代码行数B.缺陷数量C.周期时间或流动效率D.团队成员的工时利用率【答案】C【答案解析】在敏捷和精益中，关注点在于流动和交付价值。周期时间指一个任务从开始到完成的时间，流动效率指有效工作时间与总等待时间的比例。这些是衡量流程效率的关键指标。A代码行数是生产力指标，不代表价值或效率；B缺陷数量是质量指标；D工时利用率是资源利用率指标，过分关注它反而会损害流动（如为了保持忙碌而产生在制品堆积）。第五部分：风险、干系人与混合型管理五、多项选择题21.敏捷项目管理中，风险管理的特点包括哪些？（选两项）A.风险管理主要在项目启动阶段进行一次详细的规划B.风险管理是迭代的，通过频繁的回顾和待办事项梳理来识别新风险C.通过缩短反馈循环和尽早交付MVP来减少不确定性D.只有项目经理负责风险管理【答案】B,C【答案解析】敏捷风险管理是持续进行的（B），并且通过缩短迭代周期、增量交付来降低风险（C）。A是瀑布模式；D在敏捷中，全团队（包括PO和开发团队）都参与风险管理。22.在一个混合型项目中，部分硬件开发必须遵循瀑布模式，而软件开发采用敏捷模式。作为项目经理，在处理这种依赖关系时，应该注意什么？（选两项）A.强制硬件团队也转为敏捷，以保持一致B.在硬件和软件的接口处建立严格的变更控制流程C.利用同步点来协调瀑布阶段的里程碑和敏捷的迭代D.忽略硬件团队的进度，专注于软件的快速迭代【答案】B,C【答案解析】混合模式需要协调不同的生命周期。B选项对于外部依赖的硬件接口，需要控制变更以防止不兼容；C选项通过里程碑同步点来对齐进度。A选项不现实；D选项会导致系统集成失败。六、情景分析题23.情景：你是一个新任的ScrumMaster。团队由10人组成，其中包含2名远程成员。最近几次Sprint的燃尽图显示，团队几乎在Sprint中期就完成了所有工作，但在最后几天突然增加了大量任务，导致燃尽图在最后呈水平线，甚至有时未完成Sprint目标。团队成员反映在Sprint后期经常发现很多之前未预料到的细节工作。问题：这种现象最可能揭示了什么问题？作为ScrumMaster，你首先应该建议采取什么改进措施？A.团队速度太慢，建议增加团队成员B.团队在Sprint规划时估算过小，建议在规划时增加缓冲时间C.用户故事分解得不够细，隐藏了细节，建议在ProductBacklogRefinement中将故事拆分得更小（如符合INVEST原则）D.燃尽图工具不准确，建议改用燃起图【答案】C【答案解析】燃尽图“L”型或“J”型（前期快速下降，后期停滞）通常意味着任务分解不够细致。前期完成的都是大任务表面，后期才发现大量的子任务，导致工作突然膨胀。这是典型的“胡子”故事问题。A增加人数会降低沟通效率；B增加缓冲不是敏捷解决根本问题的方法；D工具问题不是主要原因。C选项通过在梳理阶段将故事拆分得更小、更清晰，可以提高估算的准确性，减少后期意外的发生。24.情景：项目进行了一半，公司决定引入一个新的自动化测试工具。技术负责人非常兴奋，希望在接下来的Sprint中花大量时间配置这个工具并编写基础测试脚本。然而，产品负责人担心这会减少用户功能的交付速度，影响发布日期。问题：在这个冲突中，ScrumMaster应该如何协助解决？A.支持技术负责人，因为技术债务偿还很重要B.支持产品负责人，因为客户价值是第一位的C.引导双方讨论，尝试将工具的集成工作拆分为小的任务，在不影响Sprint目标的前提下逐步进行，或者明确将其作为一个技术债务故事放入Backlog，由PO根据优先级排序D.由管理层决定是否引入该工具【答案】C【答案解析】这是一个典型的“探索性/技术工作”与“功能交付”的冲突。ScrumMaster不应偏向一方（A或B），也不应上交（D）。C选项是最佳实践：将技术工作透明化。如果工具集成是为了支持长期效率，可以写成技术故事放入Backlog，由PO权衡其价值与其他功能故事的优先级。或者，在Sprint中包含少量的基础设施工作，只要不破坏Sprint目标。这体现了PO对价值排序的职责和团队对技术卓越的追求。25.情景：你的团队正在开发一款金融APP。在一次Sprint评审中，一位高级合规官员指出，团队刚刚演示的一个交易功能虽然功能正常，但不符合最新的合规文档要求。团队表示并不知道合规文档已经更新。问题：为了避免这种情况再次发生，最根本的长期解决方案是什么？A.惩罚负责该功能的开发人员B.在“完成定义”中增加“必须通过合规审查”这一项C.在Sprint评审中必须邀请所有合规官员参加D.要求合规官员每天参加每日站会【答案】B【答案解析】问题的根源在于质量标准（合规性）没有被内化到团队的交付流程中。A选项是责备文化，不可取；C选项虽然可以发现问题，但不是根本解决方案，且成本高；D选项干扰团队。B选项通过修改DoD，将合规审查作为每个增量必须满足的标准，从制度上确保了未来交付的合规性，符合敏捷“持续改进质量”的原则。26.情景：一个跨职能的敏捷团队中，有几位资深的后端开发人员，但只有一位前端开发人员。最近几个Sprint，前端开发人员成为了瓶颈，导致很多后端API已经准备好，但前端界面无法完成，Story无法关闭。问题：以下哪项措施最符合敏捷的解决问题思路？A.要求后端开发人员停下来，全部去学习前端技术并帮忙B.让前端开发人员加班，以匹配后端的速度C.鼓励团队内部进行知识分享（Swarming：蜂拥式开发），或者调整Backlog优先级，暂时减少依赖前端的Story，同时寻找长期的人员技能平衡方案（如招聘、培训）D.将前端开发任务外包给第三方公司【答案】C【答案解析】这是典型的瓶颈问题。A选项全员换技能不现实且短期效率低；B选项不可持续；D选项外包是下策，且引入集成风险。C选项中的“Swarming”是指全团队齐心协力攻克瓶颈（Collaborating），同时调整优先级。敏捷强调跨职能，鼓励T型技能，通过内部协作和知识分享来解决瓶颈是最佳途径。同时，长期来看需要解决技能单一的问题。27.情景：产品负责人在一次Sprint规划中，坚持要求团队承诺完成50个故事点的任务，这比团队历史平均速度（30点）高出很多。PO的理由是“下个月有一个重大展会，我们必须发布这些功能”。团队感到压力很大，但在PO的劝说下勉强答应了。问题：这个Sprint最可能面临什么风险？ScrumMaster未能履行好哪项职责？A.风险：团队将加班完成；职责：ScrumMaster应强迫PO降低需求B.风险：质量下降或Sprint失败；职责：ScrumMaster未能保护团队免受外部压力，未能依据历史数据引导现实规划C.风险：PO会被解雇；职责：ScrumMaster应支持PO的商业决策D.风险：工具无法支持；职责：ScrumMaster应升级工具【答案】B【答案解析】在压力下承诺超出能力的任务，极大概率导致质量下降（赶工）或者Sprint失败（无法完成）。ScrumMaster的一个重要职责是保护团队，包括依据数据和现实情况，帮助团队和PO制定可达成目标，抵制不切实际的压力。虽然SM不能单方面决定范围，但必须基于数据（如速度）进行辅导和干预。A选项加班不是健康的敏捷方式；C不是主要风险；D与题意无关。28.情景：你的团队采用Scrum方法。在一次回顾会议上，团队成员提到：“我们花了太多时间在Sprint评审的准备PPT上，而不是真正准备演示环境。”问题：针对这个问题，团队应该采取什么行动？A.雇佣一名专门的助理来制作PPTB.决定在下个Sprint评审中，完全不使用PPT，直接演示可工作的软件C.练习制作PPT的技能，以提高效率D.取消Sprint评审会议【答案】B【答案解析】Sprint评审的目的是检查可工作的产品增量，而不是汇报PPT。过多的准备工作是浪费。A选项增加浪费；C选项治标不治本；D取消会议失去了反馈机会。B选项直接回归Scrum评审的本质——展示真实软件，符合敏捷“可工作的软件高于详尽的文档”原则。29.情景：一个大型项目被拆分为5个Scrum团队。团队A开发的模块需要依赖团队B的API。团队A在Sprint中期发现团队B的API接口定义有变动，导致自己的开发受阻。问题：为了避免这种跨团队依赖问题，最有效的机制是什么？A.增加文档管理的严格度B.建立ScrumofScrums（SoS）会议，让各团队代表定期协调依赖和接口问题C.将所有5个团队合并为一个超大团队D.让团队A的成员直接去团队B的工位旁监督【答案】B【答案解析】对于多团队协作，ScrumofScrums（SoS）是一种标准机制。它允许各团队代表定期沟通，识别和解决跨团队的依赖、冲突和接口变更问题。A文档往往滞后；C团队过大违反沟通法则；D不可行。SoS提供了动态调整和同步的渠道。30.情景：你是一名敏捷教练。公司高层问你：“敏捷团队不写文档，将来如何维护？我们如何知道他们做了什么？”问题：你应该如何回答？A.敏捷团队确实不写文档，代码就是文档B.敏捷并非不写文档，而是尽可能减少浪费。我们编写必要的、有价值的文档（如API文档、用户手册），并且优先保持代码的高质量和可读性。对于“做了什么”，可工作的软件增量是最好的证明。C.我们会在项目结束时补齐所有文档D.敏捷只适合小项目，不需要关心维护【答案】B【答案解析】这是一个常见的误解。敏捷宣言说“可工作的软件高于详尽的文档”，意味着“右边的项目（文档）有价值，但我们更看重左边的项目（软件）”。B选项准确阐述了敏捷对文档的态度：按需编写，不盲目排斥，同时强调代码质量和可运行软件的重要性。A选项太绝对；C选项是瀑布思维；D选项错误。31.情景：团队在使用看板方法。目前“测试”列堆积了大量卡片，而“开发”列移动很快。这导致了整体交付延迟。问题：这是看板中的什么现象？应该采取什么措施？A.现象：瓶颈在测试。措施：暂停开发，或者将部分开发人员临时调配去协助测试（Swarming），直到测试列恢复流动B.现象：开发太慢。措施：增加开发人员C.现象：测试人员能力不足。措施：解雇测试人员D.现象：WIP限制太低。措施：取消WIP限制【答案】A【答案解析】看板图中，堆积最多的地方就是瓶颈。根据利特尔法则，系统的产出取决于瓶颈的吞吐量。A选项符合精益思想：限制非瓶颈环节的上游产出（停止启动），或者帮助瓶颈（开始完成）。通过调配资源支援测试是缓解瓶颈的直接手段。B、C、D都无法解决流动问题，甚至可能恶化。32.情景：在Sprint的最后一天，团队发现还有一个P0级（最高优先级）的Bug未修复，但这会影响Sprint目标的达成。团队讨论后决定，虽然Sprint时间到了，但他们决定自发地再花几天时间修复这个Bug，确保高质量交付。问题：作为ScrumMaster，你对团队的决定有何评价？A.表扬团队，因为质量第一B.提醒团队，Sprint时长是神圣的时间盒，不应随意延长。如果Bug影响Sprint目标，应视为Sprint未完全达成，应在回顾中分析为何Bug没被发现，而不是延长SprintC.向管理层报告团队加班D.帮助团队延长Sprint【答案】B【答案解析】虽然质量很重要，但Sprint时间盒是Scrum的规则之一。随意延长Sprint会破坏节奏和可预测性，掩盖规划或开发过程中的问题（如为何P0Bug留到最后）。正确的做法是遵守时间盒，未完成的Story放回Backlog（如果是P0Bug，PO会立即将其放入下一个Sprint顶部）。ScrumMaster应维护流程规则的完整性。A选项忽视了流程规则；C、D不是首要反应。33.情景：项目接近尾声，PO和团队正在讨论发布。团队认为还有不少技术债务需要偿还，否则后续维护会很困难。PO认为市场窗口期即将关闭，必须先发布所有功能。问题：如何解决这个冲突？A.立即发布，技术债务以后再说B.拒绝发布，直到技术债务清零C.评估技术债务的风险，如果债务可能导致系统崩溃或严重不可用，则必须优先处理；如果是代码层面的优化，可考虑在发布后立即安排Sprint专门处理技术债务D.抛硬币决定【答案】C【答案解析】这是商业价值（时间）与技术质量的权衡。不能走极端（A或B）。C选项提供了一个理性的风险评估方案。如果技术债务危及系统安全性或稳定性，它是阻碍发布的因素；如果是优化问题，可以通过权衡先发布，随后快速迭代修复。这体现了敏捷的pragmatism（实用主义）。34.情景：一个敏捷团队正在开发一个电商网站。团队决定采用“功能驱动开发（FDD）”中的特性团队组织方式。问题：以下哪项是特性团队的主要优势？A.每个成员都只需要掌握自己专业的技能（如只做数据库）B.团队是跨职能的，能够端到端地交付用户价值，减少依赖和协调成本C.更有利于项目经理进行微观管理D.适合构建架构层级清晰的系统【答案】B【答案解析】特性团队组织是为了最大化对用户价值的交付速度。团队拥有完成某个功能所需的所有技能（UI、DB、后端等），从而减少了跨组件依赖和握手。A是组件团队的特征；C敏捷反对微观管理；D组件团队更关注架构层级。35.情景：在进行敏捷估算时，团队决定使用“T恤尺码”（XS,S,M,L,XL）而不是数字。问题：这种估算方法的主要优点和缺点是什么？A.优点：可以精确计算工时；缺点：难以理解B.优点：直观，避免了数字带来的虚假精确感；缺点：难以追踪速度（Velocity），因为无法直接相加C.优点：适合所有团队；缺点：太复杂D.优点：管理层喜欢；缺点：开发人员不喜欢【答案】B【答案解析】T恤尺码是一种相对估算的定性方法。它的优点在于去除了数字带来的精确假象，让团队关注相对大小。缺点在于无法直接进行数学运算（如计算平均速度），通常需要映射到数字或使用不同的追踪方式。A选项错误；C选项并非适合所有追踪需求；D选项管理层通常更喜欢数字报告。36.情景：ScrumMaster注意到，在每日站会上，团队成员总是对着ScrumMaster汇报：“昨天我做了X，今天我做Y，没有障碍。”问题：这说明了什么？ScrumMaster应该怎么做？A.说明团队很自律，不需要干预B.说明团队误解了站会目的，将其变成了状态汇报会。ScrumMaster应引导团队成员互相沟通，针对后续计划进行协商，而不是向SM汇报C.说明ScrumMaster工作不到位，应该替团队解决问题D.说明团队没有障碍，这是好消息【答案】B【答案解析】站会是团队为了同步计划而开的，不是给SM听的汇报会。如果只对着SM讲，说明团队缺乏协作意识。SM需要纠正这一行为，引导成员之间对话（例如，“既然你今天要做Y，那我也需要Y的接口，我们会后碰一下”）。A、C、D都未识别出流程偏差。37.情景：团队在一个Sprint中完成了所有计划的Story，并且还有时间。于是他们从ProductBacklog中拉取了新的Story。问题：这在敏捷中被称为？A.范围蔓延B.提前交付C.动态范围管理【答案】C【答案解析】在Sprint中，如果团队提前完成，允许从Backlog顶部拉入新故事，这被称为动态范围管理，旨在最大化团队的生产力。这与范围蔓延不同，范围蔓延通常指未控制的、未经流程的外部变更。38.情景：敏捷团队中的某位成员在公开会议上总是嘲笑其他成员提出的想法，导致大家不敢发言。问题：这破坏了敏捷的什么核心价值观？ScrumMaster应如何处理？A.价值：勇气。处理：鼓励该成员继续坚持B.价值：尊重。处理：私下与该成员沟通，指出其行为对团队心理安全感的破坏，并要求其改正C.价值：专注。处理：忽略他D.价值：开放。处理：让他主持会议【答案】B【答案解析】敏捷宣言的五个价值观是承诺、勇气、专注、开放、尊重。嘲笑他人违背了“尊重”，也破坏了团队建立心理安全感所需的环境。ScrumMaster必须干预，通常先私下辅导，若无效则升级处理，以维护团队环境。39.情景：为了提高透明度，团队决定在墙上挂一个大大的实体看板。问题：除了透明度，实体看板还有什么好处？A.可以作为团队的信息辐射器，促进日常对话，且持久可见（不需要开机就能看）B.比电子工具更容易生成报告C.可以远程访问D.自动计算图表【答案】A【答案解析】实体看板是信息辐射器。它的优势在于高可见性（路过就能看到）、促进面对面沟通（站在板前讨论）、简单直观。B、C、D通常是电子工具的优势。40.情景：一个分布式敏捷团队，分布在三个时区。为了有效协作，他们决定安排每日站会。问题：最佳的时间安排策略是？A.按照总部时间开会B.轮流牺牲，每次都让时区最晚的人熬夜开会C.寻找一个对大家相对重叠的时间窗口，并每次轮流在不同时区的“黄金时间”开会，以公平分担不便D.取消每日站会，改用邮件汇报【答案】C【答案解析】分布式团队需要考虑公平性和可持续性。C选项体现了对团队成员的尊重和公平。A、B对部分团队不友好；D失去了同步沟通的效果。第六部分：混合题型与综合应用七、简答题41.请简述Scrum框架中三个角色的主要职责，并解释为什么产品负责人（PO）和ScrumMaster（SM）不能由同一个人担任？【答案】Scrum角色职责：1.产品负责人（PO）：负责最大化产品价值和投资回报（ROI）。主要职责包括明确产品愿景、创建和管理产品待办列表、对条目进行优先级排序、做出发布决策、验收团队完成的增量。2.ScrumMaster（SM）：负责过程有效性，是服务型领导。主要职责包括教导团队理解Scrum理论/实践/规则、移除团队障碍、促进Scrum事件（如站会、评审、回顾）、保护团队免受外部干扰、辅导组织采纳Scrum。3.开发团队：负责在每个Sprint结束时交付可用的“完成”增量。主要职责包括自组织、在SprintBacklog中选择任务、执行工作、通过每日站会同步进度、决定完成定义的技术细节。为何PO与SM不能兼任：Scrum要求角色之间保持制衡和关注点的分离。PO关注“做什么”（产品价值），代表业务和用户利益。SM关注“怎么做”（流程效率），代表团队和流程利益。如果一人兼任，当面临“质量vs进度”或“流程规范vs快速交付”的冲突时，该角色会产生严重的利益冲突，无法客观地做出有利于项目的决定。例如，PO可能为了功能牺牲流程，而SM需要维护流程规则。兼任会破坏Scrum的透明度和检查与适应机制。42.在敏捷项目管理中，“用户故事”应包含哪三个要素（3C原则）？并请解释INVEST原则的含义。【答案】用户故事的3C原则：1.Card（卡片）：用于书写故事的物理或虚拟载体，通常简短。2.Conversation（对话）：指PO、团队与测试人员等干系人之间关于故事的详细内容、规则和验收标准的持续沟通。3.Confirmation（确认）：指验收测试条件，用于确认故事是否被正确实现。INVEST原则（用于评估高质量用户故事的标准）：1.Independent（独立的）：故事之间应尽量减少依赖，以便排序。2.Negotiable（可协商的）：故事是需求描述，不是固定合同，细节可通过讨论确定。3.Valuable（有价值的）：故事必须对客户或用户有价值。4.Estimable（可估算的）：故事的大小要足够清晰，使团队能够估算工作量。5.Small（小的）：故事应足够小，以便在一个Sprint内完成。6.Testable（可测试的）：必须有明确的验收标准，以验证完成情况。八、计算与分析题43.某敏捷团队正在进行发布规划。已知团队的平均速度为每个Sprint45个故事点。产品待办列表中总共有540个故事点的功能需求。团队计划每2周进行一次Sprint。问题1：如果团队速度保持不变，预计需要多少个Sprint才能完成所有功能？问题2：预计的发布周期是多少周？问题3：如果在第4个Sprint结束后，团队的实际速度分别为：40,45,50,40。请重