硬件研发做敏捷，难点在于长周期的阶段门流程与短周期的迭代节奏如何共存。本文给出一套适配后的操作路径：在阶段门内用固定迭代推进设计、验证与样机工作，用看板管理在制品与阻塞，用分层完成定义区分设计完成、验证通过与可量产，并通过一个子项目试点验收后再扩展。ONES 可作为承载工作项与迭代节奏的管理工具。
要点总览（TL;DR）
- 硬件研发做敏捷的关键，是把阶段门作为外层治理节点、迭代作为内层执行节奏：阶段门管方案冻结、设计冻结、验证通过等放行决策，迭代管设计、打样、验证与问题闭环的日常推进。
- Scrum 元素需要取舍：保留固定节奏、看板、站会、评审与回顾；迭代长度按样机与验证周期设定，完成定义拆成设计完成、验证通过、可量产三层，增量改为可评审的设计与验证证据。
- 落地按五步走：确定产品目标与阶段门节点、建立工作项类型与完成定义、设定迭代长度与节奏、运行迭代内设计与验证并处理阻塞、把迭代评审结论汇入阶段门评审。
- 看板按需求、设计、打样、验证、放行设列并设好在制品限制，工作项必填负责人、所属阶段门、依赖、风险等级和完成定义层级，让等待打样、等待设备这类阻塞尽早暴露。
- 试点验收看四项：迭代节奏稳定、完成定义被遵守、阻塞及时暴露处理、阶段门与迭代评审有效衔接；四项通过后再统一阶段门计划与迭代日历，扩展到多团队。
硬件研发为什么不能照搬软件 Scrum
软件 Scrum 默认需求可以在短周期内被完整实现并随时交付可用增量，硬件研发不满足这个前提。一个硬件项目从概念到量产通常跨越数月甚至更长，结构件开模、PCB 打样、元器件采购、样机装配、环境与可靠性验证各自有外部周期，迭代内能完成的往往是设计输出、仿真结论、验证方案或问题定位，而非可交付的产品增量。变更成本也随阶段快速上升：原理图阶段改一个接口代价很小，开模之后再改结构可能带来模具重做和认证重测。这些约束决定了硬件敏捷不能照搬软件 Scrum 的节奏假设。
适配的做法是把阶段门作为外层治理节点，把迭代作为内层执行节奏。阶段门管关键决策与放行，例如概念评审、方案冻结、设计冻结、验证通过、量产放行；迭代管阶段门之间的日常推进，按固定长度滚动设计、打样、验证和问题闭环。阶段门提供硬件的决策纪律，迭代提供短周期的透明度和调整空间，两者叠加而不是互相替代。
Scrum 元素需要做取舍。保留的部分包括固定节奏的迭代、可视化的看板、每日站会同步阻塞、迭代评审检视产出、回顾改进协作方式。需要改造的部分主要有三处：迭代长度按硬件实际交付节拍设定，通常长于软件的两周；完成定义分层，设计完成、验证通过、可量产分别有各自的判定标准；增量定义从“可交付功能”改为“可评审的设计与验证证据”，例如一份通过评审的原理图、一组仿真结果、一份验证报告。
核心操作步骤：从立项到迭代运行
下面五步构成从立项到迭代运行的完整操作链，每一步都给出输入、动作、输出和完成标志，便于直接对照执行。
第一步：确定产品目标与阶段门节点
输入是产品需求、市场窗口和资源约束。动作是与产品、硬件、验证、供应链共同确认产品目标，并把项目拆成若干阶段门，明确每个门的评审内容、放行标准和责任人。输出是一张阶段门计划，标注各门的计划时间与准入条件。完成标志是所有关键角色对阶段门数量和放行标准达成一致，且每个门都有明确的决策人。
第二步：建立硬件工作项类型与完成定义
输入是阶段门计划和硬件研发的实际工作内容。动作是定义工作项类型，常见的有需求、设计任务、打样任务、验证任务、缺陷与问题、风险项；同时为每类工作项写明完成定义。完成定义要分层：设计完成指图纸或文件通过内部评审并归档；验证通过指验证方案执行完毕、结果满足预定指标并有记录；可量产指工艺、物料、测试工装和供应链条件具备。输出是工作项类型清单与完成定义说明。完成标志是团队能对任一工作项说出它当前处于哪一层完成状态。
第三步：设定迭代长度与节奏
输入是样机与验证的外部周期、团队规模和评审习惯。动作是确定迭代长度和固定节点，例如每三周一个迭代，迭代首日做计划、每日站会同步、迭代末日做评审。硬件迭代长度通常需要覆盖一次设计输出加一轮内部验证的周期，过长会失去透明度，过短则大量工作项跨迭代悬挂。输出是迭代日历和会议节奏。完成标志是连续两个迭代按计划日期开始和结束。
第四步：运行迭代内的设计、验证与阻塞处理
输入是迭代计划中承诺的工作项。动作是团队成员认领并拆解任务，在看板上推进状态；每日站会聚焦三件事：昨天推进了什么、今天做什么、有什么阻塞。阻塞项要当场标记责任人和解决时限，跨部门的依赖（如等待打样回板、等待实验室排期）单独跟踪。输出是迭代内的工作项状态更新和阻塞清单。完成标志是迭代结束时每个承诺工作项都有明确状态，阻塞项有处理结论。
第五步：迭代评审与阶段门评审的衔接
输入是迭代产出的设计文件、验证记录和问题清单。动作是在迭代评审中检视产出是否满足完成定义，并把评审结论汇总为阶段门评审的输入材料；阶段门评审则判断是否放行进入下一阶段。输出是迭代评审纪要和阶段门决策记录。完成标志是每次阶段门评审都能追溯到对应的迭代产出，评审结论有明确的放行、有条件放行或退回决定。
角色分工与各阶段交付物
硬件敏捷的角色设置需要在 Scrum 角色基础上补充硬件特有的职能。职责不清是试点阶段最常见的失败原因，下表按角色列出主要职责、在迭代中的交付物和在阶段门中的交付物。
| 角色 | 主要职责 | 迭代中的交付物 | 阶段门中的交付物 |
|---|---|---|---|
| 产品负责人 | 确定产品目标与优先级，维护待办事项顺序，对阶段门放行标准负责 | 迭代目标、优先级排序后的工作项 | 产品需求说明、阶段门放行建议 |
| 硬件项目经理 | 协调阶段门计划与迭代节奏，跟踪跨部门依赖与风险 | 迭代计划、阻塞清单、进度看板 | 阶段门评审材料、风险与依赖报告 |
| 技术负责人 | 把关设计方案与技术决策，主持设计评审 | 设计输出、评审结论、技术问题定位 | 方案冻结与设计冻结的技术依据 |
| 验证角色 | 制定验证方案，执行验证并记录结果 | 验证方案、验证记录、问题单 | 验证通过报告与遗留问题说明 |
| 供应链角色 | 负责物料选型、采购周期、打样与量产条件 | 物料清单、打样进度、供应风险提示 | 可量产条件评估、供应保障说明 |
跨职能协作的关键交接点有三处。设计输出移交验证时，需要同时移交验证要点和已知风险，避免验证角色从零理解设计意图；验证问题回流设计时，问题单要写明复现条件和影响范围，便于技术负责人判断优先级；阶段门评审前，各角色的交付物需要提前汇总，由硬件项目经理确认材料完整后再提交决策。
看板与工作项设计：让硬件进度可见
看板的作用是让设计、打样、验证的推进状态和阻塞在同一视图里可见。硬件看板的列不宜照搬软件的任务状态，建议按硬件工作的实际流转设计，并为每列设定在制品限制。
| 看板列 | 进入条件 | 在制品限制建议 | 典型阻塞信号 |
|---|---|---|---|
| 需求 | 已确认要做的需求或变更 | 按团队容量设定 | 需求描述不清、优先级冲突 |
| 设计 | 已分配负责人并开始设计 | 按设计人力设定，通常每人一到两项 | 等待技术决策、等待接口确认 |
| 打样 | 设计输出已评审并提交打样 | 按打样批次设定 | 等待供应商排期、物料未到 |
| 验证 | 样机到位并开始验证 | 按实验室与验证人力设定 | 等待测试设备、验证方案未确认 |
| 放行 | 验证通过并完成问题闭环 | 不设上限，但需限期清空 | 遗留问题未关闭、评审材料不全 |
工作项需要设置必填字段，保证信息在流转中不丢失。建议至少包含：负责人、所属阶段门、依赖项、风险等级、完成定义层级。所属阶段门让每个工作项都能对应到治理节点；依赖项用于识别跨角色和跨部门的等待关系；风险等级帮助站会快速聚焦；完成定义层级避免用笼统的“完成”掩盖验证缺口。
在制品限制的作用是让阻塞尽早暴露。当某一列达到上限，团队必须先处理该列的存量而不是继续拉入新工作，这会迫使等待打样、等待设备这类外部依赖被提前讨论。阻塞项在看板上应有独立标记，并记录阻塞原因、责任人和预计解除时间，站会逐项过一遍。
ONES 的敏捷看板可用于管理任务状态，每日站会中借助看板对齐迭代进度与风险，燃尽图可用于评估当前研发效率；工作流可根据实际场景自定义，复杂需求可用子工作项拆解并关联研发与测试任务。这些能力适合承载上述看板列与字段设计，具体配置方式以团队实际流程为准。
一个硬件子项目的迭代运行示例
以下为演示情景，用于说明一轮迭代如何从计划走到评审。某硬件团队正在开发一款带无线通信模块的控制设备，当前处于方案冻结之后的详细设计阶段，迭代长度为三周。
迭代目标是完成主控板原理图设计并通过内部评审，同时启动结构件的打样准备。迭代计划会上，团队把目标拆成若干工作项：主控板原理图绘制、关键器件选型确认、电源部分仿真、结构件图纸输出、打样供应商询价。每个工作项标注所属阶段门为设计冻结门，并写明完成定义层级为设计完成。
迭代进行中，原理图绘制依赖器件选型确认，团队把这一依赖显式记录，选型确认安排在第一周完成。第二周站会暴露出一个阻塞：无线模块的供货周期比预期长，供应链角色当场标记阻塞并给出替代型号评估的时间点。结构件图纸输出后进入打样列，因供应商排期需要两周，团队将其列为跨迭代依赖，提前纳入下一轮迭代计划。
迭代评审时，主控板原理图通过内部评审，电源仿真结果满足指标，结构件图纸完成输出但打样尚未回样。评审结论是设计完成层级的工作项可以关闭，打样相关工作项顺延到下一迭代，同时把无线模块供货风险提交阶段门评审作为有条件放行的关注项。下一轮迭代据此调整，把打样回样后的验证准备和替代型号评估列为主要目标。
完成检查：判断硬件敏捷是否跑起来了
试点运行一段时间后，可以用下面这份清单逐项核对。每项都给出可观察的通过标准，避免凭感觉判断。
| 检查项 | 通过标准 | 未通过时的常见原因 |
|---|---|---|
| 迭代节奏是否稳定 | 连续三个迭代按计划日期开始和结束，迭代长度未频繁调整 | 迭代长度与打样、验证周期不匹配 |
| 完成定义是否被遵守 | 关闭的工作项都能说清处于设计完成、验证通过还是可量产层级，评审中未出现用“基本完成”代替判定 | 完成定义过于笼统或未被评审引用 |
| 阻塞是否被及时暴露和处理 | 阻塞项在站会上被提出，有责任人和解除时间，跨迭代阻塞有跟踪记录 | 看板缺少阻塞标记或在制品限制过松 |
| 阶段门与迭代评审是否有效衔接 | 每次阶段门评审都能追溯到对应迭代产出，评审结论有明确放行决定 | 迭代评审纪要与阶段门材料脱节 |
四项全部通过，说明试点阶段的基本机制已经运转；若只有部分通过，优先修复对应环节再扩展范围。扩展到多团队协同时，阶段门计划和迭代日历需要统一，跨团队的依赖要在看板上显式管理。ONES 支持多团队并行开发，兼具组织架构管理、进度管理与资源管理能力，可在扩展阶段承载跨团队的工作项与进度视图。
常见问题
硬件迭代长度定多长比较合适？定错了怎么调整？
迭代长度以能覆盖一次设计输出加一轮内部验证为宜，常见做法是先按团队实际的打样与验证节拍试跑两到三个迭代再定。判断标准是迭代结束时承诺的工作项大多有明确状态，跨迭代悬挂的工作项数量可控。
如果大量工作项反复顺延，说明迭代偏短或工作项拆得过大，可以适当拉长迭代或把打样、验证类工作项按阶段拆细；如果迭代内长期没有可评审的产出，说明迭代偏长，透明度已经下降。调整迭代长度时保持会议节奏不变，避免同时改动多个变量导致无法判断效果。
阶段门评审和迭代评审会不会重复开会？两者怎么分工？
两者决策对象不同，可以合并材料但不能合并决策。迭代评审检视本轮产出是否满足完成定义，结论是工作项能否关闭、哪些问题需要顺延；阶段门评审判断项目能否进入下一阶段，结论是放行、有条件放行或退回。
操作上让迭代评审纪要直接成为阶段门评审的输入材料，硬件项目经理在阶段门评审前确认材料完整。阶段门评审只讨论跨迭代的决策事项和遗留风险，不再逐项复述迭代产出，这样两次会议各司其职，也不会出现阶段门结论追溯不到具体迭代产出的情况。
硬件变更频繁，迭代计划刚定就被打乱，怎么处理？
先区分变更类型。需求或方案层面的变更走阶段门或产品负责人决策，不在迭代中途直接插入；设计细节和问题修复类变更可以在迭代内处理，但要记录对原承诺工作项的影响。
迭代计划被打乱的常见原因是把外部依赖当成了团队可控任务。等待打样回板、等待实验室排期这类工作项应显式标注依赖和预计解除时间，纳入跨迭代跟踪，而不是压进当前迭代的承诺里。迭代内确实需要插入高优先级工作时，由产品负责人明确换出哪一项，保持承诺总量可控。
试点选哪个硬件子项目比较合适？
优先选范围清晰、跨部门依赖相对可控、周期能覆盖两到三个迭代的子项目，例如某个模块的详细设计加验证，而不是整机从概念到量产的全程。这样既能在试点期内观察到迭代节奏是否稳定，也能检验阶段门与迭代评审的衔接。
试点团队应包含设计、验证和供应链角色，否则阻塞暴露和交接点检验不出来。试点期间只在一个子项目运行新机制，其余项目维持原流程，便于对比和收敛问题，验收通过后再统一阶段门计划与迭代日历向多团队扩展。
用工具承载这套机制时，工作项和看板至少要配到什么程度？
最低要求是能表达三件事：工作项归属哪个阶段门、当前处于哪一层完成定义、被什么依赖或阻塞卡住。看板列与硬件流转一致，并为关键列设在制品限制。
ONES 的敏捷看板可用于管理任务状态，站会中借助看板对齐迭代进度与风险，燃尽图可用于评估研发效率；工作流可根据实际场景自定义，复杂需求可用子工作项拆解并关联研发与测试任务。配置时以团队实际流程为准，先保证字段必填和阻塞标记可用，再考虑报表和跨团队视图。
