常常被问到，硬件的敏捷怎么做？2年前我就非常关注这个跨界融合的话题，所以在不同场合发表过自己的观点。前不久，被一个车企客户软件负责人再一次问到了，于是那场访谈变成我说得多、对方聆听的模式。所以我想，还是，写一段文字吧，一来算是把观点系统性总结一下；二来也算是抛砖引玉，在更大范围和读者朋友一起做个交流探讨。

首先申明，这个话题非常大，我的背景局限了我的经验和知识面，一定是挂一漏万，事先给读者打声招呼，读者群体可能分两大类：

• 一类读者是熟悉敏捷的软件背景人士：建议对本文抱着开放心态来阅读，想一下再反驳，或许本文可以给你一些how方面的启示；

• 另一类读者是熟悉硬件产品开发、并不那么熟悉敏捷的小伙伴：建议也要开放，因为有些how部分你肯定比我更专业，希望本文能更多给你why和what方面的启示。

  
  

  
  

0，本文核心框架

首先用下面两张图来概括本文的观点，图一是MVP、精益创业的循环：

图一 MVP的实现路径

图二是乔帮主的“持续交付”双轮模型，其实就是图一MVP的拆解：

• 如果把业务管理看成时间维度上的活动、就是左边一个科学探索环，强调业务创新。

• 如果把工程开发看成空间维度上的活动、就是右边一个快速验证环，强调工程卓越。

图二：持续交付2.0（credit：乔梁）

1，厘清定义：何谓敏捷？何谓硬件、系统、零部件？

在进入两个环如何相辅相成地支持硬件敏捷之前，先厘清本文题中的两个基本定义：何谓敏捷？何谓“硬件”？

首先，何谓敏捷？

它本质上是一种管理哲学，和很多先进的管理哲学殊途同归。敏捷并不是越快越好；而是可以通过快速迭代实现更早交付价值、且强调build in quality，也就是一次性通过FPY（First Pass Yield）；产品开发对业务的影响，可以从以下两方面来理解：

第一，如何保障未来的商业成功？ENSURE FUTURE BUSINESS SUCCESS

产品要大规模可复制：这意味着，我们不得不以最小成本、在给定时间内开发出可靠的产品。这里的可靠是真正的工程术语reliability，是指0到1不够，还有1到1000000。因此要遵循3R原则，如图三左侧。

第二，如何避免带来经济损失？AVOID ECONOMIC DAMAGE

产品要尽量避免技术风险：这意味着，我们可能不得不预测结果，而且几个样件得并行跑，而不再像以前那样，按部就班地一遍一遍瀑布地顺序实施：打样、测试并学习是否有错、再打样。如图三右侧。

图三 硬件开发的3R原则和敏捷的prototype模式其实图三中的3R原则，是硬件敏捷的精髓，也可以看成敏捷版的QCT：

其次，本文题中的“硬件”到底是指什么？

本文指的是相对于纯机械更复杂的软硬件结合产品，包含mechanic+eletronics+SW在一起的“系统”及其包含的零部件（传感器、控制器、执行器等等），比如EMS、ESP这样的电控系统。如果是整车级别的自驾复杂控制系统（system of system），那么依然可以做功能分解，总能分解到软硬件、参数这一级实现层，如图。

图四 系统的拆解，需求工程也遵循此逻辑（根据系统论：系统是分层次的）

2，HOW？硬件敏捷的工程卓越部分

我认为硬件敏捷的工程卓越可以通过以下四个方面来实现。

a，产品工程PE（V模型的需求工程路径和经典PE工具）

工业界人尽皆知的V模型，是产品工程的精髓。系统工程的骨架之美，是指导我们一次性把事情做对：比如按QFD、FAA、DRBFM等方法论来提升效率；其中，FAA（Focus Area Analysis）是用于快速识别和聚焦关键部位的工具；DRBFM（Design Review Based Failure Mode）是针对变更局部做影响分析和设计回顾的工具。

这些工具背后都是非常精益、敏捷的思想。

图五 V模型的分层分解

这里简单分享一个最佳实践：一个被动安全空气气囊ECU产品，为了满足中国五星碰撞法规CNCAP的要求，需要加大电容、加高ECU外壳体等元器件。整个变更项目还是存在不少风险点和不可知因素，团队从立项开始做好了充分规划，灵活采用了FAA、DRBFM、DFMA和仿真等PE工具方法论，总共只花了1年就完成改款从设计到各级V&V的验证，最后成为了全球的一个最佳实践；

图六 一个电控单元设计变更遵循3R原则、灵活运用PE工具的最佳实践

b，系统（同步）工程SE

其实同步工程属于系统工程里的常规方法了，就是从设计之初就引入后面工业化阶段需要有资产投资、有实体产出的诸如工艺、设备、采购、包装、物流等等职能部门，而不是等到很多工作做完，最后做出成品发现不行，甚至可能连需求都是错的。其核心就是避免闭门造车、增加成功率，就和敏捷宣言里Working Software异曲同工。

这里面也有非常丰富的工具箱，比如以DfX为代表：DfE、DfR、DfM等。

图七 体现同步工程的产品工程路径

c，数字技术Digitial Technology

