硬件真的敏捷不起来吗？

在硬件场景中，一提到敏捷往往会有这样的反应：“这是软件行业的事儿，软件开发敏捷起来很容易。硬件没办法敏捷，我们有机械、电气、供应链、制造等环节重重阻碍，真的敏捷不起来。”

然而，在市场瞬息万变的当下，保持这样想法的人是时候该走出这个思维误区了。敏捷力已经嵌入各行各业的方方面面，纵览全球，那些优秀的领导者已经把敏捷力嵌入了工业硬件产品的开发和导入活动中。像Bosch、宝马以及极具热度的特斯拉、SpaceX。

这些企业无不把敏捷力与执行效率直接关联起来，而执行效率又是企业竞争力的重中之重。显而易见的是，NPD（新产品开发）和NPI（新产品导入）过程越快的企业，往往能够收获更高的价值。特斯拉在产线上每天他们至少有27个变更，这种对变化的快速响应能力使特斯拉在汽车行业的市值也遥遥领先。反观那些响应度慢的企业，市值正在逐步萎缩。

那么硬件该如何才能敏捷起来呢？硬件敏捷的关键之处就在于模块化，最佳的模块大小有助于提升团队的技术优越性和自动化能力。构建面向对象的硬件架构体系，并把一个大的硬件产品逐步拆成相互独立的小模块，是硬件敏捷实践中降低风险的关键策略。接下来我们一起看看实施硬件敏捷的重点。

首先需要明确一个硬件产品目标，以面向对象的进行架构设计并进行模块化拆分，让这些模块可以相互独立地并行开展交付工作。这些相互独立的模块之间通过明确的接口定义连接，任何人改动了接口都需要自行提供一个新的软件或者硬件适配器，从而其他团队不会被这个变动影响，这样产品级别的变更可以每天持续发生。

在过去，如果车企想生产一辆新车，以面向过程的方法开展工作，从设计到发布量产通常要5～7年左右的时间。但如果你能把一辆车分解成相互独立的两部分，这两部分通过稳固的接口相连，并可以并行开展，这样你就有可能缩短一半的时间。试想一下如果切分成8个模块，那么就有可能把原来的时间缩短为1/8。WIKISpeed就是用这种方式创新了汽车研发过程。

其次，每个模块都有充满责任感的敏捷团队，可以实时对齐目标和节奏并行开展工作，通过持续集成、持续验证、持续反馈、持续改进、持续创新以及自动化技术的不断深入应用，给硬件产品研发敏捷起来。这些敏捷团队更像是组织内的小型创业公司，团队内通常包括采购、财务、法务、机械工程师、电气工程师、软件工程师等交付模块所需要的所有职能，这些成员聚集在一起，在做决策时互相支持，并检视彼此的成果。

我们需要在这些新产品开发和导入的过程中不断基于实际成果获取反馈，来确保每个模块都获取到在当前情况下的实际进展和实现方向，以此推动整个产品的持续创新迭代。如果现在你还是摇头微笑，那让我们看看试着一起造一艘火箭。

对于火箭这个XXXL超大体量的家伙来说，首先就要把这个规模宏大的产品切分成体量适中的几个模块，比如左边助推器、右边助推器以及中央箭体，这样一艘火箭就变成了3个相互独立的L体量大小的模块。

接着继续对这3个模块进行拆分，直至拆分成几十个彼此独立的更小体积模块，每个模块模块之间有明确的接口定义，任何在接口层面的变动都需要自行适配或者提供兼容方案以降低对其他团队的干扰。创新和部署就这样在这几十个小模块所对应的敏捷团队中每天发生，并持续集成在火箭上。

当有新想法或者设计涌现时，在小而美的敏捷团队中大家一起确定如何让这件事儿变得简单、如何完成它以及验证它，同时可能还会一同考虑合规性以及安全性等内容。团队里的每一个成员都持续在为优化而努力，包括流程效率、部件复杂度、软件体积等方方面面的内容。

如果你觉得这是天方夜谭，那么可以去看一下SpaceX的发展过程，现今他们5天以内就可以完成一次包含新版本软件及硬件的火箭发射。

需要注意的一点是，这里没有所谓的设计阶段、研发阶段、测试阶段和部署阶段。从产品到产线的设计从未终止，改进产品和流程的设计是常态且持续的。新的自动化应用也在迭代过程中被持续引入，来提升设计、反馈、测试、组装、验证等方面的速度。让机器做哪些本该机器做的事儿，人员的能力最大程度被释放用于持续创新，同时产品的质量也得到了极大的保证。这便是硬件DevOps，自动化硬件测试及部署安装。

OK，对于硬件敏捷你有哪些看法，又有哪些有趣有效的实践方法呢？欢迎在评论区留言，交流你的经验或者感兴趣的话题。

钟润杰，Roger