1 软件定义时代已经来临

       软件作为产品的一部分，与硬件组合在一起提供特定的产品功能，已不稀奇。我们称之为“嵌入式软件或系统”，它是计算机化的软件系统，嵌入在计算机外的硬件设备中，旨在完成一组特定的任务或操作。业界广泛认可的第一款嵌入式软件系统是阿波罗制导计算机（AGC），它是由麻省理工学院于1965年为NASA的阿波罗计划开发，用于控制太空任务期间使用的所有机载设备，使航天器能够执行复杂的计算和控制操作。AGC有四个处理器板和五个内存模块，每个模块包含70KB内存。它使用先进的软件和硬件组合来运行其程序，其中包括制导、导航和控制系统，在任务期间提供了前所未有的准确性和精确度。随后，Intel公司于1971年发布了第一款微处理器C4004，这是嵌入式软件系统发展的重要里程碑，它使得嵌入式软件系统摆脱了计算机的限制，开始以独立的计算单元形式嵌入到不同的硬件设备中，开创了嵌入式系统应用的新时代。到2000年初期，嵌入式系统逐渐演进为嵌入式微型计算机，并被广泛应用于大到汽车、高铁和飞机，小到手机和家用电器等各种产品当中。

       过去十几年来，计算机和智能手机得到了前所未有的迅猛发展，将硬件的标准化和摩尔定律发挥到了极限，人们开始将持续创新的焦点从硬件转向软件。“软件定义产品”这一概念逐渐开始流行起来。时至今日，我们所谈到的“软件定义产品”已经演进成为一种专注于软件创新而非硬件的新型产品——软件开始成为产品的核心，且无需硬件的升级换代，用户就可以持续享受产品的新功能。“软件定义产品”最为大众所熟知和津津乐道的是在汽车行业，即“软件定义汽车”。

       根据大众汽车在2020年的预测，当时一辆车上最多约集成了1亿行代码，而到2025年一辆车上将集成多达10亿行代码。10亿行代码相当于是谷歌与Facebook之间的互联网或软件公司量级。当汽车的软件代码达到10亿行量级时，汽车公司就成为了一家不折不扣的软件公司。大众汽车前CEO赫伯特·迪斯（Herbert Diess）预测，汽车行业的创新将有90%以上来源于软件。普华永道在《打造软件驱动的汽车企业》报告中指出：“未来几年内汽车产业、产品和相关服务，将随着智能与互联功能方面需求的大幅增加而迎来重大改变。尤其是软件，已成为现代车辆差异化竞争的核心，而软件开发的成本，将在未来十年内增长83%。”麦肯锡预计到2030年软件成本占整车成本将从现在的15%上升到60%。由此可见，软件定义时代已经来临。

