敏捷运动与持续工程

2014 年 8 月的 IBM 技术峰会上，IBM 杰出工程师、Rational 系统与软件工程开发首席架构师 Eran Gery 提到了他所做的关于“持续工程”方面的一些工作。“ Continuous Engineering ”中所指的工程并非是软件工程，而是物理工程，目前已经在飞机制造、汽车制造等行业展开应用。本报道将对持续工程的理念和目前的进展进行简单阐述。

物理工程领域的工期是很长的：一部新的汽车车型设计需要 4、5 年，一架飞机的新机型设计需要十年以上。时间都用在哪儿了？IBM 总结了导致物理工程进度缓慢的三大瓶颈所在：

1. 工程链条长，上下游工具太多，各个层面的数据离散，导致工程师如果要有效的掌握、分析数据以做出决策需要花费很多时间
2. 零件完成制作后无法一一测试，为了等待其他部件完成之后才统一测试验证，这部分等待浪费了很多时间
3. 前一个设计的很多经验没有固化，在进行新一个型号的设计时花费了很多时间在重复上一个设计做过的事情上

这三大瓶颈就如同软件交付团队在测试、部署、规划这三个场景一样，如果解决，则能够大大缩短工程的周期。

在软件交付团队中，目前已经有 DevOps 的理念应对，旨在通过统一标准、实时的全链路监控与数据分析、加上自动化的脚本 / 工具构成管理与持续反馈机制，来实现高频率的部署与快速的自动修复。

在物理工程领域，IBM 针对三大瓶颈也分别提出了解决的思路：

1. 上下游工具的接口标准化，将来自建模设计、供应链、工厂等不同环节的不同工具之间联通起来，把不同数据集里面的数据集中的整合起来以供分析
2. 利用软件制作虚拟的模型，对已经做好的物理组件进行测试验证，尽早发现组件设计上的缺陷
3. 建立抽象化的工程原型，提高对已有设计的复用

当然，由于物理条件所限，硬件工程的周期并不一定能像软件那样做到每日交付数次的频率，但目前一些持续工程的实践已经成功将十数年的飞机机型设计周期缩短至四五年。而且，随着物理设备中的软件含量越来越高，我们可以对产品中的软件进行更高频率的升级，持续改善产品。