PMP新考纲敏捷项目练习考题及答案解析

PMP新考纲敏捷项目练习考题及答案解析第一部分：情境化单选题1.在一个敏捷软件开发项目中，团队由7名全职成员组成，其中包括一名ScrumMaster。在Sprint进行到一半时，产品负责人（PO）找到团队，告诉他们市场环境发生了剧烈变化，一个高优先级的新功能必须立即加入当前Sprint以确保产品的竞争力。PO请求ScrumMaster批准在当前Sprint中加入这个新工作。作为ScrumMaster，你应该如何回应？A.立即召开紧急团队会议，讨论是否可以将新功能加入当前Sprint，并告知PO这是特例。B.拒绝PO的请求，解释一旦Sprint开始，其范围是固定的，不能增加新工作，只能移除工作。C.接受PO的请求，因为敏捷原则强调响应变化高于遵循计划，应将该新功能加入当前Sprint的待办列表末尾。D.与PO沟通，解释Sprint的目标和范围在Sprint规划会议确定后不应变更，建议将新功能放入产品待办列表的顶部，并在下一个Sprint中优先考虑。答案：D解析：在Scrum框架中，Sprint（冲刺）是一个时间盒（Time-boxed），通常为1-4周。一旦Sprint开始，其目标和范围应当保持稳定，以保护团队免受干扰，使其能够专注于承诺的工作。这是为了保证团队有可预测的生产节奏。选项A错误，因为虽然可以开会，但在Sprint中期增加范围会破坏Sprint的目标，且ScrumMaster不应单方面批准改变Sprint范围，这违背了时间盒和范围稳定性的原则。选项B错误，虽然Sprint范围通常固定，但“只能移除工作”并非绝对正确，且如果Sprint目标不再有效，Sprint甚至可以被取消。但在本题语境下，单纯的生硬拒绝不是最佳的服务型领导表现。更重要的是，PO有权管理待办列表的内容，但无权干涉Sprint内部的执行。选项C错误，虽然敏捷欢迎变化，但在Sprint内部，为了保护团队的专注力，短期的变化通常不直接加入当前正在进行的Sprint，除非Sprint本身被取消。选项D正确，ScrumMaster作为服务型领导，需要教育利益相关者关于敏捷流程的规则。他/她应向PO解释，为了保护团队的专注度和Sprint目标的达成，新功能应放入产品待办列表，并按优先级排序，在下一个Sprint规划会议时处理。这既尊重了PO的优先级决定权，又维护了Scrum的流程完整性。2.一个敏捷团队已经工作了几个Sprint，团队成员之间相处融洽，但在最近的几次回顾会议上，大家发现虽然团队速度很稳定，但每个Sprint结束时，仍有部分用户故事未能达到“完成”的定义，导致这些故事被推迟到下一个Sprint。团队感到有些沮丧。作为敏捷教练，你建议团队首先应该做什么？A.增加Sprint的长度，给予团队更多的时间来完成用户故事。B.在Sprint规划会议中减少承诺的故事数量，以确保所有故事都能完成。C.审查并优化“完成”的定义，检查是否包含所有必要的活动，或者检查是否因为估算不准确导致经常无法完成。D.引入加班机制，在Sprint的最后几天集中力量完成未完成的工作。答案：C解析：这个问题涉及到敏捷中的质量控制和透明度。“完成”的定义是Scrum中至关重要的概念，它明确了当用户故事被认为是“完成”时必须满足的标准（如：代码编写、单元测试、集成测试、文档编写等）。选项A错误，增加Sprint长度违反了敏捷开发中的短周期迭代原则，会降低反馈频率，掩盖问题而非解决问题。选项B错误，虽然减少承诺数量可能缓解燃尽图的压力，但这只是治标不治本。如果“完成”的定义不清晰或不切实际，或者估算能力有问题，单纯减少数量并不能解决根本原因，且可能降低生产力。选项C正确，如果经常有故事未能完成，首先应检查“完成”的定义是否被严格执行，或者标准是否清晰。此外，这也可能与估算准确性有关。通过回顾会议分析未完成的原因（是技术难点、依赖关系还是理解偏差？），并针对性地优化DoD或改进估算技巧，是解决此问题的根本途径。选项D错误，敏捷不鼓励持续加班，这会导致职业倦怠，降低代码质量，形成恶性循环。3.你是一名新加入项目的敏捷教练。该团队采用Scrum方法，但团队成员习惯于等待任务分配，而不是主动从看板上拉取任务。ScrumMaster尝试鼓励大家主动，但效果不佳。在一次每日站会上，开发人员A说：“我昨天完成了任务X，现在等待经理分配任务Y。”作为敏捷教练，你观察到这种情况，最有效的干预措施是什么？A.在每日站会后立即与开发人员A私下谈话，批评他缺乏主动性。B.在站会上公开纠正开发人员A，告诉他必须主动拉取任务。C.与ScrumMaster和产品负责人沟通，重新组织团队建设活动，强调自组织团队的重要性，并帮助团队建立明确的领取机制。D.接纳这种现状，因为文化改变需要时间，并让ScrumMaster开始为团队成员分配任务以保证进度。答案：C解析：这个问题考察的是“自组织团队”的建设。敏捷团队的核心特征之一是自组织，即团队成员自己决定谁做什么工作，而不是由管理者指派。选项A和B错误，公开批评或私下指责都不是教练的最佳实践。这种行为会制造恐惧心理，破坏心理安全感，使团队成员更不敢尝试新行为。选项D错误，这是退回到命令控制型管理模式，违背了敏捷的核心价值观。虽然文化改变需要时间，但教练不能因此放弃引导，更不能亲自去强化错误的行为模式。选项C正确，团队习惯于被动接受任务，说明缺乏自组织的习惯或机制。作为教练，应引导ScrumMaster和团队通过团队建设活动、工作坊等形式，建立任务领取的规则（例如：泳道、技能标签、WIP限制等），并营造一种主动承担责任的安全氛围。通过系统性的引导和机制建设，比单纯的批评更有效。4.项目采用混合模式管理，部分团队使用敏捷，部分团队使用瀑布。敏捷团队每两周交付一次增量，而依赖的架构团队使用瀑布模式，每三个月交付一次核心架构组件。这导致敏捷团队在等待架构组件时经常受阻。项目经理应该如何解决这个依赖问题？A.要求架构团队也转为敏捷模式，保持步调一致。B.将敏捷团队的Sprint长度调整为3个月，与架构团队对齐。C.在架构团队和敏捷团队之间建立“接口团队”或进行频繁的协调会议，提前识别依赖点，并使用特性待办列表管理这些依赖。D.让敏捷团队在这期间开发其他不依赖该架构的功能，或者进行技术探索，等待架构组件就绪后再集成。答案：C解析：这是一个典型的混合环境下的依赖管理问题。选项A不切实际，虽然长期来看统一模式好，但在短期内要求另一个成熟团队改变模式可能面临巨大阻力，且不一定能立即解决当前依赖。选项B错误，将敏捷Sprint延长到3个月使其失去了敏捷的意义，变成了小瀑布。选项D是被动应对策略，虽然可以暂时缓解，但如果没有协调机制，可能会导致关键路径延误，且如果所有功能都强依赖，团队将无事可做。选项C最佳。在混合模式下，建立有效的协调机制是关键。通过“接口团队”或定期的同步会议（如ScrumofScrums），可以提前暴露依赖风险。使用特性待办列表可以让架构团队清晰地看到敏捷团队的需求优先级，从而可能调整他们的交付计划，或者分阶段交付接口。这是主动管理依赖的做法。5.在Sprint评审会议上，产品负责人演示了新开发的功能。一位关键利益相关者对此非常不满，认为这不是他想要的功能，并指责团队浪费了时间。团队感到非常困惑，因为在Sprint规划时，他们确认了验收标准。作为ScrumMaster，你应该怎么做？A.支持团队，告诉利益相关者验收标准已达成，功能符合要求。B.立即取消当前Sprint，并在下一个Sprint重新开发该功能。C.记录下利益相关者的反馈，建议产品负责人在后续的产品待办列表梳理和规划会议中加强与该利益相关者的沟通，以确保需求理解一致。D.在会议结束后，让技术负责人与利益相关者进行技术辩论，证明为什么当前实现是合理的。答案：C解析：这个问题考察的是利益相关者管理和产品负责人的职责。选项A错误，虽然技术上可能符合验收标准，但敏捷的核心价值是交付有价值的软件。如果客户不满意，单纯用“符合标准”来反驳是缺乏客户协作精神的体现。选项B错误，Sprint通常只有在目标变得毫无意义时才被取消。仅仅因为一个功能不满意就取消整个Sprint是过激反应，浪费了团队在其他Story上的努力。选项D错误，技术辩论往往解决不了业务价值不对齐的问题，且容易激化矛盾。选项C正确，ScrumMaster是服务型领导，也是流程的维护者。出现这种情况，说明需求传递环节出了问题。ScrumMaster应记录反馈，并辅导PO。PO负责最大化产品价值，也是利益相关者与团队之间的桥梁。ScrumMaster应帮助PO意识到需要加强与该关键利益相关者的互动，确保未来的开发工作对齐业务期望。6.一个分布式的敏捷团队，成员位于三个不同的时区。团队发现每日站会效率低下，因为总是有人因为时间问题无法参加，或者参加时精神状态不佳。此外，沟通延迟也影响了协作。以下哪项措施最能改善分布式团队的协作效率？A.取消每日站会，改用每日状态报告邮件。B.要求所有成员都调整工作时间，重叠至少4小时的工作时间。C.使用异步沟通工具（如Jira,Confluence）更新状态，并设立每周一次的全员视频同步会议。D.轮换站会时间，确保每次会议都在每个时区的黄金工作时间举行。答案：B解析：分布式团队是敏捷实践中的难点。选项A错误，每日站会是Scrum的事件，用于同步计划和检查进度。取消会议改为邮件会失去实时互动和解决障碍的机会，违背了Scrum原则。选项C错误，虽然异步工具很重要，但完全取消每日同步会导致团队凝聚力下降，问题发现滞后。每周一次太慢，无法满足敏捷的快速反馈需求。选项D看似公平，但会导致所有人都在非正常时间开会，长期来看不可持续且效率低。选项B最佳。分布式敏捷团队的最佳实践是建立“黄金重叠时间”，即所有成员（或核心成员）都处于工作时间的重叠窗口。虽然这需要个人牺牲，但这是保证实时协作（如站会、结对编程）的最有效方式。在这个窗口内进行关键同步会议，其余时间可异步沟通。7.团队正在使用看板方法管理工作。在制品限制设置为3。目前“开发”列有3个任务，均处于停滞状态。一名开发人员想要从“待办”列拉入一个新任务开始工作，但被看板工具阻止了。他向你抱怨说：“我有空闲时间，为什么不让我拉新任务？”你应该怎么建议他？A.临时将WIP限制增加到4，允许他拉入新任务。B.帮助他分析“开发”列中那3个停滞任务的根本原因，并协助清除障碍。C.让他去帮助测试人员做测试工作，因为测试列可能很忙。D.忽略WIP限制，手动将卡片拖入“开发”列，因为效率很重要。答案：B解析：看板的核心目的是限制在制品（WIP），以此促进流动、暴露瓶颈和发现问题。选项A和D错误，随意增加WIP限制或绕过限制会掩盖问题。当“开发”列满员且停滞时，说明“开发”环节是瓶颈。允许更多任务进入只会增加库存，延长交付周期，且不解决停滞问题。选项C是一个备选方案，如果测试确实是瓶颈且开发人员具备测试技能，这符合“泳道”或“跟随工作”的原则。但是，题目中并未明确测试列的状态，且首要任务是解决当前列的停滞。选项B最佳。WIP限制触发了停止信号，这是一个改进的机会。开发人员有空闲时间，说明资源利用率低，但任务流转慢。正确的做法是利用这个空闲时间去解决那3个停滞任务的问题（找原因、协调依赖、修复Bug），从而疏通流程，让任务流动下去，这才是看板的精髓。8.你是项目集经理，负责监管多个相关的敏捷项目。高层管理人员要求你提供一份关于项目集整体进度的预测报告，以便向董事会汇报。他们习惯于看到甘特图和关键路径分析。以下哪种方式最适合满足管理层的需求，同时保持敏捷团队的灵活性？A.强制所有敏捷团队停止使用Sprint，转而使用微软Project软件进行详细的项目计划。B.收集各团队的发布燃尽图和产品待办列表的趋势，汇总成一份基于价值的交付进度报告，解释敏捷的不确定性特点。C.要求各ScrumMaster提供详细的Sprint任务清单，自己手动绘制甘特图。D.拒绝提供报告，告诉董事会敏捷项目没有甘特图，只有产品待办列表。答案：B解析：这是关于在敏捷环境中向上级管理的汇报问题。选项A和C错误，这会导致“微管理”，强迫敏捷团队回到瀑布式的详细计划中，破坏团队的自组织和适应性。选项D错误，虽然敏捷不推崇甘特图，但作为项目经理/集经理，有责任向利益相关者提供可视化的进度信息。直接拒绝是不专业的。选项B正确。敏捷团队可以使用发布燃尽图、累积流图等工具来展示趋势。作为项目集经理，应利用这些数据生成一份高层级的报告。重点应放在已交付的价值、剩余工作量的趋势以及风险上。同时，这也是一个教育管理层的机会，解释敏捷是基于经验主义过程的预测，虽然不如甘特图“精确”，但更能反映现实的不确定性，有助于做出更好的决策。9.在Sprint回顾会议上，团队气氛非常紧张。两名核心开发人员就代码架构的设计产生了严重分歧，互不相让，导致会议无法继续进行。作为ScrumMaster，你应该如何处理？A.宣布会议结束，让两名成员会后私下解决。B.利用冲突解决技巧，引导双方表达观点，寻找共同点，或者提出折中方案（如技术探索），如果无法达成一致，由产品负责人做决定。C.投票表决，少数服从多数。D.将问题升级给职能经理，让他来裁决技术架构。答案：B解析：团队冲突是ScrumMaster必须面对的挑战。选项A是逃避问题，冲突如果不解决，会影响团队协作和士气。选项C看似民主，但在技术架构问题上，简单的投票可能导致“多数人的暴政”，输掉的一方可能消极怠工，且技术决策往往不是靠人数决定的。选项D错误，升级给职能经理是命令控制型做法，剥夺了团队的自组织权利，ScrumMaster应尽量在团队内部解决问题。选项B最佳。ScrumMaster应作为教练，引导健康的冲突。通过引导技术讨论，帮助团队聚焦于“什么对产品最好”，而不是“谁是对的”。如果短期内无法达成一致，可以建议进行spikes（技术探索）来验证不同方案，或者为了进度暂时选择一种方案（Decidenow,revertlater），但绝不能让冲突破坏团队关系。注意：产品负责人通常不决定技术实现细节，除非涉及商业价值权衡，所以主要依靠ScrumMaster引导团队自行解决或技术探索。10.一个敏捷团队正在开发一个复杂的金融系统。在Sprint中期，团队发现了一个重大的安全漏洞，修复它可能需要花费整个团队3天的时间。当前Sprint还剩5天，且团队已经承诺了若干高优先级的用户故事。作为ScrumMaster，当团队得知这个消息后，你期望团队怎么做？A.忽略安全漏洞，因为不在当前Sprint的范围内，等到下一个Sprint再处理。B.立即停止当前工作，全员修复安全漏洞，如果无法完成原本承诺的Story，就在Sprint评审会议上解释原因。C.询问产品负责人是否要暂停当前Sprint，或者将安全漏洞作为最高优先级插入当前Sprint，并协商移除等量的低优先级工作。D.让团队中能力最弱的成员去修复漏洞，其他人继续完成承诺的Story。答案：C解析：这是关于范围变更和优先级的问题。安全漏洞通常属于高优先级甚至“阻碍发布”的问题。选项A极其危险，安全漏洞不能忽视，否则交付的产品没有价值。选项B看似负责，但ScrumMaster不应直接命令团队停止工作。且如果未与PO协商直接改变Sprint范围，可能会破坏Sprint目标的完整性。选项D错误，安全漏洞修复往往需要高水平，且分兵作战可能导致两边都做不好。选项C正确。当出现意外的重要工作时，ScrumMaster应协助团队与PO沟通。PO负责最大化产品价值并决定优先级。团队向PO说明情况：发现严重漏洞，修复需3天。PO可以决定：1.取消当前Sprint；2.将漏洞插入当前Sprint，并移除等量的其他工作以维持容量平衡；3.如果漏洞不阻碍当前发布，可放入下一个Sprint。这样既保证了透明度，又尊重了PO的决策权。11.敏捷团队在使用用户故事进行需求管理。产品负责人写了一个用户故事：“作为一个用户，我希望系统响应速度快，以便我有好的体验。”团队成员在进行估算时认为这个故事无法估算。为什么？团队应该建议PO如何修改？A.因为故事太大，需要拆分。B.因为故事缺乏具体的验收标准，且“快”是主观的，不可测试。C.因为故事不独立，依赖于其他系统。D.建议PO删除这个故事，因为非功能性需求不放在用户故事中。答案：B解析：这个问题考察的是INVEST原则（Independent,Negotiable,Valuable,Estimable,Small,Testable）。选项A（太大）可能是一个原因，但主要问题在于内容本身无法量化。选项C（依赖性）题目中没有体现。选项D错误，非功能性需求（如性能、安全）完全可以放在用户故事中，或者作为技术任务。选项B正确。这个故事无法估算和测试的原因在于它缺乏具体的“如何验证”的标准。“快”是主观的。团队应建议PO将其具体化，例如：“作为一个用户，我希望页面加载时间在2秒以内，以便...”或者增加具体的验收标准：“在1000并发用户下，响应时间<500ms”。这样故事才变得可估算和可测试。12.在一个采用SAFe（ScaledAgileFramework）的大型项目中，你是一个敏捷团队的ScrumMaster。在PI（项目增量）规划会议上，各团队展示了自己的capacities（容量）和draftplans（草拟计划）。但是，总体来看，由于依赖关系过多，架构风险未解决，管理层认为无法达成PI的目标。此时应该发生什么？A.强制各团队加班，确保PI目标达成。B.重新调整PI的范围，移除低价值的特性，直到风险可接受，或者建立“悬念”列表。C.取消本次PI，推迟两个月再进行规划。D.让架构团队单独加班解决架构风险，开发团队按原计划进行。答案：B解析：这是SAFe中PI规划的一个典型场景。选项A不可取，加班不能解决依赖和架构风险。选项C是下下策，推迟PI会造成巨大浪费和延迟。选项D有风险，如果架构风险阻碍开发，开发团队单独进行也是浪费。选项B正确。在PI规划的最后，如果通过“投票”显示团队无法承诺，那么必须进行调整。这包括：重新分配特性、降低范围（移除Feature）、建立悬念列表（将不确定的工作放入）、或者增加资源（如果可能）。目标是制定出一个可行的、可靠的计划。这是SAFe中“自组织”在项目集层面的体现。13.团队正在使用XP（极限编程）实践，包括结对编程。最近，新加入了一名成员，他非常抵触结对编程，认为这效率低下，浪费了一半的人力。他向你抱怨说：“我自己写代码更快。”你应该如何回应？A.强制要求他必须结对编程，因为这是团队规则。B.允许他单独编程，观察他的产出和质量。C.与他探讨结对编程的价值，如知识共享、代码质量、集体代码所有权，并建议他先尝试一段时间，关注团队整体效能而非个人产出。D.让他在回顾会议上提出废除结对编程的动议。答案：C解析：这是关于引入敏捷实践时的阻力管理和教练技术。选项A过于强硬，容易引起逆反心理，且未解释原因。选项B看似妥协，但如果团队规则是结对编程，打破规则会破坏团队一致性。且单独编程可能引入Bug，增加后续维护成本。选项D把问题抛给回溯会议虽然可以，但作为教练，ScrumMaster有责任在平时进行辅导。选项C最佳。ScrumMaster应运用辅导技巧，解释敏捷实践背后的“为什么”。结对编程不仅仅是写代码，更是实时的代码审查和知识传播。对于新成员，结对是快速融入团队、学习代码库的最佳途径。建议他关注长期收益（质量、风险降低）和团队整体效能，而不是短期的个人打字速度。14.在一个Sprint中，团队完成了所有计划的用户故事，并提前两天完成了Sprint目标。团队询问ScrumMaster接下来该做什么。以下哪个选项是ScrumMaster的最佳建议？A.提前结束Sprint，开始下一个Sprint的规划会议。B.让大家休息，享受提前完成的喜悦。C.从产品待办列表的顶部拉入新的用户故事，只要在Sprint结束前能完成。D.利用剩余时间进行技术探索、重构代码、偿还技术债务，或者帮助完善自动化测试。答案：D解析：这是关于Sprint提前完成后的处理。选项A错误，Sprint是时间盒，不能因为提前完成工作就缩短时间盒。时间盒的目的是保持节奏和减少开销。选项B不建议，虽然可以适当调整节奏，但Sprint时间是为了交付价值，完全休息可能浪费了付费的产能。选项C有争议。如果团队确实能完成且PO在场，可以拉入新故事。但根据现代敏捷理念，过早填充Sprint可能导致团队为了填满时间而拉入低价值工作，或者掩盖了估算偏差（即原本可以承诺更多）。选项D最佳。利用“slacktime”（松弛时间）进行技术改进是敏捷推荐的做法。团队往往忙于功能开发而忽视技术债务。利用这段意外获得的时间进行重构、提升自动化覆盖率或探索新技术，能为未来的Sprint加速。这体现了“可持续发展的步伐”和技术卓越。15.一个项目刚刚启动，产品负责人收集了大量的需求。为了开始工作，团队需要对这些需求进行初步估算。但是，对于一些涉及新技术的需求，团队完全不知道如何估算。此时应该使用什么方法？A.使用计划扑克进行相对估算。B.将这些需求标记为“史诗”，并创建“Spike”（探索/探针任务）来进行研究，以便在未来的Sprint中获得更准确的估算。C.联请外部专家给出一个估算值。D.暂时跳过这些需求，先估算那些熟悉的。答案：B解析：这是关于不确定性处理的问题。选项A无法进行，因为团队缺乏估算的基础知识。选项C可以参考，但最终执行和承担风险的是团队，外部专家的估算往往不够准确或团队不认同。选项D是逃避，如果这些是高价值需求，跳过会影响产品规划。选项B正确。Spikes是敏捷中专门用于处理不确定性的一种特殊用户故事（TypeEnabler）。Spike的时间是盒子的，其产出不是可交付的功能，而是知识（答案、原型、PoC）。通过Spike，团队可以拆解史诗，了解技术细节，从而在后续的Sprint规划中给出准确的估算。第二部分：多选题16.【多选】作为ScrumMaster，你发现团队在每日站会上经常陷入细节讨论，导致会议超时且枯燥。为了改善站会质量，你可以采取哪些行动？（请选择三项）A.建议团队将技术细节讨论留到站会后的专门会议进行。B.严格执行15分钟时间盒，一旦超时立即中断会议。C.引入“通行证”机制，如果团队成员没有更新内容，可以说“Pass”。D.在站会上设置一个“会说话的动物”玩偶，只有持有玩偶的人才能发言，避免插话。E.取消每日站会，改为每天在项目管理软件上更新进度。答案：A,B,D解析：每日站会的目的是同步计划，不是解决问题。A正确：这是标准建议，站会只谈“做了什么、要做什么、有什么障碍”，细节问题会后单独讨论。B正确：15分钟时间盒是Scrum的规则，必须遵守。D正确：使用物理道具（如球、玩偶）可以有效控制发言秩序，防止多人同时说话或打断，这在分布式或话痨团队中很有效。C错误：虽然可以说Pass，但这不能从根本上解决陷入细节讨论的问题。E错误：取消站会违背Scrum原则。17.【多选】以下哪些是敏捷宣言背后的原则？（请选择三项）A.欢迎对需求提出变更，即使是在项目开发后期。敏捷流程利用变更来为客户维持竞争优势。B.可以工作的软件是进度的首要度量标准。C.经常交付可工作的软件，间隔从几周到几个月，倾向于越短越好。D.不惜一切代价通过详尽的文档来捕捉需求。E.项目构建围绕着被激励起来的个体，给予他们所需的环境和支持，并信任他们能够完成工作。答案：A,B,C,E解析：注：题目要求选三项，但A,B,C,E均正确。如果是严格的选三项，通常A,B,C是最核心的特征。但E也是核心原则。这里我们分析所有选项。A正确：敏捷响应变化。B正确：可工作的软件胜过详尽的文档，是度量进度的首要指标。C正确：频繁交付。D错误：这是瀑布模式的特征，敏捷强调“可工作的软件胜过详尽的文档”。E正确：个体与互动高于流程与工具。（注：如果系统强制只能选三项，建议选A,B,C，因为它们直接关联到“交付”和“变化”的核心机制。但E同样是正确的原则。）第三部分：综合案例分析题案例背景：你是一家大型电信公司的项目经理，负责一个“5G客户计费系统升级”项目。该项目旨在将旧的计费系统迁移到云端，并引入新的实时计费功能。项目工期紧，商业环境变化快，且涉及大量遗留代码。公司决定采用混合模式：核心数据库迁移小组采用瀑布模式，因为迁移工作不可逆且风险极高；而新的计费功能开发小组采用Scrum敏捷模式。你是负责整体协调的项目经理。项目已经进行了3个月。目前出现以下状况：1.敏捷团队（FeatureTeam）每两周一个Sprint。在第6个Sprint结束时，敏捷团队交付了承诺的功能，但在集成测试时发现，数据库迁移小组（DBTeam）的接口定义发生了一次变更，导致敏捷团队开发的功能无法正常连接数据库。2.敏捷团队指责DBTeam没有及时通知变更；DBTeam则指责敏捷团队没有查看他们每周发布的邮件文档。3.产品负责人（PO）非常焦虑，因为市场部刚刚确认，一个新的“流量包动态计费”功能必须在6周后上线，否则将失去大客户。这个功能非常复杂，涉及多个模块。4.敏捷团队目前的平均速度为30点/Sprint。新功能经过初步估算，大约为120点。5.团队士气低落，因为频繁的返工和紧急插队让他们感到疲惫。问题18：针对状况1和2（接口变更导致的集成失败），作为项目经理，你应采取什么长期措施来防止此类问题再次发生？A.惩罚DBTeam的负责人，因为他们没有遵循沟通计划。B.建立一个跨团队的“集成看板”，并设立定期的“ScrumofScrums”会议，让双方的技术代表参加，提前对齐接口依赖。C.要求敏捷团队在每个Sprint中安排50%的时间用于处理DBTeam的变更。D.停止所有开发工作，直到DBTeam冻结所有接口。答案：B解析：这是典型的跨团队依赖和沟通断裂问题。A错误：惩罚不能解决问题，只会破坏信任。C错误：预留50%时间过高，浪费产能，且治标不治本。D错误：完全冻结接口在瀑布/敏捷混合环境中不现实，且会阻碍进度。B正确：在混合环境中，必须建立显式的依赖管理机制。“ScrumofScrums”允许不同团队的代表定期同步，识别接口冲突。“集成看板”可以让双方看到集成状态和阻塞点。这能促进早期协作，而不是依赖被动的邮件文档。问题19：针对状况3和4（紧急的高价值新功能），PO希望团队能在6周内（即3个Sprint）交付该120点的功能。基于目前的数据，这种做法具有很高的风险。作为项目经理，你应该给PO提供什么建议？A.拒绝PO的请求，告诉他在6周内不可能完成。B.同意PO的请求，并要求团队在下个Sprint立即开始，加班赶工。C.与PO和团队一起探讨“最小可发布增量”（MVP），将120点的功能拆分，找出能在6周内交付的最核心子集（约90点），剩余部分延后或分批交付。D.将新功能外包给其他团队完成，以减轻当前团队压力。答案：C解析：这是关于范围管理和敏捷规划的问题。A错误：直接拒绝没有建设性，PO面临商业压力，需要解决方案。B错误：盲目承诺会导致团队崩溃，且根据平均速度，30*3=90点，120点在3个Sprint内完成是不现实的，加班不可持续。D错误：外包新功能涉及复杂的知识转移和集成风险，短期来看风险更大。C正确：敏捷的核心是交付价值。如果全部120点无法按时交付，应通过MVP思维，拆分需求，识别出那80%价值所在的20%功能（或按优先级排序），确保在6周交付最有价值的部分。这既响应了市场压力，又尊重了团队的实际产能。问题20：针对状况5（团队士气低落），以及整体的项目环境，为了改善团队的健康度，你应该优先关注哪两个方面？（请选择两项）A.增加团队建设活动，如聚餐和游戏。B.保护团队免受外部干扰，建立清晰的“完成”定义，并确保PO对待办列表进行优先级排序，减少Sprint中的变更。C.提高技术实践，如引入持续集成（CI/CD）和自动化测试，以减少集成失败带来的返工痛苦。D.更换ScrumMaster，因为他没能管理好团队情绪。答案：B,C解析：团队士气低落通常源于：频繁失败（集成问题）、无休止的变更、感到无力（无法承诺）。A（团建）虽然有助于增进感情，但如果不解决根本的工作痛点，团建只是暂时的止痛药。D（换人）通常不是首选，除非ScrumMaster严重失职。B正确：建立清晰的DoD和严格的优先级管理，可以减少“做无用功”和“半路插队”的情况，给团队一种稳定感和掌控感。C正确：技术债务和集成痛苦是敏捷团队士气的杀手。引入CI/CD和自动化测试，可以让集成问题尽早发现，减少手动返工，提高开发效率。当技术工具顺滑时，团队成员会更快乐。第四部分：计算与逻辑分析题21.某敏捷团队正在使用燃尽图来跟踪Sprint进度。Sprint长度为10天。在第5天结束时，理想燃尽图显示剩余工作应为20点，但实际燃尽图显示剩余工作为30点。作为ScrumMaster，你如何解读这个数据？A.团队落后于进度，需要采取纠正措施。B.团队超前于进度。C.团队进度正好。D.数据不足，无法判断，因为不知道团队的总速度。答案：A解析：燃尽图用于跟踪剩余工作量。Sprint一半时间过去了（第5天），理想情况下应该完成一半的工作（剩余20点）。实际上剩余30点，说明团队完成的工作量少于预期。即：原计划应完成（Total-20），实际只完成了（Total-30）。显然（Total-30）<（Total-20）。所以团队落后了。ScrumMaster应与团队沟通，了解是否遇到了障碍，或者是否需要调整范围（如与PO协商降低本Sprint目标）。22.团队在过去的5个Sprint中完成的故事点数分别为：21,24,23,25,22。产品待办列表中剩余的待办事项总估算值为150点。如果团队保持这种绩效水平，大约还需要多少个Sprint才能完成剩余工作？A.5个B.6个C.7个D.8个答案：C解析：首先计算平均速度：(21+24+23+25+22)/5=115/5=23点/Sprint。剩余工作量=150点。所需Sprint数=剩余工作量/平均速度=150/23≈6.52。Sprint必须是整数，且不能部分完成（除非是最后一个Sprin