2 软件定义时代企业面临的挑战

       正如德勤所指出的，在“软件定义”时代，变化的不仅仅是简单的产品中软件的比重，其本质是产品从高度集成的机电终端，转变为智能化、可扩展、可持续迭代升级的移动电子终端。

       为实现这一最终目标，软硬件将被进一步解耦，硬件结构部分将进行极致的标准化和模块化，并将超前的硬件功能预埋在产品中，通过持续迭代升级的软件来逐步释放新功能，使得用户能够在无需任何硬件升级换代的前提下就能够持续享受创新的应用体验。

       特斯拉是这一理念的大力倡导者，并率先将其付诸实践。2012年，特斯拉推出Model S时首次发布了软件空中升级（Software Over-The-Air，简称SOTA）功能，使得车辆可以远程升级车机娱乐系统和应用软件，如导航系统、人机交互界面等。2017年发布Model 3时进一步推出了固件空中升级（Firmware Over-The-Air，简称FOTA）功能，可实现对系统固件的远程在线升级，再一次为业界树立了新的标准。FOTA升级是对汽车全方位的升级，涉及底层硬件和电子控制单元（Electronic Control Unit，简称ECU）等相关控制软件的远程在线升级，如辅助驾驶功能、底盘悬架、车身控制等软件系统，其难度、复杂度，以及对车辆的安全影响等要远远高于SOTA升级。

       在这一趋势下，企业商业模式和盈利模式发生了变化。特斯拉于2019年开始尝试OTA付费升级，车主以9.9美元/月的价格购买娱乐性和实用性软件的更新服务；2021年，特斯拉推出了自动驾驶软件选装包服务，推出EAP（Enhanced AutoPilot，增强辅助驾驶）和FSD（Full Self-Driving，完全自动驾驶）两套不同级别的自动驾驶选装套件，支持用户一次性买断或按月订阅付费模式。据高盛预测，特斯拉的FSD软件虽然仍处于Beta测试阶段，但年收入已达到10亿至30亿美元。到2030年，特斯拉FSD等软件每年收入将达到100亿至750亿美元。考虑到特斯拉2022年的总收入为815亿美元，这是一个非常惊人的数字。特斯拉表示，FSD的长期毛利率可高达90%。作为对比，其历年来卖车所得最高毛利率仅为32.9%。由此可见，在“软件定义”时代，软件服务收入在企业的营收和利润占比中开始扮演重要的角色，企业需要重新审视其商业模式和产品策略。

       显而易见的是，“软件定义产品”引发的产品电子电气架构（Electronic & Electrical Architecture，以下简称E/E）的革命性变革，也将带来产品研发模式的变革。

       简单来说，传统的汽车E/E架构往往是采用以ECU为核心的分布式架构，即传感器、ECU和执行器一一对应，以保证各个系统的独立性和抗干扰性。一般一辆汽车由几十个乃至上百个ECU组成。随着车辆的智能化程度越来越高，车上传感器数量不断增加，随之而来的是ECU数量也在不断增加。智能网络、自动驾驶等技术给整车开发带来的巨大考验就是爆炸式的数据处理需求和更高的运算速度。因此，传统的分布式E/E架构，无论是运算能力和数据处理能力，还是车载网络带宽和传输效率等都无法满足自动驾驶和智能网联技术的要求。譬如在自动驾驶多传感器融合方案下，需要实时处理和融合来自不同传感器的信息（如摄像头、激光雷达、毫米波雷达等），然后进行实时计算和分析，并辅助驾驶控制或安全预警，这就需要更高的运算能力和通讯带宽，而传统的分布式E/E架构显然已经无法满足这些需求。因此，汽车E/E架构开始由传统的分布式逐步走向中央化集中式、以云计算为基础的架构。图1是德勤及博世汽车电子给出的汽车E/E架构演进路线图。
 
       德勤指出，汽车E/E架构将经历三个演变周期：即集成化、域集中式和中央集中式。集成化是指通过ECU的升级换代，使得一个ECU能够控制多个传感器，承载多项功能，从而达到降低ECU数量的效果，但无法满足L2级以上自动驾驶对算力和通信效率的需求。域集中式则是将汽车电子按功能划分为几个大域，如动力域、座舱域、自动驾驶域等，将分散的ECU集中到域控制器（Domain Controller Unit, 简称DCU）中，以提供更高的运算能力和通信网络带宽，且更易于实现OTA软件升级。而中央集中式则通过车载中央计算平台，作为决策和控制中心，统一调度各个传感器和执行单元，并直接面向前端应用和服务。中央集中式架构极大地实现了软硬件解耦，软件直接部署在中央计算平台，可支持整车软件的OTA升级。然而，中央集中式架构在量产开发过程中，软件开发的规模和难度激增，面临技术复杂度、组织体系、开发模式、开发周期等多维度挑战，不仅要解决多核异构芯片的软件部署，还要涉及跨域融合的多个域控制器软件开发。因此为了降低开发难度，大幅提高开发效率，需要将开发视图从域控制器层面向整车层面迁移，并提供一体化的开发平台、开发视图与开发方法。与此同时，为提升软件功能的重用性和可扩展性，车载软件技术架构也将由传统的面向信号的分布式架构向基于统一平台的分层化、服务化架构转变。

       特斯拉于2019年率先在Model 3车型中采用中央集中式架构，国内新能源车企也正在经历从域集中式架构向中央集中式架构转型的过程。同样，其他行业也提出了类似的概念，如“软件定义风机”、“软件定义工程机械”等。

