我们如何用敏捷做硬件研发

一、我们做了一个决定：把Scrum里最“硬”的东西先扔掉

2022年秋天，我所在的产品线出了一次严重事故。一块已经走到EVT阶段的核心板，因为固件团队和硬件团队对“一个传感器采样频率”的理解完全不同，两边各做各的，直到联调时才发现方案级的不兼容。损失不是几行代码的事，而是3周时间和将近17万元的PCB改版费用。

那场复盘会上，技术VP说了一句让我记到现在的话：“你们天天站会、看板、燃尽图，一个都没少，为什么还是在最后一刻撞车？”

这个问题就是本文的起点。我后来花了整整两年时间，在不同项目里反复试验一个命题：硬件研发到底能不能做敏捷？如果能，它应该长什么样？ 本文不是什么理论推演，而是我和团队在真实的电路板、外壳模具、BOM成本和供应商交期约束下，一步步试出来的答案。

先说一个可能让很多人不舒服的核心结论：在硬件研发领域，90%的所谓“敏捷实践”，本质上只是把传统瀑布流程用Scrum术语重新包装了一遍。站会开了，Sprint设了，Retro做了，但决策链路、成本结构和风险承担方式一点没变。 真正的硬件敏捷，不是让硬件团队去适应软件Scrum，而是重新理解“敏捷”在物理世界里的含义。

敏捷的核心不是“快”，而是“快速获得反馈并据此调整”。 软件可以一天发布多次，是因为获得反馈的成本几乎为零。硬件不行。硬件敏捷真正要解决的问题，不是怎么让硬件“跑得更快”，而是怎么在物理世界的约束下，让“获得反馈”这件事尽可能早、尽可能便宜、尽可能不伤筋动骨。 如果你不理解这一点，后面所有的工具和流程都是空中楼阁。

二、一个被大多数人跳过的前置问题：你这个项目，真的适合做敏捷吗？

在做敏捷咨询时，我发现一个规律：那些敏捷转型失败的硬件团队，十个里有八个一开始就问错了问题。 他们上来就问“我们应该用Scrum还是Kanban”，却没有人问过：“以我们产品现在的成熟度，敏捷到底是加速器还是折腾？”

这个问题不回答清楚，后面全是无效劳动。

1. 硬件产品从来就不是一个“均匀”的东西

一块电路板上，至少有三种完全不同性质的工作在并行推进：

• 纯软件/固件层： 驱动、通信协议、算法逻辑，这一层和软件项目几乎一样，天然适合敏捷。
• 软硬耦合层： 功耗管理、信号完整性、传感器选型验证，这一层需要物理测试环境，迭代成本中等。
• 纯硬件层： PCB布局、结构设计、模具开发、BOM定型，这一层每一次变更都意味着真金白银和时间。

我见证过最典型的失败案例：一家做智能门锁的创业公司，用统一Scrum管理所有团队，要求硬件工程师每两周必须出一个“可交付增量”。结果硬件团队为了凑Sprint目标，把原本该花三周做完整信号仿真的PCB，拆成三次“迭代”投板，三次加起来多花了将近两万块钱，而且第二次回来的板子和第一次在阻抗控制上不一致，导致联调时出现间歇性通信故障，根本不知道是哪一版引入的。

教训很清楚：不是所有类型的硬件工作都值得、都应该被塞进同一个敏捷节奏里。

2. 一个简单的判断矩阵：你的项目站在哪个位置？

在PingCode服务的中大型客户中，我观察到一个很有意思的现象：越是成熟的产品线，越懂得在敏捷和瀑布之间做“不纯粹的取舍”。 他们很少会宣布“全产品敏捷转型”，而是精准到具体模块：哪些需求走Scrum，哪些走传统阶段评审，边界非常清楚。

下面这个判断矩阵，是我在多个项目中反复验证后总结出来的。如果你的项目落在左侧，大胆做敏捷；如果在右侧，请谨慎甚至放弃：

如果你有三项以上落在右侧，我的建议是：别硬上敏捷。先把需求明确度和供应商弹性搞定，再来谈方法论。 这不是保守，而是尊重物理规律。

3. 什么样的案例，用敏捷做硬件是对的？

说一个正面的。2023年年初，我参与了一款工业平板电脑的新品研发。这个项目有一个很特殊的背景：客户需求非常模糊，只知道“要在产线上用，能抗摔、防水、续航够一个班次”，但具体用什么通信协议、屏幕尺寸多大、要不要支持戴手套触控，客户自己也不确定。

