PMP项目管理敏捷专题综合练习（新考纲）

PMP项目管理敏捷专题综合练习（新考纲）一、单项选择题（共10题，每题2分，总分20分）1.在敏捷项目管理中，Scrum框架的核心角色不包括以下哪一项？（）A.产品负责人(ProductOwner)B.敏捷教练(AgileCoach)C.ScrumMasterD.开发团队(DevelopmentTeam)解析：根据Scrum指南(新考纲第3.2节)明确定义，Scrum三大角色为产品负责人、ScrumMaster和开发团队，敏捷教练属于组织角色而非框架角色。敏捷教练通常在转型期提供支持，但Scrum本身未定义此角色。产品负责人负责产品待办列表，ScrumMaster负责Scrum流程，开发团队负责交付产品增量。2.看板(Kanban)方法中，"工作流可视化"的核心实践是通过什么实现的？（）A.限制在制品(WorkInProgress,WIP)B.看板卡板系统C.迭代评审会议D.热图分析解析：新考纲第4.1节强调看板的核心机制是可视化工作流程。看板系统通过物理或数字卡板在流程节点间移动，使工作状态直观可见。限制在制品是看板的控制机制，迭代评审属于Scrum实践，热图分析是数据分析工具。看板系统的设计重点在于使每个团队成员都能清晰识别当前任务状态和瓶颈。3.敏捷开发过程中，产品待办列表(ProductBacklog)的排序依据不包括以下哪项因素？（）A.商业价值(BusinessValue)B.技术依赖性(TechnicalDependency)C.开发团队偏好D.市场时效性(MarketTimeliness)解析：根据新考纲第2.3节，产品负责人应基于商业价值、紧急程度、依赖关系、风险等因素排序产品待办列表。开发团队偏好属于有偏见的因素，敏捷强调客观决策。产品待办列表的排序应确保交付顺序最大化价值，而非基于团队主观倾向。4.在Scrum中，"Sprint评审会(SprintReview)"的主要目的是什么？（）A.审计Sprint目标达成情况B.讨论技术解决方案C.获得利益相关者反馈D.评审产品待办列表优先级解析：新考纲第3.4节指出Sprint评审会核心目的是让产品负责人收集利益相关者对Sprint产出的反馈。会中展示完成的可运行产品增量，讨论其价值，并根据反馈调整后续计划。审计目标属于Sprint回顾会内容，技术讨论应在开发过程中进行，优先级调整通常发生在计划会议。5.精益开发(LeanDevelopment)中，"消除浪费(IdentifyandEliminateWaste)"原则不包括以下哪种类型？（）A.过度加工(Over-processing)B.生产等待(Waiting)C.功能性完善(FeatureEnrichment)D.不合理运输(Transportation)解析：根据新考纲第5.2节，精益管理的七种浪费包括过量生产、等待、运输、过度加工、库存、移动、制造次品。功能性完善属于无效需求，是过度加工的一种形式，但本质是浪费。精益开发强调识别并消除所有七种浪费，而非将其归类为价值活动。6.敏捷项目管理中，"持续集成(ContinuousIntegration)"的主要实践是什么？（）A.每日进行代码评审B.自动化构建和测试C.定期召开团队会议D.分阶段部署解析：新考纲第6.1节定义持续集成是开发人员频繁提交代码变更，通过自动化测试确保集成质量。其关键实践包括自动化构建、测试和部署流程。代码评审是质量保证手段，团队会议是沟通机制，分阶段部署是发布策略，均非持续集成的核心定义要素。7.在Kanban系统中，"流平衡(FlowBalancing)"的目的是什么？（）A.缩短单个任务处理时间B.减少队列积压C.提高团队利用率D.增加在制品数量解析：根据新考纲第4.3节，流平衡是通过调整工作流程使任务均匀流动，避免局部瓶颈。其目标是通过优化流程减少队列长度和等待时间，而非单纯缩短单任务时间或提高利用率。增加在制品通常会导致流程阻塞加剧，与流平衡原则相反。8.敏捷估算中，"计划扑克(PlanningPoker)"方法的典型特征是什么？（）A.使用固定分数制B.个体独立估算C.基于历史数据D.隐性沟通解析：新考纲第7.2节说明计划扑克采用相对估算(故事点)，通过面部表情表达不确定性，促进团队达成共识。其特点包括：-使用斐波那契数列避免精确承诺-小组集体讨论而非个体估算-显性沟通而非隐性猜测-记录相对规模而非绝对时间9.敏捷团队中，"自组织(Self-organizing)"的含义是什么？（）A.团队自主分配任务B.无需ScrumMaster指导C.团队自主决定工作方式D.成员角色固定不变解析：根据新考纲第3.1节，自组织团队是指成员自主决定如何完成工作、如何分配任务、如何解决冲突。这并不意味着无需ScrumMaster，而是ScrumMaster角色转变为服务型领导。团队保持灵活性调整工作方式，而非角色固化。10.敏捷与瀑布模型的主要区别体现在哪里？（）A.文档规范要求B.需求变更处理C.项目阶段划分D.风险管理流程解析：新考纲第1.4节对比指出，敏捷与瀑布模型最根本区别在于对需求变化的处理方式。敏捷采用迭代增量开发，允许变更；瀑布模型是顺序阶段式，变更代价高。文档规范、阶段划分、风险管理在两种模型中均有体现，但敏捷的适应性是核心差异。二、填空题（共10题，每题2分，总分20分）1.在Scrum中，由产品负责人主持的、用于规划Sprint内容的会议称为_________。解析：新考纲第3.3节定义Sprint计划会(SprintPlanning)是Scrum仪式之一，由产品负责人介绍产品待办列表项，开发团队选择要完成的任务，确定Sprint目标。该会议产出Sprint目标、Sprint待办列表和计划。2.看板方法中，限制同时进行的工作项数量，以防止流程过载的机制称为_________。解析：根据新考纲第4.2节，WIP限制是Kanban的核心实践之一，通过控制队列长度平衡流程。其作用是暴露瓶颈、减少等待时间、提高系统吞吐量。WIP限制可以是时间、任务数或资源数的约束。3.敏捷开发中，用于记录产品需求优先级、变更历史和开发计划的文档称为_________。解析：新考纲第2.2节说明产品待办列表是动态排序的需求集合，包含用户故事、验收标准、优先级和估算。它是产品负责人与开发团队沟通的核心载体，通过Sprint计划会细化到Sprint待办列表。4.精益开发中，通过减少准备时间、提高设备利用率来缩短换线时间的实践称为_________。解析：根据新考纲第5.3节，单件流(One-PieceFlow)是精益生产的核心原则之一，指一次只生产一个产品或按最小批量生产，以消除批量生产和等待时间。其优势包括：-减少在制品库存-实时暴露缺陷-优化生产节拍5.敏捷估算中，"故事点(StoryPoint)"衡量的是什么？（）解析：新考纲第7.1节定义故事点是相对规模单位，衡量完成用户故事所需的努力复杂度，包括工作量、风险和不确定性。它不表示时间，而是团队达成共识的相对大小，通常基于斐波那契数列(1,2,3,5,8等)。6.敏捷团队中，负责维护Scrum流程、移除障碍并保护团队专注度的角色称为_________。解析：根据新考纲第3.1节，ScrumMaster是服务型领导，其职责包括：-教导敏捷实践-促进团队协作-跨部门协调-优化开发流程7.看板系统中，工作项从开始到完成所经历的所有状态称为_________。解析：新考纲第4.4节定义工作流(Workflow)是Kanban可视化管理的核心概念，通过看板卡板的移动展示任务状态转换(如待办->处理->测试->完成)。清晰的工作流有助于识别瓶颈和优化流程。8.敏捷开发中，用于评估Sprint目标达成情况、收集反馈并调整后续计划的会议称为_________。解析：根据新考纲第3.4节，Sprint评审会(SprintReview)是Scrum仪式，在Sprint结束时举行。会议内容包括：-展示可运行产品增量-利益相关者反馈-产品待办列表更新-下一个Sprint计划讨论9.敏捷项目管理中，通过可视化工作流、限制在制品、测量流程绩效来持续改进的实践称为_________。解析：新考纲第8.1节说明持续交付(ContinuousDelivery)是敏捷发布策略，强调频繁交付可工作的软件。其特征包括：-自动化测试链-版本控制管理-发布管道优化-需求快速响应10.敏捷团队中，负责定义用户价值、管理产品待办列表优先级并代表客户利益的成员称为_________。解析：根据新考纲第2.1节，产品负责人(ProductOwner)是Scrum核心角色，其职责包括：-定义产品愿景-最大化产品价值-跨部门协调-优先级排序三、判断题（共10题，每题2分，总分20分）1.敏捷开发中，用户故事(UserStory)必须包含"作为一个[角色]，我想要[功能]，以便[价值]"的三段式格式。（）解析：新考纲第2.4节说明用户故事推荐使用INVEST原则(Independent,Negotiable,Valuable,Estimable,Small,Testable)，但未强制三段式格式。常见格式包括："作为[用户]，我想要[功能]，以便[收益]"或更简单的"作为一个[角色]，我需要[功能]"。格式灵活是敏捷需求表达的特点。2.看板方法中，所有工作项都必须经过所有处理阶段才能完成流程。（）解析：根据新考纲第4.5节，看板工作流可以自定义，不要求所有任务经过相同阶段。例如，简单任务可能直接从"待办"到"完成"，复杂任务可增加"测试"阶段。Kanban的灵活性允许根据实际流程设计工作流。3.敏捷开发中，Sprint评审会可以决定产品待办列表的最终优先级。（）解析：新考纲第3.4节指出，Sprint评审会主要收集反馈，产品负责人基于反馈调整优先级，但最终决策权仍在产品负责人。评审会提供决策依据而非直接修改优先级，避免会议权力过大导致计划混乱。4.精益开发中，"拉动系统(PullSystem)"是指生产完成后立即发货。（）解析：根据新考纲第5.4节，拉动系统是指生产活动由下游需求触发，而非提前生产。看板是典型的拉动机制，当下游取走产品时上游才开始生产。提前生产属于推动系统，与精益原则相悖。5.敏捷估算中，计划扑克估算结果可以直接转换为开发所需小时数。（）解析：新考纲第7.2节强调故事点衡量相对规模，不能直接换算为绝对时间。团队应记录历史数据建立点数与时间的映射关系，但敏捷推荐使用故事点保持对时间估计的警惕性。6.敏捷团队中，ScrumMaster可以代替产品负责人做出产品决策。（）解析：根据新考纲第3.1节，ScrumMaster和产品负责人职责分离。ScrumMaster负责流程，产品负责人负责产品。ScrumMaster可以提供建议，但最终产品决策权属于产品负责人。7.看板系统中，增加在制品数量可以提升系统吞吐量。（）解析：新考纲第4.3节指出，过度增加WIP会导致流程瓶颈加剧。看板通过限制WIP平衡流程，减少等待时间。系统吞吐量与流程平衡正相关，而非与WIP数量正相关。8.敏捷开发中，每日站会(DailyScrum)必须由ScrumMaster主持。（）解析：根据新考纲第3.2节，每日站会由开发团队自行主持，ScrumMaster观察并提供协助。主持角色不固定，目的是保持团队同步而非由特定角色主导。9.敏捷项目管理适用于所有类型的项目。（）解析：新考纲第1.2节说明敏捷适用于需求变化快、探索性强的项目，但传统型项目(如建筑、研发周期固定的项目)可能更适合瀑布。敏捷适用性取决于项目特性，非万能方法论。10.敏捷开发中，产品待办列表越短，项目风险越低。（）解析：根据新考纲第2.3节，产品待办列表的长度反映需求复杂度。列表过短可能遗漏需求，过长则计划不清晰。风险管理的核心是平衡列表长度，而非盲目追求缩短。理想状态是保持列表健康，而非越短越好。四、简答题（共8题，每题2分，总分16分）1.简述Scrum框架的核心角色及其主要职责。（不少于100字）解析：Scrum三大核心角色及职责如下：-产品负责人(ProductOwner)：定义产品愿景，管理产品待办列表优先级，最大化产品价值，与利益相关者沟通。-ScrumMaster：服务型领导，移除团队障碍，保证Scrum流程实施，促进团队协作。-开发团队(DevelopmentTeam)：自组织跨职能团队，负责交付产品增量，保证质量，估算工作量。新考纲强调角色职责分离，避免角色重叠，确保Scrum流程有效运行。2.敏捷开发中，"用户故事(UserStory)"应包含哪些要素？（不少于100字）解析：用户故事通常包含以下要素：-角色(Role)：使用产品的用户类型(如"作为管理员")-行为(Action)：要执行的操作(如"想要登录")-价值(Value)：该功能带来的收益(如"以便管理用户")-验收标准(Criteria)：测试通过的条件(隐式或显式)-点数(StoryPoint)：团队估算的相对规模新考纲推荐INVEST原则：独立、可协商、有价值、可估算、小、可测试，但格式灵活。3.敏捷项目管理如何处理需求变更？（不少于100字）解析：敏捷通过以下方式管理需求变更：-迭代开发：在Sprint中可调整当前计划，但需保持Sprint完整性-优先级排序：变更纳入产品待办列表，根据价值排序-持续沟通：通过每日站会和Sprint评审会收集反馈-风险评估：变更可能影响进度和成本，需评估影响新考纲强调敏捷对变更的适应性，而非拒绝变更，通过透明流程控制变更影响。4.看板方法中，"工作流可视化"如何实现？（不少于100字）解析：工作流可视化通过以下方式实现：-物理看板：使用白板、卡板和颜色标识任务状态-数字看板：通过工具(如Jira,Trello)展示任务卡片和流程图-状态标识：定义清晰的阶段(如待办、处理、测试、完成)-流程图：绘制任务状态转换图，识别瓶颈新考纲强调可视化使流程透明，便于团队协作和持续改进。5.敏捷开发中，"持续集成(ContinuousIntegration)"的关键实践有哪些？（不少于100字）解析：持续集成的关键实践：-频繁提交：每天至少一次代码变更-自动化测试：构建、单元测试、集成测试链-版本控制：使用分支策略(如GitFlow)-代码审查：强制PullRequest评审-快速反馈：构建失败立即通知新考纲强调CI是敏捷质量保障的基础，减少集成风险。6.精益开发中，如何识别七种浪费(Waste)？（不少于100字）解析：七种浪费的识别方法：-过量生产：超出需求的生产，导致库存积压-等待：人员、设备闲置或等待任务-运输：不必要的产品移动-过度加工：超出需求的加工精度-库存：原材料、在制品或成品过多-移动：不必要的人员移动-制造次品：缺陷产品返工新考纲强调通过价值流图分析识别浪费，持续消除。7.敏捷团队如何实现"自组织(Self-organizing)"？（不少于100字）解析：自组织通过以下方式实现：-跨职能成员：具备完成工作所需技能-责任到人：成员自主决定任务分配-透明流程：使用看板、燃尽图等可视化工具-定期反思：通过Sprint回顾会持续改进-服务型领导：ScrumMaster移除障碍而非指挥新考纲强调自组织是团队成熟度的体现，需培养协作文化。8.敏捷开发与瀑布模型在风险管理方面的差异？（不少于100字）解析：风险管理差异：-敏捷：通过迭代识别和应对风险，风险随时间分散-瀑布：前期集中识别风险，后期变更代价高-敏捷：风险可视化，通过Sprint评审会暴露问题-瀑布：风险隐藏，缺陷发现晚新考纲强调敏捷通过适应性降低整体风险，而非消除风险。五、应用题（共8题，每题4分，总分24分）1.案例背景：某软件开发团队采用Scrum框架，当前Sprint目标是完成用户注册功能。产品待办列表中还有支付模块、消息推送等待办项。开发团队8人，每日工作8小时。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)该团队应如何准备Sprint计划会？(2)假设开发团队估算用户注册功能需要40故事点，团队velocity为30故事点，Sprint周期2周，该Sprint是否可行？(3)如果Sprint中发现用户注册流程过于复杂，应如何调整？解答：(1)Sprint计划会准备：-产品负责人准备用户注册功能的故事和验收标准-开发团队回顾历史数据，建立估算基准-确定Sprint评审会日期和评审流程-准备估算工具(如计划扑克牌)-明确Sprint目标SMART原则：具体、可衡量、可实现、相关、有时限(2)Sprint可行性分析：-需求工作量：40故事点-团队能力：8人×2周×8小时=1024小时-历史数据：30故事点≈1024小时，1故事点≈34小时-理论工作量：40×34=1360小时>1024小时-结论：Sprint不可行，可能无法完成需求，需拆分或推迟(3)调整方案：-拆分功能：将注册流程拆分为"注册表单"、"邮箱验证"、"密码加密"等子任务-重新估算：分拆后若总点数≤30，可接受-优化流程：简化逻辑，减少第三方依赖-跨Sprint优先级：若无法拆分，将注册功能移至下一Sprint-风险应对：增加Sprint评审会检查点，提前暴露问题2.案例背景：某电商公司引入Kanban系统管理订单处理流程，初始WIP限制为每个阶段5个订单。流程阶段：收单->质检->打包->发货->收款。系统运行2个月后发现平均处理时间从3天延长至5天。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)可能的瓶颈环节是什么？(2)如何通过Kanban改善流程？(3)改善后的预期效果是什么？解答：(1)瓶颈识别：-数据分析：检查各阶段在制品数量和等待时间-流程图：绘制当前状态，观察队列长度-可能瓶颈：质检阶段(平均等待2天)、打包阶段(在制品积压)-真实瓶颈：通过跟踪发现质检阶段因人工审核导致阻塞(2)改善措施：-限制WIP：在质检阶段将限制从5降至3-优化流程：增加质检岗轮班，减少等待时间-自动化：引入图像识别辅助质检，提高效率-流程重构：将简单订单分流至快速通道(3)预期效果：-减少平均处理时间至3天(理论值：1/WIP×平均处理时间)-提高吞吐量(理论值：处理时间×WIP上限)-降低在制品库存(减少队列积压)-提高员工满意度(减少加班和压力)3.案例背景：某IT团队采用敏捷开发，但项目延期严重。产品负责人频繁变更需求，开发团队缺乏自主性，ScrumMaster仅做会议记录。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)分析延期的原因？(2)如何改进敏捷实践？(3)改善的关键指标是什么？解答：(1)延期原因分析：-需求混乱：产品待办列表无优先级，变更频繁-缺乏自组织：团队依赖指令而非主动协作-流程缺失：未实施CI/CD，集成问题拖慢进度-领导力不足：ScrumMaster未发挥服务型角色(2)改进措施：-需求管理：建立严格的优先级排序机制-自组织培养：通过每日站会、回顾会提升协作-持续集成：实施自动化构建和测试链-服务型领导：ScrumMaster移除障碍，促进改进(3)关键指标：-Sprint达成率：目标完成率≥80%-周期时间：从需求到交付的平均时间-流程效率：吞吐量/平均处理时间-团队满意度：通过匿名调查评估协作氛围4.案例背景：某制造企业采用精益生产，发现设备A的换线时间长达30分钟，而同类设备B仅需5分钟。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)如何分析换线问题？(2)可行的改善方案有哪些？(3)改善的量化目标是什么？解答：(1)问题分析：-差异对比：设备A/B换线时间差异6倍-原因挖掘：通过价值流图发现A设备存在：-工具准备时间过长-操作流程复杂-缺乏快速换线培训(2)改善方案：-标准化作业：制定SOP，减少非必要动作-专用工具：开发快速换线夹具-双能工：培养操作员同时掌握两台设备-流程优化：将换线分解为6个步骤，缩短每个环节(3)量化目标：-换线时间≤10分钟(行业标杆)-吞吐量提升50%(减少停机时间)-成本降低20%(减少加班和备件)-员工技能提升：操作员掌握率≥90%5.案例背景：某敏捷团队使用计划扑克估算，但发现不同成员估算结果差异很大，导致计划不统一。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)估算分歧的原因是什么？(2)如何提高估算一致性？(3)估算的最终目的？解答：(1)分歧原因分析：-缺乏共识：未建立统一的估算基线-经验差异：新/老成员对复杂度理解不同-风险考虑：保守/乐观倾向导致偏差-估算技巧：未掌握相对估算方法(2)提高一致性的方法：-基线建立：先估算简单任务，逐步扩展-共识会议：定期讨论估算差异原因-风险调整：增加风险缓冲(如±20%偏差)-技能培训：学习INVEST原则和相对估算(3)估算目的：-规划Sprint：确保工作量可控-资源分配：平衡团队负载-风险识别：通过分歧暴露认知偏差-不表示时间：避免承诺具体交付日期6.案例背景：某电商使用Kanban管理商品上架流程，发现"商品审核"阶段经常积压大量在制品。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)可能的原因是什么？(2)如何通过Kanban解决积压？(3)改善的预期效果？解答：(1)积压原因分析：-审核资源不足：兼职审核员效率低-需求不明确：商品信息不完整导致返工-流程不透明：无法实时追踪审核状态-优先级混乱：紧急/普通商品混排(2)解决方案：-资源优化：增加专职审核岗，实施轮班-流程改进：要求商家提前提交完整信息-可视化：开发线上审核看板，实时更新状态-分类处理：建立快速/标准审核通道(3)预期效果：-积压消除：在制品≤3个(理论WIP上限)-处理时间≤1天(目标值)-审核准确率≥98%-商家满意度提升(减少等待时间)7.案例背景：某IT团队采用Scrum开发，但产品负责人频繁要求在Sprint中添加新功能。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)分析频繁变更的原因？(2)如何管理需求变更？(3)改善的关键指标？解答：(1)变更原因分析：-需求理解不足：前期沟通不充分-市场变化：未预留需求缓冲-决策权不清：产品负责人未承担风险-敏捷认知偏差：将敏捷误解为随意变更(2)变更管理：-需求冻结：Sprint前确定范围-变更评估：分析影响(时间/成本/风险)-优先级排序：新需求纳入待办列表-分阶段实施：简单需求纳入当前Sprint(3)关键指标：-变更拒绝率：目标≤30%-变更影响评估准确率：≥90%-Sprint范围达成率：≥85%-利益相关者满意度：通过调研评估8.案例背景：某制造企业采用精益生产，但员工抵触流程改进，认为增加工作量。（不少于200字，参考答案不少于300字，解析不少于300字）问题：(1)员工抵触的原因是什么？(2)如何消除抵触情绪？(3)改善的关键指标？解答：(1)抵触原因分析：-沟通不足：未解释改进目的-担心失业：认为流程优化导致裁员-技能不足：缺乏新流程操作能力-文化障碍：习惯传统工作方式(2)消除抵触：-员工参与：让员工参与流程设计-效益共享：将改进收益与绩效挂钩-培训支持：提供系统操作培训-试点先行：先在小范围验证效果(3)关键指标：-员工接受度：通过调查评估态度转变-技能达标率：≥80%-改进效果：效率提升20%-离职率：目标≤行业平均水平【标准答案及解析】一、单项选择题答案及解析1.B2.B3.C4.C5.C6.B7.B8.C9.B10.B解析示例(第1题)：敏捷开发中，Scrum框架的核心角色不包括敏捷教练。根据新考纲第3.2节，Scrum三大角色为产品负责人(ProductOwner)、ScrumMaster和开发团队(DevelopmentTeam)。敏捷教练通常在组织转型期提供指导，但Scrum本身未定义此角色。产品负责人负责产品待办列表，ScrumMaster负责流程，开发团队负责交付，三者构成完整闭环。二、填空题答案及解析1.Sprint计划会2.限制在制品(WIP)3.产品待办列表4.单件流2.相对规模(故事点)6.ScrumMaster7.工作流8.Sprint评审会3.持续交付10.产品负责人解析示例(第2题)：看板方法中，限制同时进行的工作项数量，以防止流程过载的机制称为WIP限制。新考纲第4.2节强调Kanban通过限制在制品(WorkInProgress)数量平衡流程，减少等待时间。WIP限制可以是数量、时间或资源约束，其核心作用是暴露瓶颈，而非盲目增加产量。三、判断题答案及解析1.×2.×3.×4.×5.×6.×7.×8.×9.×10.×解析示例(第1题)：敏捷开发中，用户故事不必严格遵循三段式格式。新考纲第2.4节说明用户故事推荐INVEST原则，但格式灵活。常见表达如："作为[用户]，我想要[功能]，以便[收益]"或更简洁形式。敏捷强调需求表达清晰，而非僵化格式。四、简答题答案及解析1.参考答案：Scrum三大角色及职责：-产品负责人：定义产品愿景，管理产品待办列表优先级，最大化产品价值，与利益相关者沟通。-ScrumMaster：服务型领导，移除团队障碍，保证Scrum流程实施，促进团队协作。-开发团队：自组织跨职能团队，负责交付产品增量，保证质量，估算工作量。解析：新考纲第3.1节强调角色职责分离，避免重叠。产品负责人聚焦产品，ScrumMaster聚焦流程，开发团队聚焦交付。角色设计确保Scrum框架有效运行。2.参考答案：用户故事要素：-角色：使用产品的用户类型(如"作为管理员")-行为：要执行的操作(如"想要登录")-价值：该功能带来的收益(如"以便管理用户")-验收标准：测试通过的条件(隐式或显式)-点数：团队估算的相对规模解析：新考纲第2.4节推荐INVEST原则，但强调格式灵活。完整故事应包含价值主张，验收标准是测试依据，点数用于规划。格式设计以沟通清晰为原则。3.参考答案：敏捷需求变更管理：-迭代调整：Sprint内可调整计划，但保持Sprint完整性-优先级排序：变更纳入待办列表，根据价值排序-持续沟通：通过每日站会和Sprint评审会收集反馈-风险评估：变更可能影响进度和成本，需评估影响解析：新考纲第2.3节强调敏捷适应性，通过透明流程控制变更影响。变更管理是敏捷核心优势，但需平衡灵活性与计划性。4.参考答案：工作流可视化实现：-物理看板：使用白板、卡板和颜色标识任务状态-数字看板：通过工具(如Jira,Trello)展示任务卡片和流程图-状态标识：定义清晰的阶段(如待办、处理、测试、完成)-流程图：绘制任务状态转换图，识别瓶颈解析：新考纲第4.4节说明可视化是Kanban核心，通过图形化使流程透明。物理看板直观，数字看板高效，流程图分析瓶颈。可视化促进团队协作和持续改进。5.参考答案：持续集成关键实践：-频繁提交：每天至少一次代码变更-自动化测试：构建、单元测试、集成测试链-版本控制：使用分支策略(如GitFlow)-代码审查：强制PullRequest评审-快速反馈：构建失败立即通知解析：新考纲第7.2节强调CI是敏捷质量保障基础。实践包括自动化测试链和版本控制，避免集成风险。CI通过快速反馈确保代码质量。6.参考答案：七种浪费识别：-过量生产：超出需求的生产，导致库存积压-等待：人员、设备闲置或等待任务-运输：不必要的产品移动-过度加工：超出需求的加工精度-库存：原材料、在制品或成品过多-移动：不必要的人员移动-制造次品：缺陷产品返工解析：新考纲第5.4节通过价值流图识别浪费。七种浪费是精益开发核心概念，持续消除浪费可提升效率。7.参考答案：自组织实现方式：-跨职能成员：具备完成工作所需技能-责任到人：成员自主决定任务分配-透明流程：使用看板、燃尽图等可视化工具-定期反思：通过Sprint回顾会持续改进-服务型领导：ScrumMaster移除障碍，促进改进解析：新考纲第3.1节强调自组织是团队成熟度体现。通过培养协作文化，自组织团队可高效交付。8.参考答案：敏捷与瀑布风险管理差异：-敏捷：通过迭代识别和应对风险，风险随时间分散-瀑布：前期集中识别风险，后期变更代价高-敏捷：风险可视化，通过Sprint评审会暴露问题-瀑布：风险隐藏，缺陷发现晚解析：新考纲第1.2节强调敏捷通过适应性降低整体风险。敏捷风险管理是持续过程，瀑布风险集中且被动。五、应用题答案及解析1.参考答案：(1)Sprint计划会准备：-产品负责人准备用户注册功能的故事和验收标准-开发团队回顾历史数据，建立估算基准-确定Sprint评审会日期和评审流程-准备估算工具(如计划扑克牌)-明确Sprint目标SMART原则：具体、可衡量、可实现、相关、有时限(2)Sprint可行性分析：-需求工作量：40故事点-团队能力：8人×2周×8小时=1024小时-历史数据：30故事点≈1024小时，1故事点≈34小时-理论工作量：40×34=1360小时>1024小时-结论：Sprint不可行，可能无法完成需求，需拆分或推迟(3)调整方案：-拆分功能：将注册流程拆分为"注册表单"、"邮箱验证"、"密码加密"等子任务-重新估算：分拆后若总点数≤30，可接受-优化流程：简化逻辑，减少第三方依赖-跨Sprint优先级：若无法拆分，将注册功能移至下一Sprint-风险应对：增加Sprint评审会检查点，提前暴露问题解析：该案例考察Sprint规划能力。通过历史数据和理论计算判断工作量是否合理，并给出调整方案。敏捷开发强调适应性，但需在灵活性与计划性间找到平衡。2.参考答案：(1)瓶颈识别：-数据分析：检查各阶段在制品数量和等待时间-流程图：绘制当前状态，观察队列长度-可能瓶颈：质检阶段(平均等待2天)、打包阶段(在制品积压)-真实瓶颈：通过跟踪发现质检阶段因人工审核导致阻塞(2)改善措施：-限制WIP：在质检阶段将限制从5降至3-优化流程：增加质检岗轮班，减少等待时间-自动化：引入图像识别辅助质检，提高效率-流程重构：将简单订单分流至快速通道(3)预期效果：-减少平均处理时间至3天(理论值：1/WIP×平均处理时间)-提高吞吐量(理论值：处理时间×WIP上限)-降低在制品库存(减少队列积压)-提高员工满意度(减少加班和压力)解析：该案例考察Kanban应用能力。通过数据分析和流程图识别瓶颈，并给出改善方案。Kanban的核心是持续改进，通过限制WIP平衡流程。3.参考答案：(1)延期原因分析：-需求混乱：产品待办列表无优先级，变更频繁-缺乏自组织：团队依赖指令而非主动协作-流程缺失：未实施CI/CD，集成问题拖慢进度-领导力不足：ScrumMaster未发挥服务型角色(2)改进措施：-需求管理：建立严格的优先级排序机制-自组织培养：通过每日站会、回顾会提升协作-持续集成：实施自动化构建和测试链-服务型领导：ScrumMaster移除障碍，促进改进(3)关键指标：-Sprint达成率：目标完成率≥80%-周期时间：从需求到交付的平均时间-流程效率：吞吐量/平均处理时间-团队满意度：通过匿名调查评估协作氛围解析：该案例考察敏捷实践问题诊断和改进能力。通过分析团队表现，给出改进方案，并设定可衡量的关键指标。敏捷成功需要团队、流程和领导力协同。4.参考答案：(1)问题分析：-差异对比：设备A/B换线时间差异6倍-原因挖掘：通过价值流图发现A设备存在：-工具准备时间过长-操作流程复杂-缺乏快速换线培训(2)改善方案：-标准化作业