3 从敏捷软件开发到敏捷产品开发

       由于在“软件定义产品”时代，产品创新更多地依赖于软件的创新，因此产品研发模式也必然从传统的硬件优先过渡到软件优先的产品开发方法，即所谓的“软件定义开发模式”。

       简单来说，软件定义开发模式就是在产品开发过程中，以软件开发为主，通过采用敏捷软件开发和基于DevOps的数字化部署运营相结合的方法，构建以软件开发，以及持续集、测试、部署（CI/CT/CD）为核心的产品数字主线，从而实现产品开发、测试和运营等过程的深度融合。
 
       显而易见，与传统的硬件优先产品开发模式相比，软件定义产品开发模式具有诸多的显著的优势和特点。

       首先，通过软件功能与硬件解耦，产品软件逐渐由固化在专用微处理器的嵌入式程序，整合为基于服务架构（SOA）、开放可扩展的软件平台，使开发人员能够更专注于应用程序开发和软件功能创新。

       其次，提供兼容不同硬件的应用程序可移植性，极大地简化了面向跨硬件平台的软件开发、测试和部署，并使制造商更容易更换升级过时或不可用的硬件组件。

       第三，通过软件在线应用商店和产品功能的服务化，可以通过基于云的在线更新实现产品的持续升级或功能优化，在提升用户体验和满意度的同时，也为企业带来了新的盈利模式。

       最后，新的模式能够加速人工智能(AI)和云计算等新技术在产品中的应用，并可通过简单有效的方法来更新、配置和扩展产品中的人工智能模型，而无需进行昂贵且耗时的硬件升级。

       随着软件定义产品开发模式被应用，产品的整个研发模式将面临转型升级——软硬件一体化的敏捷产品开发方法成为其中的关键。

       在传统的产品开发模式里，软件和硬件是错综复杂地连接在一起的。开发人员为确保软件和硬件之间的完美集成，除了在开发过程中需要与硬件开发人员进行频繁的沟通协作，还需要通过物理样机进行大量的功能测试和集成测试，以确保终端、设备驱动程序和应用程序之间的交互逻辑能够按预期运作。在软件定义产品开发模式下，软硬件得到充分解耦，软硬件之间采用通用、标准的通讯和控制协议进行交互，软件开始转变为面向服务的、平台化开发架构。为提升软件开发运维协作效率，缩短软件研发周期，提高软件质量，制造商开始引入在软件工程领域备受推崇的敏捷开发和基于DevOps的持续集成部署方法。SAFe（Scaled Agile Framework）敏捷开发方法提出了敏捷发布火车（Agile Release Train）概念，它将多个开发团队协同起来，按照固定的时间间隔（通常为几周或几个月）发布软件产品或服务。敏捷版本火车的每一节车厢可以认为是一个分工明确又相对独立的开发团队，各个团队需要按照预期计划在指定时间将各自的开发功能发布到指定站点（PI, Program increment）的版本火车上，共同交付同一个价值流中的一个或多个解决方案，如图3所示。这有助于加强产品不同开发团队之间的协作，以快速响应不断变化的市场需求，并在竞争中保持领先地位。

       在产品开发过程中应用敏捷开发框架，需要从产品视角进行通盘考虑，除了软件工程领域之外，还需要兼顾硬件和机械工程领域。与硬件相比，软件的研发即生产过程，没有后续的生产制造供应链等一系列活动，但有着持续的运营和迭代。而硬件和机械工程领域，由于其开发过程复杂，涉及业务环节过多，开发周期长，矩阵式开发组织架构等因素，使得敏捷方法一直难以得到大规模应用。鉴于此，很多人认为硬件产品开发不适合采用敏捷开发方法。然而，事实并非如此。哈佛商业评论于2016年发表的《The secret history of agile innovation》中揭示了敏捷方法在企业中应用最早可追溯至20世纪30年代的贝尔实验室，主要应用于硬件开发实践。至20世纪90年代，随着初创公司和大型组织都在寻求变得更灵活，以应对动荡的环境，敏捷思想才真正开始得到企业重视。到2001年《敏捷宣言》诞生后，敏捷方法在软件工程领域得到了广泛应用和验证，才逐渐为大家所熟知。由此可见，并不是敏捷方法不适用于硬件产品开发，而是其应用难度要大于软件敏捷开发过程。

       时至今日，随着数字化技术的蓬勃发展和成熟应用，敏捷产品开发再次成为行业领导者的关注焦点。很多企业开始构建面向产品的BizDevOps方法体系，将软硬件一体化的敏捷产品开发方法作为企业数字化战略的重要一环。
 
       宝马汽车早在2018年就提出在整车开发过程中引入BizDevOps方法，开启了向敏捷产品开发的转型，即通过业务、开发和运营团队的密切协作，以产品和专业领域为导向，构建连续、一致的工程数据流，加速和优化产品开发和交付流程，实现端到端的持续集成、开发和部署运营，以及全过程、360º的实时透明可视化。

       戴姆勒（Daimler）公司于2020年提出软件驱动的敏捷产品开发战略，通过构建面向多专业、全寿期的数字产品原型，打造敏捷的协作流程体系和产品开发组织架构，在数字样机+数字孪生环境中敏捷迭代完成系统/子系统、到机电软传统等多专业级的虚拟仿真验证过程，取代90%的物理样机功能，从而提升多专业、上下流协作效率，使得首车上市时间缩短12个月，且首车下线即达到可交付状态。

