作者： Q.H. Wang

敏捷团队出现“这件事谁负责”的争议时，问题可能出在三个不同位置：角色混淆是职责边界与决策权说不清，角色重叠是多个角色承担同一职责，角色缺位是必要职责无人承接。本文给出三者的定义、边界对照与识别信号，帮助判断团队遇到的是哪一类问题。

阶段门管理用分阶段评审和放行决策控制投入风险，敏捷管理用短周期迭代和持续反馈应对不确定性。本文对照两者在目标假设、流程结构和评审机制上的差异，说明硬件研发如何组合使用，并给出选择与试点建议。

硬件研发导入敏捷管理的阻力多表现为计划顺延、迭代目标无法闭合、评审堆积和跨部门等待。本文按症状归类、原因假设与证据验证、分类型处置、效果验证四步展开，帮助推进者判断阻力来自结构还是执行，并安排可回退的处置动作。

硬件研发导入敏捷失败，多与把软件迭代节奏直接套到长周期硬件流程有关。本文按症状、原因假设、排查顺序、处置和验证展开，帮助判断问题出在导入方式还是个别迭代执行。

敏捷团队可以没有Scrum Master，前提是流程引导、障碍清除、外部协调与改进跟踪有人稳定承接。本文按团队阶段给出可行性判断表，说明兼职与轮值的投入代价、应暂缓取消角色的信号，以及用小范围试点验证的方法。

硬件研发敏捷管理以短周期迭代持续检视增量，阶段门评审以里程碑关口控制投入与放行。本文对照两类机制在节奏、评审对象、决策类型上的差异，说明硬件研发中如何组合使用，并给出选择侧重的判断条件。

专职 Scrum Master 是否必要，取决于阻碍是否长期无人清理、跨团队依赖是否频繁、Scrum 事件是否稳定产生改进，以及组织是否处于转型初期。本文给出专职、兼职、暂不设岗三种配置的判断框架、投入前提与试点验证方法。

评估Scrum Master的工作成效，应围绕其职责建立可观察指标：交付节奏稳定性、流程事件质量、阻碍清除时效、团队自组织程度和协作顺畅度。每项指标写清分子分母、统计时间窗和数据来源，用多周期趋势与基线对照判断，并把结果用于改进对话而非绩效定论。

兼职Scrum Master是一种有条件的角色安排。本文从职责冲突、时间投入与团队成熟度三项判断出发，给出适用条件自查、投入前提清单、暂缓信号，以及用两到三个迭代试点验证可行性的方法。

评估Scrum Master是否称职，需要把团队结果与SM个人作用分开看。本文给出交付节奏、流程健康、障碍清除、团队成长与事件质量五类指标，逐项说明公式、分母、时间窗和缺失值规则，并用一个季度的演算示例展示如何从取数走到判断结论。