如果我们全流程的看待机器的开发，从概念设计、原型设计、测试验证，整个流程中，最烧钱的地方在哪里？

对于机器与系统的开发，V-Model是普遍被应用的模式，在整个设计与开发阶段，从概念到需求、功能规范、子系统设计再到实现，各个阶段对应都有相应的测试与验证，这个集成测试验证是确保每个流程都能够保证任务的质量与进度得到控制，顺利完成产品整个的研发过程，而这些过程中，真正需要耗费大量成本的往往是测试验证这些过程。

现在有了数字孪生、建模仿真等手段，可以有效减少了费时耗力的长周期测试的长尾部分（20%的测试会用掉80%的时间）。类似的新技术还有virtual ECU的模拟测试，3D打印（增材技术）快速成型，等等，这些数字化手段都能让研发周期得以缩短，成本也得以降低。

图八 通过仿真测试等数字化手段可缩短研发周期（图源：知乎）

d，架构设计：标准化、模块化、平台化

就跟工业柔性生产线一样，研发之所以能快速提供多样化产品组合给不同的用户，其实，只有先标准化、模块化、平台化，才能做到快。也就是先做减法再做加法。

标准化、模块化、平台化的最大好处就是，能够复用reuse、而不是重复造轮子，从而降低风险，而且开发周期短。

图九 架构设计带来的平台化、模块化、标准化是快速、灵活交付的基础

特别是复杂性提高、互相依赖越来越多的情况下，为了提高组织研发工作的韧性和灵活性，好的技术架构显得尤为重要：比如SOA架构。

再比如特斯拉的诸多颠覆式创新，像一体式压铸giga-press，制造端实现了快速、低成本；第三代中央计算EE架构，线束节省到几百米。

图十 特斯拉特别注重common part、减少零部件数量和简化装配工艺

3，HOW？硬件敏捷的管理创新部分

现在来说说管理创新，也就是敏捷可以如何应用到硬件领域。

- 产品思维VS.项目思维

硬件之所以要敏捷，就是拥抱变化、响应变化，是要快速交付价值并得到反馈和验证。那么和过去市场驱动不同，我们更多需要引入新技术、来进行产品驱动，引领市场而不是跟随者。于是，从用户画像、需求挖掘、产品愿景到MVP再一步步迭代完善，就特别重要。

- 组织形式：

SCRUM、Sportify、SAFe本身就是不错的系统性实践框架。哪怕小到站会、看板、需求backlog、回顾、用户故事、AC（Acceptance Criteria），这些日常工作的标准化做法，也非常适合引入到硬件敏捷项目管理。

对比一下，同样是需求表达，为了避免模棱两可的现象，硬件领域以前我们被要求遵循4C原则（Complete，Clear，Correct，Consistent），但是怎么做到，并不清楚，对于成熟度低的开发团队就很要命了；相对而言，软件敏捷开发的user story的表述范式更易于掌握；再比如需求的排序方法，来自软件领域的WSJF就非常可操作，都非常适合借鉴到硬件领域，诸如此类的例子还很多。我一直说，软件敏捷开发方法把人们尤其是不成熟的团队从大的足球场框到小一点的足球场（像2周一个sprint的时间盒就能很好地解决学生症候群），规范了人们的行为。

图十一  需求表达：4C原则 VS. 用户故事

- 管理原则：

更主要的是，敏捷脱胎于精益，而精益价值流的概念应用在研发端，是非常有用武之地的，通过价值流识别VSI、价值流分析VSM、价值流设计VSD，能很好地识别重大浪费和不合理，从而找到优化和改善点，极大提升研发效率，比如现在我们在辅导的多家车企客户，都在应用这个方法、反馈效果很好。

- 决策模式：

Cynefine及CAS：与时俱进，科学管理有其局限性，现在越来越需要CAS来应对VUCA。即去中心化的决策机制，响应更快。这部分对人的影响是最大的。无论软件工程师还是硬件/系统工程师，其实最终都希望通过敏捷理念赋能每个人，就是人人都是thinker + doer；如此，实现学习型组织，充分拥抱变化、快速响应变化。

图十二  敏捷转型的终极目标：学习型组织

4，最后的畅想

敏捷在硬件领域会有更多形态，因其跨学科的多样（材料、化学、等）造成的组合就是好几个数量级的差别、同时约束更多，试错成本相对高。软件世界本质上是计算机能解决的，但并不是世界上所有问题都能通过计算机解决。从比特世界来到原子世界，从数学世界来到物理世界，我们需要面对的是更复杂的组合：跨学科、约束更多、软硬件一起，多物理学科。

这也就不难理解为什么马斯克说，对于特斯拉这样一家软件牛逼的造车公司而言，99%的疑难杂症来自于批量生产了。

可能需要更多的创新，技术的创新，流程的创新，管理方法的创新。没有敬畏感，那么必然就会像诸多厂家的案例那样，TAKATA因为技术问题彻底破产、特斯拉最近的电子件召回和小鹏的断轴，都出过事故；但是太有敬畏感，也不行，反倒束缚了创新的手脚。总之，在更广阔的物理世界，人类的产品开发这种创造性活动如果得到敏捷的加持，一定会绽放出更多创新的智慧之花。

图十三  不是所有问题都能通过计算机或人工智能解决（credit：吴军）