4 软件驱动的数字化创新转型

       由此，敏捷产品开发已经成为“软件定义产品”行业进行数字化转型的战略重心，必将引发新一轮的业务变革。经过深入分析国内外企业敏捷产品开发案例，结合多年的行业经验，我们发现对于应用企业而言，采用敏捷产品开发模式往往重点专注于两个方面的转型，即“向左转”和“向右转”。
 
       “向左转”注重于研发模式的创新转型，即采用BizDevOps策略实施敏捷产品开发和交付流程，在产品早期建立多专业、跨领域的敏捷组织模型，根据明确定义的业务策略和产品架构，制定详细的产品开发路线图，并基于此各团队开展敏捷开发、持续集成、持续测试和部署工作。“向左转”其实就是将物理样机阶段执行的试验等各项工作尽量往左移，即利用数字样机、数据驱动仿真和数字孪生等技术，构建持续的、一致的面向全寿期的产品数字原型，并逐级分解和定义基于模型的多专业、上下游之间的协作机制和协作流程，从而驱动硬件由传统串行的、瀑布式开发模式转向敏捷迭代开发模式，有效提升产品研发过程的并行协同效率，缩短硬件结构迭代周期。

       而“向右转”则注重于商业模式的创新转型，即利用OTA和云计算技术，在实现部署灵活性，保持产品持续更新，为用户提供增值服务的同时，也为制造商带来了新的盈利模式。OTA和云计算架构，更易于实现业务和流程的集成，以及海量数据的分析应用，是数字孪生技术蓬勃发展的土壤。数字孪生，即物理产品或流程在数字空间的完整数字化表达，是人工智能和产品的深度融合，将为制造商带来更多的创新和想象空间，为产品创新和持续改进提供源源不断的连续数据流。数字孪生将进一步促进产品运营模式的转型，使产品即服务（Product As A Service）成为现实，产品或软件可以按使用情况收费。数字孪生的主要优点是可以实现机理模型和机器学习模型的融合，前期以仿真机理模型为基础，利用大量物理样机的测试数据来训练产品在各种场景的性能、可靠性和安全性等仿真分析模型，然后通过产品数字孪生模型进行多维度的展示。随着训练数据量的不断增加，这些数字孪生模型逐渐逼近真实物理场景，将逐步替代物理试验过程，从而大大提升仿真试验迭代效率，降低试验成本。这样的数字孪生模型还可以延伸到产品运营和维修维护过程中，为用户提供预测性维护和智能故障诊断等功能，持续优化产品性能，提升运营效率，同时也为孪生模型提供海量的数据样本进行自我迭代更新。这些数字孪生产品还可以连接分布在全球的每一台设备，基于其实时工况仿真分析设备健康状况，提前预测未来可能发生的问题或故障。
 
       当然，目前数字孪生并不能完全取代物理样机，如民用客机的试飞取证过程，汽车安全合规强制要求的实车碰撞试验等。但毫无疑问，数字孪生将成为已交付产品与企业内部开发团队之间的桥梁和纽带，加速产品的敏捷开发和交付流程，促进企业进一步“向左转型”。数字孪生技术最终将会使企业“向右转型”和“向左转型”无缝衔接，实现敏捷产品开发和持续部署运营的无限循环迭代过程。