传统做法是先花两个月做需求调研和规格确认，然后进入设计阶段，但问题在于，客户对“产线使用场景”的认知是在我们看到方案后才被激活的。 你给他文字描述，他说“都行”；你给他一台样机往产线上一放，他立刻能指出十几个问题。

我们果断选择了敏捷模式：

• 核心策略： 不做完整产品Sprint，而是做“功能模块级的快速验证”。
• 验证节奏： 每一到两周召一次“物理评审会”，客户必须到场摸样机。
• 硬件策略： 放弃了“一次做对”的执念，先用开发板加3D打印外壳拼出功能原型，验证核心交互后再进入正式设计。

这一轮下来，我们在正式投板之前完成了11轮功能验证，发现了23个需求层面的问题，其中8个会直接导致产品在产线上无法使用。这些问题的修正，如果在开模之后发现，成本将超过60万元；而在原型阶段修正，总成本不到3万元。 这就是硬件敏捷最核心的价值，不是跑得快，而是让昂贵的错误提前暴露。

三、拆掉那些“看起来敏捷其实不敏捷”的行为

如果让我总结这两年在硬件敏捷上见过最多的坑，排名前三的几乎都是“仪式感大于实质”的伪敏捷行为。它们不是没价值，而是容易让人产生一种“我们已经很敏捷了”的幻觉，从而忽略了真正需要改变的东西。

1. 每日站会不等于敏捷

我见过一个30人的硬件团队，每天早上9点准时站会，每人说三句话，整整坚持了半年。效率提升了吗？没有。因为他们的站会只做了信息同步，没有做阻塞暴露，更没有做即时决策。

硬件团队的站会应该有且只有一个核心目标：识别并移除物理层面的阻碍。 软件团队的阻碍往往是“这段逻辑不知道怎么处理”，而硬件团队的阻碍是“供应商说这个电容交期要8周”、“结构干涉还没解决没法打样”、“实验设备被其他项目占了”。

如果你在硬件站会上听到的都是“昨天画了原理图，今天继续画”，那说明这个站会只是管理者的自我安慰。真正有效的硬件站会，应该由Scrum Master或项目负责人追问两个问题：“你手里有卡住的事情需要其他人介入吗？”和“这个阻碍是否会影响本周的物理验证计划？” 如果连续三次站会都没有暴露任何阻塞，要么是团队在报喜不报忧，要么是站会规则本身失效了。

2. 用Jira/TAPD/PingCode不等于敏捷

工具是流程的载体，不是流程本身。我曾在一家使用PingCode管理硬件项目的团队里看到这样一个场景：他们严格在PingCode里建了Epic、Feature、User Story三级需求结构，每个Story都估了Story Point，燃尽图每周自动生成，但他们的迭代周期是8周，而且迭代期间需求基本不变。

这本质上还是一个瀑布项目，只不过把甘特图换成了看板。PingCode的产品设计本身支持标准的Scrum流程，从需求管理、迭代规划到进度跟踪和回顾，但工具能做的是让敏捷流程“跑起来”，而不是保证它“跑对”。 如果你的迭代周期长到足够容纳所有已知需求，那Scrum的时间盒机制就失去了意义。

对于硬件项目来说，我更建议把PingCode这类工具用在“可视化管理”和“跨职能协同”这两个维度上。 比如：硬件工程师的进度在Jira里是一个Black Box，而PingCode可以把需求、任务、代码提交、测试用例打通，这样固件团队和硬件团队至少能在同一块看板上看到对方的进展。这种“透明化”的价值，比生搬硬套Story Point要大得多。

3. “等这版稳定了再敏捷”是一种拖延

我听过最多次的借口是：“这个项目时间太紧了，等下一个项目我们再试点敏捷。”然后下一个项目也一样，永远在“等”。

敏捷本来就不是让你在最舒适的时候用的，它就是为不确定性和时间压力设计的。 如果你项目时间充分、需求明确、技术成熟，你用什么方法都不会太差。硬件敏捷真正的用武之地，恰恰是那些“时间紧、需求变、方案不确定”的项目。

四、我们重新定义了一套“硬件敏捷判断框架”

经过多个项目的试错和修正，我逐渐形成了一套判断逻辑，用来回答“在当前阶段，我应该用什么节奏做事”这个问题。这套框架不是学术理论，而是在产线上、会议室里、供应商现场反复检验过的实用工具。

1. 先判断产品所处的物理阶段

硬件产品开发的物理阶段不同，容错空间完全不同。我把硬件研发过程拆成四个阶段，每个阶段对应完全不同的敏捷策略：

