硬件开发中的Scrum：如何适配这一框架

Scrum诞生于软件开发语境，其仪式、制品和节奏都反映了这一环境的假设：工作可以拆分为小单元，每两周可以产出一个潜在可交付的增量，变更成本相对较低。硬件开发打破了其中多项假设：实体零部件有交货期，测试环境需要数天才能配置完成，原型无法在两周内完成。然而，萨博、宝马、波士顿科学和约翰迪尔等公司的硬件团队已经成功适配了Scrum。关键在于理解哪些要素可以直接移植、哪些需要调整，以及哪些应该放弃。

调整迭代长度

软件开发中标准的两周迭代对硬件工作往往不切实际。实体原型的构建-测试周期通常至少需要三到四周。Scrum指南并未强制规定两周迭代——它规定迭代为一个月或更短。硬件团队通常运行三到六周的迭代，与实际的构建-测试周期相匹配。

硬件专属的完成定义

硬件的完成定义需要反映该领域的物理现实，例如：设计文件已更新至版本控制系统、物料清单已核对、原型按规格构建完成、指定测试已完成并记录结果、失效模式已审查、相关合规检查已完成。需要避免的陷阱是：完成定义过于宏大，只有在整个开发计划结束时才能满足，而非在每次迭代结束时。

将实物库存作为在制品管理

待交货的零件、等待装配的组件以及处于不同构建阶段的原型，都是精益意义上的在制品——已消耗资源但尚未交付价值的项目。硬件团队的迭代规划需要明确将采购交货期纳入考量。待办列表的排序不仅要考虑价值和优先级，还要考虑执行各项工作所需实物材料的可用性。

可直接沿用的元素

• 迭代规划：选定有界范围的工作并作为团队整体承诺，在硬件领域同样有价值。

• 每日站会：十五分钟足够；相同的三个问题；固定节奏在跨职能团队中建立凝聚力。

• 迭代回顾：硬件团队常将其列为框架中最有价值的元素之一。

• 产品负责人权威：由一人负责待办列表的优先级决策，消除了逐委员会审批的拖沓动态。

应避免的做法

硬件团队采用Scrum时最常见的错误，是将软件迭代长度强加于硬件工作。一个两周迭代若无法产出有意义的经过测试的硬件增量，它就不是迭代——它不过是带有额外流程开销的双周状态更新。如果团队在两周结束时无法展示明显不同的成果，就应调整迭代长度。

XNM咨询帮助工程和产品开发组织实施适应其具体情境的敏捷与Scrum实践。