5 企业应该如何推进敏捷化转型

       然而，对传统企业而言，从硬件优先方法向软件驱动的敏捷产品开发方法转型（简称敏捷化转型）仍然具有很大的挑战性。有效的敏捷化转型既要保留软件的敏捷原则，即灵活性、渐进式开发和持续迭代，同时还需要兼顾产品和业务的硬件特性进行量身定制，如制造、供应链、硬件在环测试等。

       企业必须要清醒认识到敏捷化转型是一项至关重要的数字化转型战略，不仅仅是采用一种新的开发方法和技术，而是涉及到产品战略、开发流程、组织架构等方方面面的变革转型，需要企业高层对此进行长期持续的投入和关注，甚至上升为企业“一把手”工程。同时，还需要制定自顶向下的转型战略和转型路线图，打造敏捷组织架构，重塑敏捷的产品开发流程，采用适当的敏捷数字化技术和工具，引入BizDevOps方法进行持续集成、部署和应用。

       5.1 敏捷产品开发战略

       敏捷产品开发的最终目标是更快、更高效地创造令客户满意的产品，同时为企业创造价值。为此，需要与利益相关者合作制定产品策略，并设定共同的组织目标和愿景，确保获得组织内的一致认可、支持和协作，并以此来指导业务和运营决策。然后，通过优先考虑不同的业务举措来确定如何实施该战略及其相关目标，其中许多举措是他们可以通过定量和定性分析来确定的，最后以产品路线图形式呈现给利益相关者和产品开发团队。

       5.2 敏捷产品开发流程

       在敏捷开发方法中，产品开发团队往往专注于快速迭代和验证确认。因此，需要将产品开发流程分解为1-2周的具有明确交付成果和截止日期的冲刺迭代（Sprint）。然而，传统的硬件瀑布式开发过程中，往往通过阶段性的里程碑来指导和管理交付以及上下游之间的协作，如立项论证、概念设计、详细设计、仿真验证、样机试制等。这样的里程碑往往需要历时几个月乃至一年，用于指导总体开发进度和资源配套计划尚可，却无法用于指导详细的迭代开发工作。业界最佳实践是将两者结合，即阶段性流程提供项目路标和里程碑目标，同时每个里程碑内又分解为多个2-4周的迭代和增量流程，用于指导日常的开发和协作。

       5.3 敏捷组织架构

       敏捷型组织架构与传统矩阵式组织最大的不同在于，矩阵式组织的项目团队来自于不同的职能部门，他们会随着新项目或新业务目标而频繁变化，项目完成团队也即解散。而敏捷型组织以产品为核心，组建跨职能、多专业、稳定且完整的项目团队，围绕核心项目目标，以持续的方式开展工作和交付成果。能够随时响应市场和用户需求的变化。

       值得注意的是，敏捷是一项有利于授权团队的原则，这些团队可以自主创新并创造令客户满意的产品。它还意味着一个能够快速响应市场和用户需求变化、灵活适应技术变化的学习型组织。不难发现，敏捷型组织更有利于沉淀和重用专业领域知识，形成企业最佳实践，同时发挥每个人的优势，并使工作更加高效。

       5.4 敏捷数字化技术

       在敏捷化转型过程中，采用一系列的数字化工具和系统也是不可或缺的一环，能帮助团队提升研发效率，提高交付质量。这些工具和系统五花八门，有跟产品开发过程密切相关的专业工具系统，如产品需求管理和端到端追溯的，管理软件代码和测试用例的，产品缺陷管理和闭环跟踪的，以及支持持续集成/测试/部署的工具等等。还有跟协作效率有关的，如各种促进数据共享的协作工具、知识共享平台等，以简化工作并创造更具响应性和开放性的协作环境。企业需要根据自身产品和业务特点，根据优先级和紧迫度来选择合适的数字化工具和系统，加速企业的敏捷化转型进程。

       5.5 BizDevOps部署应用策略

       在敏捷化转型过程中，还需要引入BizDevOps理念，将整个转型过程当做一个敏捷迭代的项目来处理，以核心产品和业务战略为指引，规划3-5年的转型路线图，并分解成几周到月的Sprint来指导具体工作的执行和交付。同时，在部署推广过程中，也需要借鉴敏捷思想，采用“试点-验证-推广”小步快跑、敏捷试错的应用部署策略，既保证快速获得预期价值，又能够在发现问题时快速响应，并及时作出调整。

       综上所述，敏捷化转型通常需要几年甚至更长的时间，但敏捷试点应用可以快速交付可预期的成果和价值，以证明这种转变是否值得持续投入。一旦在某一点得到验证和认可后，工程师就会从中获得信心，转型就会获得动力。