这个表的用法很简单：先问自己现在处于哪个阶段，然后接受该阶段能承受的试错成本上限。 我在PingCode的迭代规划功能中，会建议团队为每个Sprint设定一个“物理变更预算上限”，比如EVT阶段单次迭代不超过2万元。一旦超过，自动触发更高级别的评审，而不是让团队在Sprint框架内自行决策。这个机制在很多中大型硬件团队中起到了“护栏”的作用。

2. 再区分同一产品内的“可敏捷区”和“不可敏捷区”

同一个硬件产品内，不同模块的敏捷弹性天差地别。举个例子，一块智能手表主板：

• 心率算法优化： 可以做到日级迭代，只要有足够的测试数据。
• 蓝牙协议栈调整： 可以周级迭代，但每次需要完整的兼容性测试。
• 天线匹配调试： 需要物理实验室，两周一次已经很快。
• PCB层叠结构调整： 每次意味着重新投板和至少3周等待，一个月一次都嫌快。
• 外壳模具修改： 开模后基本上不能动，除非有重大缺陷。

成熟团队的标志之一，就是能坦然接受“同一个Sprint里不同任务跑在不同节奏上”这件事。 不要追求形式上的一致，追求实质上每个模块都在它能承受的最快反馈循环里运转。

3. 用“坏方案淘汰率”替代“功能完成率”作为核心指标

这个观点可能是我在硬件敏捷领域最坚持的一个：在概念验证和EVT阶段，度量团队产出的正确指标不是“完成了多少功能点”，而是“淘汰了多少个坏方案”。

软件敏捷喜欢用Velocity（速率）衡量团队产出，Story Point完成得越多越好。但硬件前期恰恰相反，你越快排除不可行的方案，后期踩坑的概率越低。我曾在同一个团队里做过对比实验：让A项目组按传统指标考核，B项目组按“原型阶段坏方案淘汰率”考核。结果B项目组在DVT阶段的设计变更数量比A组少了60%以上。

具体操作上，我在PingCode的用户故事中增加了一个自定义字段叫做“验证结论”，只有三个选项：方案可行、方案需优化、方案淘汰。 每次Sprint Review时，重点关注的不是“这个故事做完了没有”，而是“被淘汰的方案给我们带来了什么认知”。这种考核导向的转变，直接改变了团队的决策行为，以前大家倾向于“做一个看起来可行的方案就往下走”，现在更愿意“多试几个方案，快速排除差的”。

五、一个真实案例：从混乱到可控的130天

下面这个案例来自我深度参与过的一个工业网关项目，团队规模大约35人，包含硬件、结构、固件、测试、产品五个职能。产品需求是做一个支持5G和Wi-Fi 6的工业边缘计算网关，目标客户是智慧工厂。

项目启动时，团队面临三大挑战：第一，客户对边缘计算能力的具体要求说不清楚；第二，核心芯片选型有多个候选方案但各有优劣；第三，结构散热方案在紧凑空间和高功耗之间难以平衡。

1. 我们做了什么：三步走策略

第一步（第1-4周）：需求显形化与方案多方验证

我们没有上来就画原理图，而是先用三周时间做了六套功能原型，不是说做六个完整产品，而是围绕“客户到底需要网关在边缘端做什么计算”这个问题，用现成的开发板和开源软件拼出了六种不同能力组合的演示系统，每周让客户过来操作一次。

这个过程暴露了一个关键发现：客户之前在需求文档里写了“需要本地AI推理能力”，但经过三轮原型演示后，我们发现他们真正需要的是“本地数据清洗和特征提取，把结果上传到云端做推理”。这一字之差，直接让主控芯片的选型从“带NPU的高端方案”降级到“中端ARM方案”，单BOM成本降低了约180元。

第二步（第5-8周）：并行验证与模块级取舍

进入方案阶段后，我们在三个模块上同时开了并行验证：

• 射频性能验证： 同时做两版天线方案，在微波暗室里测完选一版。
• 散热方案验证： 同时做被动散热和主动散热两套结构方案，用热仿真加实物测试对比。
• 核心芯片验证： 两个候选芯片各投一版最小系统板，跑压力测试看稳定性。

用团队里一位硬件工程师的话说：“我们这次不是在‘选方案’，而是在‘淘汰方案’。每个模块都至少有一个方案是被明确验证后放弃的。”

第三步（第9-18周）：合并收敛与快速迭代

核心方案锁死后，进入正常的EVT和DVT流程。这个阶段我们恢复了相对传统的阶段管理方式，但在固件和软件层面保持了周迭代节奏。PingCode在这阶段发挥了关键作用：需求变更、缺陷跟踪、测试用例管理和迭代进度全部在一个平台上可视，硬件和固件团队之间不再需要“发邮件确认版本”。

