发帖
雷达卡
说实话，当前硬件研发的竞争非常激烈，传统的瀑布式开发模式已经难以适应快速变化的市场需求。去年我们负责一个智能家居项目时，光是需求评审就耗了三个月，等到样机终于做出来，市场风向早已不同。迫于压力，我们决定尝试引入Scrum框架，虽然过程艰难，但最终摸索出了一套适合硬件团队的工作方式。
硬件冲刺周期必须拉长到合理范围。起初我们照搬软件团队常用的两周冲刺节奏，结果很快遭遇失败。第一个冲刺目标是完成射频模块的原理图设计，但关键芯片的采购周期就长达三周，工程师画完图后只能被动等待物料。经过调整，我们将冲刺周期延长至四周，正好匹配一次小版本迭代：前两周集中进行设计与评审，后两周安排样机生产，确保团队工作连续不中断。[此处为图片1]
站会形式需要灵活处理，不能过于僵化。硬件工程师普遍反感流于形式的每日汇报。刚开始我们坚持每天站会，追问“昨天做了什么、今天计划做什么”，有位资深工程师直接反问：“昨天在等PCB打样，今天还在等，明天估计也得等——你要不要听个详细版？”此后我们改为每周一、三、五召开站会：周一统筹任务分配，周三跟进进度，周五重点清理阻碍项。尤其是周五会议，专门解决诸如物料滞留海关、测试工装协调不到位等实际卡点问题，这才是硬件研发的真实痛点所在。
任务拆解要体现硬件特性。软件可以将功能拆分为几十个细小的故事点，但硬件任务不宜过度碎片化。例如“完成电源模块设计”这类任务，若强行拆成“画原理图→布局→布线”几个步骤，并不能真实反映工作进展，反而割裂了整体性。我们现在以功能模块为单位划分任务包，每个包涵盖从设计、物料准备、生产到测试的完整流程，由模块负责人全程主导。这样既保证了工作的系统性，也能在单个冲刺内交付可验证的实体成果。
对“完成”的定义必须清晰且统一。软件中点击部署按钮即可视为发布完成，而硬件则复杂得多。我们曾吃过亏：一次评审会上，机械工程师声称结构设计已完成，细问之下才发现模具尚未启动。如今我们制定了明确的“完成”标准：电气设计完成 = 原理图 + PCB设计 + BOM清单全部冻结；结构设计完成 = 3D模型 + 工程图纸 + 模具图纸全部签发；测试完成 = 所有测试用例执行完毕并输出正式报告。这套标准成为每次评审的核心依据。
文档依然不可或缺。推行敏捷并不意味着放弃文档，而是聚焦关键文档的及时产出。无论迭代多快，设计规范、测试报告、物料清单（BOM）等核心文件仍是质量保障和合规审计的基础。目前我们将这些文档任务作为独立卡片纳入产品待办列表，优先级与开发任务并列。每个冲刺都要求交付若干重要文档，确保研发过程可追溯、可审查。
跨部门协作必须提前介入。硬件开发最怕出现“你们做完我才能开始”的推诿局面。现在我们在每个冲刺初期就邀请生产、采购、品质等部门参与。采购工程师加入早期设计评审，实时反馈关键元器件的供货周期；生产工艺师提前评估PCB布局的可制造性，避免设计完成后无法量产的情况发生。尽管前期沟通成本有所上升，但却极大减少了后期返工带来的资源浪费。
经过大半年的实践探索，虽然仍会遇到“等料”“等样机”的尴尬阶段，但相比过去那种闭门半年才拿出成品却可能偏离需求的做法，现在的模式明显更受认可。如今我们每个月都能展示可运行、可测试的阶段性实物成果，客户和管理层的反馈更加积极。最近结束的第五次冲刺中，我们甚至在评审会上现场演示了新版本样机的功能表现——这在过去几乎是不可想象的。[此处为图片2]
归根结底，Scrum并非拿来即用的万能方案，尤其在硬件领域更需因地制宜。关键在于把握“小步快跑、快速验证”的核心理念。尽管硬件迭代成本高是现实，但通过合理延长冲刺周期、明确定义交付标准、加强跨职能协同，完全能够建立起符合硬件特点的敏捷节奏。目前我们正在尝试将硬件冲刺与软件冲刺同步对齐，推动软硬件并行集成测试。这条路还很长，但我们已经迈出了实质性的步伐。
京公网安备 11010802022788号