6 敏捷产品开发案例分析

       6.1 全球领先商用车企业敏捷产品开发实践

       某全球领先的商用车企业在推进企业数字化转型过程中，引入了SAFe（规模化敏捷框架），探索平台化产品的敏捷开发方法。

       梳理产品敏捷开发方法伊始，企业重点思考了三个问题：

       软件领域敏捷开发的关键特征是什么？

       基于平台的产品开发的最佳实践是什么？

       如何将敏捷开发与平台化产品开发融合？

       经过内部跨部门的研讨，该企业认为在保证产品开发过程可追溯性的同时，借鉴Scrum方法，组建敏捷开发团队，以敏捷任务管理方式推动团队内高效协同协作，加快开发、仿真、测试到交付的迭代效率。

       新车型平台中，企业规划面向各车型增加全新的碰撞预警系统。该系统需要在前格栅处增加雷达模块，需要更新软件算法，并在仪表盘或抬头显示系统增加预警信息显示，涉及了机电软多个专业领域。该功能的开发交付过程中，企业应用了全新的敏捷开发方法，大幅提高了开发效率。

       1）战略组合定义与分解：企业从发展战略及投资组合角度进行需求定义，并逐层进行分解细化，形成系统及组件级开发需求，分配到不同敏捷开发任务中；

       2）模块规划与平台架构更新：平台开发人员接收到开发需求，因需要引入新模块或变更现有模块，将对平台架构进行分析、更新；

       3）系统建模与影响分析：开发主管基于需求模型进行功能规划，设计逻辑模型，并评估新功能对硬件及相关软件的影响，确定设计方案，细化各组件技术规格，分配到多个Sprint中；

       4）硬件设计与验证：硬件开发人员应用在线协同设计工具进行硬件组件开发，实时与内部其他团队、与外部供应商沟通，实时进行仿真验证，完成一次设计任务后及时更新敏捷任务状态；

       5）软件开发与测试：软件开发人员基于开发需求进行建模及代码开发，并应用CI流水线进行集成测试；

       6）集成测试与发布：软硬件相应的Sprint发布，自动形成需求满足度报告，构建基线，向下游试制、制造环节发布交付物，以及工程变更时进行问题追溯及影响性评估。
 
       方案实现过程中，除了全面引入敏捷思想外，企业在软件开发过程中依托新一代ALM-PTC Codebeamer导入了平台化思想。一方面，针对软件对象业务模板进行了分级管理，设置平台、车型、项目自上而下三个级别，下级对象可以继承上级对象业务模板，如合规要求、版本规则、工作流程等。同时，车型开发、项目开发还可根据个性需求对业务模板进行裁剪、修订，既实现了企业级统一规范、统一管理的要求，又满足了项目开发具备的灵活性要求。

       另一方面，碰撞预警功能开发完成后发布为平台项目基线，未来新车型项目开发支持基于平台的重用。开发经理复用平台基线中需求、模型、代码、测试用例等全过程数据，并与平台项目链接，便于软件功能升级。例如，平台项目进行bug修复，所有车型项目均将同步更新；某车型项目导入新需求，经评审后合并至平台项目，更新软件平台。软件的平台化重用，将显著提高开发效率降低管理成本，并改善软件质量。

       6.2 工业装备行业敏捷产品开发实践

       某全球领先的气动和电驱动技术和解决方案供应商，业务涉及汽车、电子、生命科学等百余个行业，在该企业的数字化蓝图中，ALM与PLM是产品开发价值链的核心平台。该企业基于ALM与PLM平台对开发流程进行了优化和革新，建立了“敏捷发布火车”开发体系，支持产品级别的敏捷开发流程。
 
       在全新的自动化机械臂开发项目中，该企业导入规模化敏捷的框架，将开发过程进行了分解。将一年内的开发任务分解为4个PI（Program Increment），每个PI又可分解为4个Sprint，每个Sprint以3周为迭代周期，由对应的敏捷开发团队负责进行开发、测试、交付。每个Sprint代表一个开发闭环，开发团队从ALM平台中获取、更新开发需求，在PLM平台中管理、更新设计方案，发布设计模型进行仿真及测试，最终交付。

       “以客户为中心”，是该企业拥抱敏捷开发流程最重要的驱动力。通过敏捷开发流程，在产品开发过程中始终聚焦客户需求，并能够尽早验证客户需求，围绕客户需求进行持续、快速的设计迭代，提高客户满意度，提高产品竞争力。

       6.3 国内某知名新能源车品牌案例

       我国汽车行业正在积极拥抱“软件定义汽车”时代，众多车企都在电动化转型的基础上大规模引进软件人才，组建软件开发团队，应对汽车产品智能化的趋势。我国某头部新能源车企从创立伊始，即已嗅到了软件之于未来汽车产品的重要性，将“软件定义创新”融入到了企业基因中。

       该车企是我国某传统车企独立的新能源业务板块，拥有独立的品牌、独立的团队、独立的管理体系。企业认为，汽车产品的智能化水平将成为未来消费者购车的重要因素，汽车不再是“交付及巅峰”、“不破不修”，而应该是具有丰富的用户体验，多样化的功能，并能够“常用常新”、“千人千面”。这背后意味着，软件开发能力将成为车企的核心竞争力，车企研发的重心应从硬件转移到软硬件并重。

       因此，该车企实施了一系列举措，全面推进“软件驱动创新”转型。

       1）架构创新——企业自研了全新EEA（电子电气架构）架构，硬件方面适应新能源车的结构特点，进行ECU整合，有助于算力升级，软件开发及更新升级；

       2）流程创新——在符合ASPICE、ISO 26262等传统标准及行业合规性要求的同时，引入敏捷开发思想，形成“瀑布+敏捷”的混合开发流程，支持智能座舱、智能驾驶业务的开发与迭代；

       3）工具创新——引入一系列工具链软件，构建CI/CD平台，提高软件开发、测试、发布效率；引入新一代ALM（应用软件生命周期管理）平台，对软件开发全过程，有效保障软件开发的质量。

       经过不断地探索与实践，该企业的转型之路得到了市场的认可与积极的评价，品牌销量居于新能源市场领先水平，车型智能化配置丰富，用户口碑出众。“软件定义汽车”变革是一场长跑，企业赢得了起跑，但要想跑的更快，跑的更远，还将继续坚定投入，坚持“软件驱动创新”的转型之旅。