2. 结果和代价

结果：

• 项目总周期130天，比原计划的160天缩短了约19%。
• 量产爬坡周期从行业平均的6-8周缩短到4周。
• DVT阶段的设计变更只有2处，远低于该团队历史平均的7处。

代价：

• 前期多投了3版PCB和2套手板，额外花费约5.8万元。
• 射频验证租用外部实验室费用3.2万元。
• 团队在第一个月普遍反映“感觉做了很多不产生交付物的工作”，士气一度受挫。

这笔账很容易算：前期额外投入约9万元，换来的是后期至少节省了40万元以上的设变成本和超过30天的项目周期。 如果你是一家硬件公司的负责人，这个ROI应该足够清晰了。

六、不同场景下的行动建议与取舍

写到这里，我必须非常诚实地说明一点：上面这套做法，不是在所有硬件项目中都适用。盲目套用比不用还糟糕。 下面我把最常见的三种场景分开讨论，每种场景下你应该做什么、不应该做什么，以及最关键的那些“取舍”。

1. 消费电子新品：可以激进但要设止损线

典型特征： 市场竞争激烈，上市时间窗口窄，工业设计和用户体验是第一优先级，硬件方案变化空间大但窗口期短。

建议做法：

• ID（工业设计）和结构必须在前三周内冻结，这是硬约束，不能进敏捷循环。
• 电子方案可以保留两套并行到EVT中期，然后强制收敛。
• 固件和App迭代保持周节奏，硬件作为“平台”，软件作为“可变层”。
• 必须设定一个明确的“止损触发条件”： 比如EVT阶段累计投板超过3版仍未锁定核心方案，必须上升到VP级别决策。

最大的取舍：
上市时间和方案完美度之间的平衡。 消费电子的窗口期往往只有3-4个月，错过就没了。在这种情况下，接受一个“85分但按时上市”的方案，远好于追求“95分但迟到两个月”。

2. 工业设备与医疗器械：敏捷空间极其有限，但并非零

典型特征： 行业标准和法规认证是硬约束，变更成本极高且流程严格，客户对可靠性的要求远高于对功能新颖性的要求。

建议做法：

• 不要在硬件主体上做敏捷。 这是我最明确的一条建议。工业设备和医疗器械的硬件架构一旦定下来就不要轻易改动，因为涉及安规认证、EMC测试、环境可靠性等大量不可逆的合规投入。
• 能做的敏捷空间在固件策略优化、通信协议适配、边缘侧算法迭代这些纯软件或软硬低耦合的层面。
• 如果有新功能需求，做“外挂模块”而不是“改主板”。新增一个子板来做新功能验证，成本远低于改主板。
• 认证预测试可以提前做，这块反而是可以“敏捷”的，不要等到正式送测才发现EMC不过。

最大的取舍：
功能完整性和认证周期之间的平衡。 宁可在认证范围上做减法，确保核心功能先拿证上市，外围功能走后期变更或子版本升级，也不要试图“一次性把所有功能都塞进首次认证”。

3. B2B定制项目：先锁定“可控中的可控”

典型特征： 客户有明确的技术规格要求但往往不完整，项目周期通常有合同约束，需求变更频繁但每次变更都涉及商务谈判。

建议做法：

• 在技术方案评审阶段做敏捷，在交付执行阶段做瀑布。 这是我个人认为B2B硬件项目最务实的策略。
• 签合同之前，投入2-3周做技术预研，把不确定的方案点用最小成本验证一遍，这部分费用建议直接写入售前预算。
• 合同签完后，需求变更走正式的CR（变更请求）流程，不要在迭代中“偷偷改”。
• 给客户做“双周方案同步会”而不是“需求变更会”，让客户在方案推进过程中持续参与评审，减少后期正式变更的数量。

最大的取舍：
客户满意度和项目利润之间的平衡。 B2B项目最大的风险不是做不出来，而是免费改了太多需求导致项目亏损。敏捷的精神是“拥抱变化”，但B2B硬件的现实是“变化应该被拥抱，但需要有对应的商务认可”。

七、给硬件团队负责人的一份实操清单

如果你读到这里，大概率是正在考虑或者正在推动硬件团队的敏捷转型。下面这份清单是我从多个项目中提炼出来的最小可行行动集，每一条都经过至少两个项目的验证。

1. 先做这三件事，再做其他

第一件：用两周时间做一次“现状物理审计”。 不要写PPT，不要开大会。就做一件事：统计过去两个项目里，DVT阶段以后发生了几次设计变更，每次变更花了多少钱，根因是什么。如果70%以上的变更是因为“前期需求没搞清楚”，那你的问题不是研发流程，而是需求显形化机制。

