2026年项目管理敏捷开发团队评估试卷及答案

2026年项目管理敏捷开发团队评估试卷及答案一、选择题（每题2分，共30分）1.以下哪项不是敏捷宣言的四大价值观？A.个体和互动高于流程和工具B.工作的软件高于详尽的文档C.客户合作高于合同谈判D.遵循计划高于响应变化2.在Scrum框架中，以下哪个角色负责确保团队遵循Scrum规则？A.产品负责人B.ScrumMasterC.开发团队成员D.项目经理3.在敏捷开发中，"用户故事"的主要目的是什么？A.提供详细的技术规范B.从用户角度描述功能需求C.替代传统的需求文档D.定义系统的非功能性需求4.以下哪项是Scrum事件中时间固定的？A.Sprint计划会议B.Sprint评审会议C.Sprint回顾会议D.DailyScrum5.在敏捷开发中，"技术债"指的是什么？A.项目中未偿还的技术投资B.团队成员的债务C.项目预算超支D.客户欠款6.看板方法的核心原则不包括以下哪项？A.可视化工作流B.限制在制品C.管理流动D.固定时间盒7.在Scrum中，Sprint的长度通常为：A.1-2周B.2-4周C.1个月D.3个月8.以下哪项不是XP（极限编程）的核心实践？A.结对编程B.持续集成C.代码审查D.详细的前期规划9.燃尽图主要用于：A.跟踪项目进度B.记录团队会议C.管理客户关系D.评估团队成员绩效10.在敏捷团队中，谁负责确定产品待办列表的优先级？A.ScrumMasterB.开发团队C.产品负责人D.项目经理11.以下哪项不属于敏捷开发的12条原则？A.满意客户通过早期和持续交付有价值的软件B.即使在项目后期也需求变更C.频繁交付可工作的软件D.业务人员与开发人员必须天天在一起工作12.在敏捷开发中，"持续集成"的主要目的是：A.确保团队成员随时可以工作B.尽早发现和解决集成问题C.减少代码审查的工作量D.提高团队士气13.以下哪项是敏捷团队规模的最佳实践？A.越大越好，可以并行更多任务B.越小越好，便于沟通C.7-9人D.15-20人14.在敏捷开发中，"待办列表细化"的主要目的是：A.延迟决策B.提高需求确定性C.减少Sprint计划会议时间D.排除变更15.以下哪项不是敏捷开发中常见的估算技术？A.故事点B.T恤尺码C.专家判断D.关键路径法二、填空题（每题2分，共20分）1.敏捷宣言于______年发布，由17位软件开发领域的专家共同撰写。2.在Scrum框架中，______是指尚未被分解为用户故事的产品待办列表项。3.敏捷开发强调"______胜过详尽的文档"。4.在敏捷开发中，______是一种用来估算相对工作量的技术，通常使用斐波那契数列。5.在看板方法中，______是指限制在制品的数量，以促进流动。6.在敏捷开发中，______是指开发团队集体拥有代码和责任的做法。7.Scrum框架中的三个角色是：产品负责人、ScrumMaster和______。8.在敏捷开发中，______是一种技术，通过将大型用户故事分解为更小的、可管理的部分。9.燃尽图显示的是______与剩余工作的关系。10.在敏捷开发中，______是一种实践，团队成员定期共享进展和挑战。三、判断题（每题2分，共20分）1.敏捷开发适用于所有类型的项目。（）2.在Scrum中，Sprint一旦开始就不能修改。（）3.敏捷开发强调文档的编写和维护。（）4.在敏捷团队中，ScrumMaster是团队的管理者。（）5.敏捷开发鼓励频繁交付可工作的软件增量。（）6.在敏捷开发中，需求一旦确定就不能变更。（）7.看板方法使用固定的时间盒来管理工作。（）8.在敏捷开发中，测试通常是在开发完成后进行的。（）9.敏捷开发强调团队的自组织和自管理。（）10.在敏捷开发中，客户参与仅限于项目开始和结束阶段。（）四、简答题（每题10分，共20分）1.请简述敏捷宣言的四大价值观和十二条原则，并解释它们对敏捷团队的意义。2.请详细说明Scrum框架中的五个事件（Sprint、Sprint计划会议、每日站会、Sprint评审会议、Sprint回顾会议）及其目的。五、论述题（每题10分，共10分）1.请论述敏捷开发在大型复杂项目中的应用挑战及应对策略，并结合实际案例进行分析。参考答案：一、选择题（每题2分，共30分）1.D.解析：敏捷宣言的四大价值观是：个体和互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。选项D不属于这四大价值观之一，而是与之相反的观点。2.B.解析：在Scrum框架中，ScrumMaster负责确保团队遵循Scrum规则，移除障碍，促进Scrum事件的有效进行，但不是团队的管理者。产品负责人负责管理产品待办列表和最大化产品价值，开发团队成员负责交付产品增量，传统意义上的项目经理角色在Scrum中被分散到ScrumMaster和产品负责人身上。3.B.解析：用户故事的主要目的是从用户角度描述功能需求，帮助团队理解用户需求和期望。它不是提供详细的技术规范，也不是要替代传统的需求文档，而是以一种简洁、易于理解的方式表达需求。4.D.解析：在Scrum事件中，DailyScrum（每日站会）是时间固定的，通常为15分钟。Sprint计划会议通常为8小时（对于一个月的Sprint）或更短，Sprint评审会议通常为4小时，Sprint回顾会议通常为3小时，这些时间会根据Sprint长度调整。5.A.解析：技术债是指在软件开发过程中，为了快速交付功能而采取的简化设计、减少测试或文档编写等做法，这些简化会在未来需要"偿还"，即进行额外的重构、测试或文档编写工作。它不是指团队成员的债务、项目预算超支或客户欠款。6.D.解析：看板方法的核心原则包括：可视化工作流、限制在制品、管理流动、明确政策、建立反馈循环、协作改进。固定时间盒是Scrum的特征，不是看板方法的核心原则。7.B.解析：在Scrum中，Sprint的长度通常为2-4周，具体长度由团队根据项目特点和业务需求决定，但一旦确定，在同一个项目中应保持固定。8.D.解析：XP（极限编程）的核心实践包括：结对编程、测试驱动开发、持续集成、重构、简单设计、代码集体所有权、编码标准、小批量发布、系统隐喻、每周40小时、现场客户、规划游戏。详细的前期规划不是XP的核心实践，XP更强调迭代和适应性规划。9.A.解析：燃尽图是一种图表，用于跟踪项目进度，显示已完成的工作和剩余工作之间的关系，帮助团队了解项目是否按计划进行。它不用于记录团队会议、管理客户关系或评估团队成员绩效。10.C.解析：在敏捷团队中，产品负责人负责确定产品待办列表的优先级，确保团队始终专注于最有价值的工作。ScrumMaster负责确保Scrum框架的正确实施，开发团队成员负责实现产品增量，项目经理角色在Scrum中被分散。11.B.解析：敏捷开发的12条原则包括：满足客户通过早期和持续交付有价值的软件、欢迎需求变更即使在项目后期、频繁交付可工作的软件、业务人员与开发人员必须天天在一起工作、激励个体给予所需环境和支持、面对面沟通、工作的软件是进度的主要度量、可持续的开发速度、持续关注技术卓越和良好设计、简洁是根本、自组织团队、定期反思如何提高效率。选项B"即使在项目后期也需求变更"表述不准确，应该是"欢迎需求变更即使在项目后期"。12.B.解析：持续集成是一种开发实践，要求团队成员频繁地（通常每天多次）将代码集成到共享主干中，每次集成后都会自动构建和测试，目的是尽早发现和解决集成问题，提高代码质量和开发效率。它不是确保团队成员随时可以工作、减少代码审查的工作量或提高团队士气。13.C.解析：敏捷团队规模的最佳实践是7-9人，这个规模足够小以促进有效沟通，又足够大以完成复杂任务。研究表明，超过9人的团队沟通成本会显著增加，效率反而下降。14.C.解析：待办列表细化的主要目的是提高用户故事的清晰度和可理解性，确保开发团队在Sprint计划会议中能够准确估算工作量，从而减少Sprint计划会议时间。它不是延迟决策、提高需求确定性或排除变更。15.D.解析：敏捷开发中常见的估算技术包括故事点、T恤尺码、专家判断、计划扑克等。关键路径法是传统项目管理中的估算技术，不适用于敏捷开发。二、填空题（每题2分，共20分）1.2001年。解析：敏捷宣言于2001年2月由17位软件开发领域的专家在美国犹他州雪鸟滑雪胜地共同撰写，标志着敏捷软件开发方法的正式诞生。2.产品待办列表项。解析：在Scrum框架中，产品待办列表项是指尚未被分解为用户故事的产品待办列表中的元素，可能是高层次的功能、需求或问题，需要进一步细化才能纳入Sprint。3.工作的软件。解析：敏捷宣言强调"工作的软件胜过详尽的文档"，这意味着交付可工作的软件是最重要的，文档是必要的但不应该成为阻碍交付软件的障碍。4.故事点。解析：故事点是敏捷开发中用来估算相对工作量的技术，通常使用斐波那契数列（1,2,3,5,8,13...）来表示，因为它反映了随着复杂度增加，工作量呈非线性增长的特点。5.限制在制品。解析：在看板方法中，限制在制品（WIP）是指限制在任何给定时间点正在进行的工作项数量，这有助于减少多任务处理，提高流动效率，及早发现问题。6.代码集体所有权。解析：在敏捷开发中，代码集体所有权是指开发团队成员共同拥有和负责项目代码的做法，任何团队成员都可以修改任何代码部分，这促进了知识共享和团队协作。7.开发团队。解析：Scrum框架中的三个角色是：产品负责人（负责最大化产品价值）、ScrumMaster（确保Scrum框架的正确实施）和开发团队（负责交付产品增量）。8.用户故事分解。解析：在敏捷开发中，用户故事分解是一种技术，通过将大型用户故事（史诗）分解为更小的、可管理的部分，使其能够在单个Sprint内完成，提高估算的准确性和交付的灵活性。9.时间。解析：燃尽图显示的是时间与剩余工作的关系，通常横轴表示时间（如Sprint的天数），纵轴表示剩余的工作量（如故事点或任务小时数），帮助团队了解项目进度是否按计划进行。10.每日站会。解析：在敏捷开发中，每日站会是一种实践，团队成员每天固定时间（通常15分钟）简短分享进展、计划和挑战，确保团队成员保持同步，及时解决问题。三、判断题（每题2分，共20分）1.错误。解析：敏捷开发适用于需求不稳定、需要快速响应变化的项目，对于需求非常稳定、明确的项目，传统瀑布模型可能更合适。敏捷开发不适用于所有类型的项目。2.正确。解析：在Scrum中，Sprint一旦开始就不能修改其长度或目标，这是Scrum框架的一个核心原则，确保团队有稳定的环境来完成承诺的工作。如果需要调整，可以在Sprint评审会议和Sprint回顾会议后，在下一个Sprint中调整。3.错误。解析：敏捷宣言强调"工作的软件胜过详尽的文档"，但这并不意味着完全不需要文档，而是文档应该服务于交付软件的目的，不应该成为阻碍交付的障碍。敏捷开发重视必要的文档，但反对过度文档化。4.错误。解析：在敏捷团队中，ScrumMaster不是团队的管理者，而是Scrum框架的促进者和团队的教练，负责确保团队遵循Scrum规则，移除障碍，促进自组织和自管理。5.正确。解析：敏捷开发强调频繁交付可工作的软件增量，通常每个Sprint结束时都应该交付一个可工作的、潜在可发布的软件增量，这有助于早期获得反馈，降低风险。6.错误。解析：敏捷开发欢迎需求变更，即使在项目后期，这也是敏捷宣言的核心价值观之一。敏捷团队应该能够灵活应对需求变化，而不是抵制变更。7.错误。解析：看板方法不使用固定的时间盒来管理工作，而是基于拉动系统，当上游工作完成时，下游工作才开始。看板关注的是流动效率，而不是固定的时间周期。8.错误。解析：在敏捷开发中，测试通常是与开发并行进行的，甚至是先于开发（测试驱动开发），而不是在开发完成后才进行。敏捷开发强调持续测试和质量内建。9.正确。解析：敏捷开发强调团队的自组织和自管理，团队成员共同决定如何完成工作，而不是由外部管理者指挥。这有助于提高团队的积极性和创造力。10.错误。解析：在敏捷开发中，客户应该全程参与项目，而不是仅限于开始和结束阶段。客户参与包括需求澄清、优先级排序、评审增量等，这有助于确保产品满足客户需求。四、简答题（每题10分，共20分）1.敏捷宣言的四大价值观是：-个体和互动高于流程和工具-工作的软件高于详尽的文档-客户合作高于合同谈判-响应变化高于遵循计划敏捷宣言的十二条原则是：-满足客户通过早期和持续交付有价值的软件-欢迎需求变更即使在项目后期-频繁交付可工作的软件-业务人员与开发人员必须天天在一起工作-激励个体给予所需环境和支持-面对面沟通-工作的软件是进度的主要度量-可持续的开发速度-持续关注技术卓越和良好设计-简洁是根本-自组织团队-定期反思如何提高效率这些价值观和原则对敏捷团队的意义在于：-强调人的因素胜过过程和工具，认识到软件开发是人的创造性活动-强调交付实际价值而非文档，确保团队专注于真正重要的工作-强调与客户的持续合作，确保产品满足客户需求-强调适应变化而非僵化计划，使团队能够应对不确定性-提供了指导敏捷实践的具体原则，帮助团队做出正确的决策-创建了一个以客户为中心、注重质量、强调协作和持续改进的开发环境2.Scrum框架中的五个事件及其目的：a)Sprint：Scrum的核心，是一个时间盒（通常为2-4周）的迭代周期，团队在此期间完成一个可工作的产品增量。Sprint的长度在整个项目中保持固定，一旦开始就不能被延长。Sprint的目标是提供一个可预测的节奏，使团队能够定期交付价值。b)Sprint计划会议：在每个Sprint开始时举行，团队确定Sprint的目标和要完成的产品待办列表项。会议通常分为两部分：第一部分讨论"什么"（确定Sprint目标），第二部分讨论"如何"（选择产品待办列表项并制定计划）。目的是确保团队对Sprint目标有清晰的理解，并制定可行的计划。c)每日站会（DailyScrum）：每个工作日举行的15分钟会议，团队成员同步进展、计划和障碍。团队成员回答三个问题：昨天完成了什么？今天计划完成什么？遇到了什么障碍？目的是促进团队沟通，及时识别和解决问题，保持团队聚焦于Sprint目标。d)Sprint评审会议：在每个Sprint结束时举行，团队向利益相关者展示已完成的产品增量，收集反馈。利益相关者提供反馈，团队讨论下一步工作。目的是获取反馈，调整产品待办列表，确保产品满足客户需求。e)Sprint回顾会议：在每个Sprint结束后举行，团队反思Sprint过程，识别改进点，并制定改进计划。会议通常包括三个部分：检查数据、生成见解、决定行动。目的是促进团队持续改进，提高团队效能和产品质量。五、论述题（每题10分，共10分）1.敏捷开发在大型复杂项目中的应用挑战及应对策略：挑战一：协调多个团队大型复杂项目通常涉及多个团队同时工作，如何有效协调这些团队是一个重大挑战。团队之间可能存在依赖关系，信息同步困难，导致效率低下。应对策略：-实施LeSS（大规模Scrum）或SAFe（规模化敏捷框架）等敏捷规模化框架，为多个团队提供统一的协调机制-建立团队间的定期同步会议，如跨团队Sprint计划会议和集成会议-使用可视化工具（如大图看板）跟踪跨团队依赖关系-指定专门的协调角色，如ScrumofScrumsMaster，负责解决跨团队问题挑战二：需求管理复杂性大型项目通常有大量需求和功能点，需求之间的复杂关系和依赖关系难以管理。应对策略：-建立分层的产品待办列表，将需求分为史诗、特性、用户故事等不同层次-使用领域驱动设计（DDD）等技术来划分限界上下文，减少需求间的耦合-实施需求分层规划，高