7 结束语

       过去五年来，麦肯锡对来自20多家经历敏捷转型的企业进行了一项统计分析，结果指出：在汽车、消费电子、工业工程和医疗设备等行业，经历敏捷转型的上市公司在一系列研发指标上取得了不低于20%的绩效提升，包括上市时间、质量、生产力和员工满意度等。在某些情况下，上市时间和工作效率提高了60%。我们预测，未来5-10年，敏捷化转型将成为推动制造业转型升级的新一波浪潮。

参考文献

       [1] Herbert Diess, VW's annual press conference, https://www.volkswagen-group.com/en/annual-media-conference-and-capital-markets-day-2019-17416
       [2] Herbert Diess, VW's annual press conference, https://www.volkswagen-group.com/en/annual-media-conference-and-capital-markets-day-2019-17416
       [3] Mickinsey, Ondrej Burkac, Outlook on the automotive software and electronics market through 2030, 2023.
       [4] 德勤, Software-Defined Vehicles – A Forthcoming Industrial Evolution, 2021.
       [5] Yahoo Finance, Tesla's Full Self-Driving is already worth $1B-$3B in sales, with upside to $75B by 2030: Goldman, 2023.
       [6] 德勤, Software-Defined Vehicles – A Forthcoming Industrial Evolution, 2021.
       [7] Darrell Rigby, The secret history of agile innovation, Harvard Business Review, 2016.
       [8] Mckinsey, It’s coming home: The return of agile hardware product development, https://www.mckinsey.com/capabilities/operations/our-insights/its-coming-home-the-return-of-agile-hardware-product-development, 2023.