第二件：选一个“风险可控但影响可见”的小模块做试点。 不要一上来就全产品敏捷转型。选一个固件模块或者一个子板，用本文的方法试一轮，让团队自己在Retro里得出结论。自上而下的敏捷转型成功率极低，自下而上的验证式推广才可持续。

第三件：和供应商谈清楚“小批量快返”的合作模式。 硬件敏捷最大的瓶颈往往不在团队内部，而在于供应商的配合度。如果你每次投板都要等两周，那你的迭代速度天花板就是两周。找一些能接受加急小批量的供应商，哪怕单价贵30%，在敏捷的语境下通常是划算的。

2. 使用PingCode管理硬件敏捷项目的几个关键配置

如果你的团队已经在用或考虑用PingCode管理硬件开发，以下配置是我在实践中反复调整后认为比较合理的：

• 需求层级： 用Epic管理产品级需求，Feature管理子系统级需求，User Story管理可在一个Sprint内验证的功能点。特别注意：硬件相关的User Story应该包含“验证条件”字段，明确这个Story做到什么程度算“被验证”而不是“被完成”。
• 迭代周期： 不建议硬套软件Scrum的两周。在概念验证阶段可以设一周，EVT阶段两到三周，DVT阶段四周。PingCode支持自定义迭代周期，根据阶段灵活调整。
• 任务拆分： 硬件工程师的任务拆分粒度比软件粗是正常的。一个“完成某模块原理图设计”的任务可能就要占用一个人5天时间，不需要强行拆成更小的任务来凑看板的视觉密度。
• 燃尽图的使用： 在硬件项目中，燃尽图的意义不在于精确追踪进度，而在于发现“异常走平”。如果燃尽线连续多日不下降，大概率是有阻塞未暴露。
• 与代码仓库和CI/CD的集成： 这是PingCode的一大优势。固件团队的代码提交可以自动关联到对应的User Story，在迭代看板上直接看到每个任务的代码提交状态和构建结果。对于硬件团队来说，即使硬件工程师不写代码，他们至少能在同一个平台上看到固件团队的工作进展，减少跨职能的信息不对称。

八、我在硬件敏捷上的一个根本性反思

写到最后，我想说一个更根本的观点。

做了这么多硬件敏捷项目之后，我越来越觉得，硬件敏捷面临的最大挑战根本不是方法论，不是工具，甚至不是供应商，而是团队对“试错”的认知和态度。

软件工程师天生习惯试错。一个功能上线后发现不对，回滚一下、修个Bug、再发一版就行了，成本微乎其微。但硬件工程师，尤其是经验丰富的老工程师，对试错有一种根深蒂固的抗拒。这不是保守，而是职业训练的结果。在他们的职业生涯中，“一次做对”就是最高荣誉，“反复改版”就是能力不足。

硬件敏捷要解决的最深层问题，是帮助硬件团队重新定义什么叫“对”：在不确定阶段，“快速排除错方案”比“一次做对”更有价值。

我见过的最成功的硬件敏捷团队，不是那些方法论执行得最标准的，而是那些能够坦然说出“我们这个方案验证失败了，所以我们学到了以下三件事”的团队。他们把“坏方案淘汰”当作资产而不是负债。

如果你只能从这篇文章里带走一件事，我希望是这句：不要让你的硬件团队在“追求确定性”的路上，错过了“拥抱不确定性”带来的红利。 敏捷不是让你放弃严谨，而是让你把严谨用在最值得的地方，不是把所有方案都做对，而是确保对的那个方案能活下来。

下一步，建议你做的事：

1. 做一个“回溯审计”： 拉出最近一个项目的所有设计变更记录，标记出哪些是“如果在原型阶段被发现，成本可以降低80%以上”的。用数据说服自己和团队。
2. 选一个小项目或子模块跑一轮： 用本文的“物理阶段判断矩阵”和“坏方案淘汰率指标”，在一个可控范围内测试。跑完之后让团队自己决定要不要扩大范围。
3. 如果条件成熟，引入PingCode这类能打通需求、任务、代码和测试的工具： 不是为了“数字化”，而是为了让跨职能协同不再依赖信息的二次传递和低效的会议同步。

硬件敏捷这条路，我走了两年，踩的坑比走对的路多。但每一次踩坑之后，我和团队都会在Retro板上写下同一句话：“我们弄清楚了今天为什么失败，所以明天可以更聪明地做决策。” 这可能就是硬件敏捷的全部意义。