软件正在迅速重塑汽车行业的关键转折点

菏泽炫佑科技

软件正在迅速重塑汽车行业的关键转折点

软件正在迅速重塑汽车行业。 近年来，行业的四次颠覆浪潮——自动驾驶、互联、电气化和共享（ACES）——都严重依赖先进的软件。 这些领域未来将迎来更具颠覆性的发展。 整个行业的原始设备制造商、供应商和新公司希望能够掌握这个新的软件驱动价值链中的关键控制点。

软件：关键的行业转折点

随着行业格局的变化，缺乏软件能力的车企将面临重大风险，包括量产（SOP）延迟和预算超支等。 如果他们能够更快地将更新的产品推向市场，他们甚至可能落后于竞争对手和新进入者。 更糟糕的是，软件问题可能会导致大规模召回，或者让汽车公司无法防范黑客造成的客户安全风险。

我们的研究表明，软件能力强的公司和软件能力弱的公司之间的差距很大，能力*强的公司报告的产出和质量比能力*低的公司高出三到六倍1。 这种开发效率差距比不同能力的硬件制造商之间可能出现的差距要大得多。 许多车企已经意识到强大的软件开发能力所带来的各种优势，并正在采取大刀阔斧的措施来提高自己的业绩。 一些车企计划在未来几年提升软件能力，招聘数千名软件工程师； 其他人将重新定义治理模式，建立伙伴关系，并在全球范围内推动软件开发卓越中心。

然而，我们认为这些措施还不够，因为只有当车企更新软件开发的基本运营模式时，真正的改变才会到来。 根据我们的研究，只有 40% 的汽车研发领导者将软件视为主要颠覆者，认为他们已经为必要的运营变革做好了准备。 尽管一些领先的汽车公司在软件工程实践方面取得了长足进步，但大多数仍远远落后于领先者。 目前车企的问题集中在几个方面：敏捷实践、持续集成、自动化测试。

软件开发转型的风险如此之大，车企必须重新思考一整套软件开发方法，包括基本的运营模式。 本文分享了我们通过与汽车制造商、供应商和生态系统中的其他合作伙伴密切合作获得的关键概念和见解。 这些见解基于对技术专家的广泛采访以及使用麦肯锡专有数据库进行的大规模基准测试。

让数字说明一切：软件的重要性如何后来居上

这一痛苦的趋势凸显了汽车软件日益增长的重要性。 **个趋势与软件和电气/电子市场的快速扩张有关，预计2020年至2030年将实现12%的复合年增长率——是普通汽车销量预期增长率的三倍以上。 多个领域正在经历*强劲的增长，包括软件功能（复合年增长率 11%）和集成测试（复合年增长率 12%）。

复杂度持续上升，但开发效率进步缓慢

无论是功能层面还是架构层面，汽车软件的复杂性都在增加，但开发工作的效率却没有跟上。 我们的研究表明，过去十年软件复杂度增加了四倍，而软件开发效率仅增加了1到1.5倍。 这个问题在信息娱乐系统和高级驾驶辅助系统 (ADAS) 等变得越来越复杂的大型模块中*为严重。 与传统的深度嵌入式软件相比，开发这些模块的效率大约低25%至35%。

这种不断扩大的差距可能会影响汽车公司未来的成功。 车企需要在软件生命周期内投入更多的资源来开发软件和维护软件，这可能会削弱其创新和应对竞争对手的能力。 一位企业负责人在采访中注意到，如果复杂性不断增加而效率不变，仅靠软件维护就会很快耗尽所有软件开发资源，没有创新的空间。 。 *终，复杂性和效率之间的差距将削弱成本竞争力，导致严重的财务和声誉问题。

可以看出，软件开发能力排名前25%的企业，其效率比垫底的企业高3倍，生产力高3.5倍，质量高6倍。 因此，他们的产品上市时间更短，各个软件功能级别的开发成本也更低。

在硬件方面，强弱企业之间的业绩差距相对不太明显，因此在该领域追求差异化的机会较少。

降低复杂性，同时提高效率

为了在这个快速变化的环境中取得成功，公司应该通过减少开发和维护软件所需的工作来尽量减少复杂性。 该策略涉及限制每个平台和生命周期阶段的功能和特性的版本数量。 同时，企业必须增加组件的重复利用。 至于开发效率，企业应尽量将软件开发速度与数字原生企业相匹配，以提高开发效率。 由于软件创新的整体水平不会下降，因此公司还必须增加软件开发和维护的产出，以便提供在市场上取得成功所需的产品和服务。

降低复杂性和提高效率需要一个新的软件运营模型，重点关注四个维度：

（1）开发什么软件，包括架构、设计以及各种需求；

（2）该软件是在哪里开发的，是公司内哪个部门开发的，包括当地的人才和合作关系；

(3)如何开发软件。 该维度考虑开发工作的方法论，例如大规模敏捷开发，或者开发和测试流程的变化；

（4）采用什么方法来促进软件开发，包括性能管理和工具链基础设施。

**个维度——开发什么软件——重点是通过模块化和解耦的硬件/软件架构、以用户为中心的设计和需求管理来降低开发复杂性。 其他三个维度侧重于通过提供适当的结构、流程和基础设施来提高软件开发的效率。 我们从四个维度出发，确定了 11 个*佳实践，可以帮助车企成功解决所面临的软件挑战。 理想情况下，公司将同时解决所有方面的问题。

A. 开发什么软件：架构、设计和各种需求

在新的运营模式下，企业必须将软件相关的发展目标和商业机会转化为产品、功能和模块层面上可行的架构、产品和组合需求。 通过这个过程，企业可以更多地了解可以为他们创造价值的软件类型。 这一过程还将帮助企业降低架构的复杂性，应用以用户为中心的设计流程，并改进软件需求的管理。

A1。 降低架构复杂度

根据我们的研究，如果汽车软件模块化程度不够，就会增加设计的复杂性，增加项目的整体难度。 此外，汽车软件的架构组件边界通常不太理想，这可能会导致更多的相互依赖性，并呈指数级增加开发人员在添加新功能时必须修改的组件数量。 这些依赖性还可能产生这样的后果：当检测到缺陷时，需要更长的时间和更高水平的专业知识才能将错误追踪到特定的软件模块和开发团队。

为了解决此类问题，OEM必须大幅提高标准化和模块化程度，使软件能够跨平台扩展，并将软件复杂度维持在可管理的水平。 车企还必须重视两项工作，一是推动软硬件解耦，二是应用面向服务的设计。

解耦架构。 汽车制造商可以引入强大的中间件层，用它提取硬件能力，并通过上层使用的标准化应用程序编程接口（API）将这些能力开放给软件功能。 这种软件架构可以利用平台之间的共性来降低设计复杂性并消除多次开发相同软件的需要。

除了解耦之外，车企还应该创建一系列标准化操作系统，并用它们来支持各个组件之间的协调，以确保互操作性。 许多公司已经宣布了开发此类操作系统的计划，但目前还没有统一的方法。

而且，企业还没有明确这些系统的具体研发重点和功能。

通过遵循清晰的架构原则和指南，企业可以有效地应对更高的系统和软件复杂性。 硬件/软件解耦允许多个实体参与模块化开发。 反过来，模块化软件构建技术增加了代码重用，并由于代码通用性的增加而减少了所需的代码总量。 许多公司已经开始引入软件产品线工程（PLE）方法，以在处理产品变更的同时提高重用性。 这种方法使一个软件能够服务于多种产品、产品变体和产品系列，并且与不同的硬件版本兼容。 软件 PLE 显着减少了开发和测试的工作量，这两项工作只需完成一次。

换句话说，将硬件与软件解耦可以实现硬件的进一步“自治”，其中硬件提供标准计算、存储、输入/输出和电源功能，而软件定义*终用户功能。 对于需要标准性能的应用程序，可以使用虚拟化和容器化技术在同一硬件上运行不同的软件功能，并在必要时动态分布到其他硬件（例如，在发生硬件故障时）。 对于具有实时性能要求的 ADAS 等应用，特定于硬件的软件开发对于实现*佳效率仍然至关重要。

面向服务的架构。 该架构应遵循各个服务的定义，而各个服务又应将业务或用户需求编码化。 面向服务的架构设计不仅可以让企业标准化各个核心元素，还可以标准化部门、业务单元之间的接口。 企业还应该将标准化设计应用于各个硬件和软件元素，以便可以在不影响性能的情况下为其他支持设备和功能大规模配置计算和存储资源等资源。 面向服务的架构对于 OEM 来说尤为重要。 实现车辆到云端的快速连接，不仅能提升车企各类车型的长期价值，还能促进车企能力快速更新升级。

A2。 应用以用户为中心的设计技术

在各个行业中，专注于开发强大的以用户为中心的设计并创造*佳用户体验 (UX) 的公司将获得更高的财务回报4。 随着 ACES 概念不断受到关注以及软件定义汽车成为常态，这些功能对于 OEM 的整体竞争力将变得越来越重要。 即使是顶级公司也需要改进，因为汽车行业在设计良好的软件用户体验和提供*佳客户价值方面仍然落后于其他行业。

遵循*佳实践中体现的设计原则，原始设备制造商应与*终用户合作，在交付之前和之后迭代新软件。 汽车制造商还应该采用新的交付模式，以便每周或每月进行软件更新或添加，以实现持续优化。 这些工作比传统的软件开发工作要短得多，后者通常需要几年的时间。 新交付模式的另一个好处是，它允许 OEM 与客户持续直接联系，让 OEM 能够收到持续的反馈，帮助他们优化软件需求并提供积极的用户体验改进。 当 OEM 依靠硬件来实施升级时，这种类型的交互是不可能的，因为仅在通过经销商网络进行一次性销售或市场调查期间才会发生一次接触。 为了达到这一目标状态，原始设备制造商需要具备必要的先决条件，例如支持软件和电子架构，以及支持云更新的工具链。

想要成为用户体验领导者的 OEM 必须充分利用他们的数据。 随着车载软件和传感器数量的不断增加，原始设备制造商现在可以访问大量数据来了解客户如何使用他们的汽车。 OEM 可以挖掘这些数据来识别对客户*重要的功能，以及那些过度配置或根本没有使用的功能。 这些见解将为配置和未来模型需求提供信息。

*终，新的交付模式将对开发效率产生积极影响。 鉴于汽车制造商会对其软件进行频繁的更改、调整和修改，因此他们不需要从项目一开始就确定极其详细的需求。 由于定义需求的时间缩短了，产品上市时间也将缩短。

A3。 调整软件需求管理

从历史上看，汽车行业一直是管理集成价值链需求的领导者。 然而，原始设备制造商主要关注硬件要求，其现有流程并未针对软件进行优化。 随着车载软件成为重要的差异化因素，原始设备制造商必须采用新的实践来管理需求。 管理需求变化尤为重要，因为我们的研究表明，汽车软件的需求变得如此细化，以至于减缓了开发速度。

根据*佳实践，原始设备制造商应根据客户价值对需求进行聚类。 **级应主要包含面向客户的需求（通常表示为用例）。 另一个级别主要由技术或实现要求（通常表示为启用因素）组成，例如功能所需的内存。 这种方法可确保 OEM 专注于价值创造并在软件开发过程中设置适当的优先级。 随着汽车制造商将需求分为多个层次，以下内容可以提供帮助。

将需求与战略和客户价值联系起来。 成功的软件开发需要根据客户反馈不断调整和修改需求。 虽然公司应该根据业务战略和目标尽早定义软件需求，但也应该根据客户反馈和开发进度定期进行调整。

确保端到端的可追溯性。 通过密切跟踪整个价值链的需求，汽车公司可以避免浪费精力并加快开发进程。 然而，车企只有其开发流程和工具链能够在从定义到验收的整个过程中实现需求的严格可追溯性，才能实现这一目标。 这种清晰度有助于汽车公司了解需求（客户角度）、所需功能（开发人员角度）和可交付成果（测试人员角度）。

车企必须分四步实现端到端的追踪，要么需要使用几个高度集成的工具，要么需要四种专业工具搭配相应的接口。 这些步骤是：

(1) 跟踪需求并细化和细化这些需求，从功能到组件；

(2)管理积压。 这项工作帮助每个团队管理软件开发冲刺期间各种需求的覆盖范围（与下一步密切相关）；

(3) 跟踪代码变更，包括代理项目的更新；

(4) 通过开发测试用例来验证需求，并检查测试用例的通过/失败状态。

借助关联需求的工具，用户可以在项目的每个阶段高效地实施变更，以满足端到端可追溯性的监管要求（例如，或）。 使用这种方法，我们可以快速找出哪些变更影响哪些工作产品。 当按照敏捷流程开发软件时，这种需求变化是正常且可取的（例如基于客户反馈的变化），公司应该使用各种流程和工具来支持它们。 在软件开发工作的传统瀑布过程中，这种变化很少见，而且往往是不可预见的。

避免过度细化并创建明确的需求类别。 企业可以建立一些*佳实践来指定和分类软件需求并开发简化的测试方法。 良好的需求声明是清晰的，并且允许独立于其他需求进行测试。 与投资组合管理一样，公司应该区分不同类型的需求。 常见的需求类别包括法律监管、安全、策略，以及必要的改进、客户价值、成本赋权等因素。 此外，公司必须确保需求之间的所有依赖关系都是透明的。 许多公司已将这些规则集成到自己的软件开发流程和培训课程中，以优化需求的处理和审查。

确定优先顺序并不断调整。 应根据特定的业务案例和战略目标以及客户反馈和整个开发过程（例如，在测试期间）获得的经验来评估软件需求并确定优先级。 组织应定期重新评估需求并以透明的积压状态维护它们。

许多公司任命产品负责人，他们知识渊博，可以对产品功能进行权衡，建立跨职能团队，并确保职能部门就需求达成一致。 根据*佳实践，产品负责人还负责遵循*佳实践并维护需求和用例的积压。

B. 在哪里开发软件：组织、地点、人才和合作伙伴

大多数汽车公司缺乏处理大规模软件开发工作所需的组织基础。 他们面临着多重挑战，其中一些挑战很少或根本没有明确的高管层职责划分，还有一些没有足够的软件工程师和架构师。 新的运营模式将通过明确软件开发工作所需的组织结构、地点和人才战略、“构建或外包”战略以及所需的合作伙伴生态系统来解决这些问题。

B1。 调整组织，建立全球软件卓越中心

在组织层面，大多数车企还没有准备好应对日益增加软件重要性的 ACES 趋势。 例如，原始设备制造商通常在软件问题上做出决策很慢。 许多车企并未明确整车平台的软件和电子设备策略的主要职责，以及相关预算。 为了在新形势下保持竞争力，车企必须重新思考组织架构。 这项工作的一个主要目标是减少端到端开发过程中架构定义、需求定义和开发所涉及的接口数量。 通过增加各个阶段团队之间的共识和协作，汽车制造商可以避免冗余工作并优化现有和新功能。

很多车企都建立了一个集中的职能部门，依靠这个部门来设计软件架构并共享固化的*佳实践。 例如，一家 OEM *近成立了一个中央职能部门，汇集了 5,000 名软件开发人员。 然而，在大多数情况下，原始设备制造商仍然采用更加分散的软件开发方法。

几种组织类型。 OEM 在尝试改进其软件开发工作时可以采用几种常见的组织类型。 对于每个企业来说软件正在迅速重塑汽车行业的关键转折点，*好的选择是反映公司优先事项的选择，包括加速决策、减少界面、明确职责。 更重要的是，公司必须专门努力协调不同组织职能部门的需求，包括研发、采购、生产、销售和售后市场，因为这些职能部门的软件需求和生命周期可能会发生变化。 彼此之间存在冲突。 此举将确保无缝的用户界面和高效的开发流程。 除了重塑组织之外，车企还必须大力投入，弥合软件和硬件团队之间的文化差距，协调工作流程，以开展相应的行动。 这些努力需要持续的变革管理，但它们将帮助汽车制造商成为软件开发巨头。

在定义组织结构时，汽车软件开发部门将构建功能角色、产品或项目以及技术的理想图景。 但这种组织架构一般会选择前述维度之一作为核心。

这里考虑强调职能角色的组织结构。 在这种模式下，公司从软件功能组织中抽取个人成员，并将他们分配到针对特定产品或平台的项目。 产品和技术将通过每个职能部门的间接“虚线”报告结构来反映。 这种架构为企业提供了*大的灵活性，因为他们不需要重新改造组织来满足产品/项目和技术方面的额外要求。 然而，这种结构下的开发效率可能不是*优的，这可能需要建立项目管理、架构和人员配备等跨职能部门。

第二种，组织结构以项目为中心，比如针对特定客户、车系、车型甚至平台的项目。 这种类型可以利用“虚线”汇报线和成熟的流程来连接产品和技术两个维度。 这种类型使客户和*终产品成为组织的主要关注点。 不利的一面是，它增加了冗余工作的风险，并在不同产品或项目团队之间造成各种障碍，这可能会扰乱技术交接。 强大的平台和架构可以帮助减轻这些风险。

在第三种类型中，组织结构侧重于技术和专业领域，例如网络、人机界面或后端。 在此模型中，公司指派其技术部门的个别成员负责特定产品的工作。 通过点状汇报和成熟的工作流程，该方法可以实现对技术和功能两个维度的聚焦。 虽然此模型有助于开发深入的技术和专业知识领域，但它在项目范围、要求和规范方面提供的灵活性很少，即使这些方面在项目期间发生变化也是如此。 企业在开发和维护多个产品时经常使用这种类型。

B2. 获取和吸引顶尖人才并进行内部能力建设

虽然汽车公司必须在许多领域表现出色才能赢得软件竞赛，但吸引和留住顶尖人才很可能是*重要的方面。

大多数原始设备制造商主要外包软件开发并依赖战略合作伙伴关系。 ACES 趋势大大提高了软件的重要性。 即使软件开发效率有数倍提升的潜力，到2030年，对软件工程师的需求仍可能增加三到四倍。随着汽车行业与科技公司和其他行业对软件人才的正面竞争，企业需要采取重大措施改善顶级开发人员的招聘。 否则，人才缺口将继续扩大。

汽车软件人才的招聘和保留计划应注重差异化。 根据我们的基准分析，在开发生产力方面，具有不同经验的团队比具有同质经验的团队表现出两位数的百分比。 企业可以通过开展以下工作来改善人才招聘现状，更好地利用全球软件开发人才资源。 全面的选址战略可帮助公司扩大软件开发活动、建设能力并提高生产能力，同时控制成本。 这也有助于企业争夺顶尖人才。 一些创新企业在数字人才热点地区建立了新的汽车工程中心，例如自动驾驶中心。 尽管如此，大多数传统公司在很大程度上保留了他们的历史足迹和硬件中心，这可能会使他们吸引和留住软件人才的努力变得复杂。 如果这些企业在关键地区的多个地点开展业务，他们可以从附近的大学和其他教育机构吸引人才。 为了加强联系，这些公司可以与大学合作开发访问实习计划，让他们有机会接触应届毕业生和其他专业技能人才。

虽然全球足迹可以带来许多好处，但它还需要合适的运营模式来避免远程和/或分布式工作的常见问题。 例如，研究表明自动化软件开发，开发项目中每添加一个新站点，软件开发效率平均就会下降约 10%。

使企业对软件人才更具吸引力。 我们的研究表明，薪酬、职业发展机会、工作类型和公司文化是留住软件工程师的首要因素。 目前，车企在这些方面都落后于科技公司。 为了弥补这一差距，前者必须制定独特且有针对性的雇主价值主张，解决所有重要的影响因素，而不能再简单地坚持工作保障和公司汽车等传统福利。

鼓励内部能力建设。 合理的做法是尽可能对当前以硬件为主的员工进行再培训，以便他们在技能升级后能够承担与软件相关的职责。 例如，公司可以培训硬件项目经理来监督软件项目。 然而，只有当公司在软件专业人员和经过再培训的硬件专家之间保持良好的平衡时，这种方法才有效。 这种平衡可能会根据具体公司的情况而有所不同，并且很难量化。 然而，根据经验，许多公司在比例保持在 2:1 时效果*佳（即 2 名软件专业人员：1 名经过再培训的硬件专家）。 为了获得*佳结果，企业应该制定有吸引力的发展计划和在职培训计划，帮助员工快速学习新的软件语言和方法。 此外，应强调终身学习。

虽然重新培训可能会填补许多人才缺口，但公司不应忘记，大多数人在工作多年后形成了根深蒂固的解决问题的模式。 当出现意外问题时，具有硬件背景的软件员工可能会采用固定的解决问题的方法，这种方法可能比敏捷更线性。 因此，企业在培训过程中应尽量鼓励新的思维方式。 如果成功，软件专家和经过再培训的员工之间的差距将迅速缩小。 相反，忽视这种实践会阻碍整个组织的敏捷转型。

提供职业道路。 与科技公司相比，大多数车企在明确职业道路和成长机会方面仍存在短板。 出现这种差距是因为汽车公司尚未广泛提供专业职业道路。 此外，原始设备制造商很少定义工作期望和资历级别。 想要晋升的专家被迫担任管理职位，因为没有其他选择。

为了提高保留率，汽车公司可以引入清晰的职业道路，并在每个级别都有特定的技能要求。 有些课程面向商业专家，其他课程则面向管理人才。 晋升路径可以是垂直的（从初级开发人员到高级开发人员再到团队领导），也可以是同样重要的横向轮换，持续六个月或更长时间，重点发展不同的技能，包括与领导力、项目管理和软件相关的技能。 企业还应该制定专门的培训计划，包括基于岗位和跨学科的培训，向更广泛的员工开放。 清晰的职业道路有望提高效率，因为专家通常比新手更有生产力。

B3。 定义并建立明确的“内部或外包”策略

为了保持来之不易的竞争优势，避免成为同质化的硬件平台开发商，车企必须制定清晰的客户策略，确定差异化的配置和价值主张，并创建一个可以逻辑分解开发模块的系统。 模块化架构。 After these tasks, car can focus on three major to a clear "in-house or :"

(1) The stage of work, such as or ;

(2) stack;

(3) areas or , which may cover areas such as or .

and along these to an “in-house or ” based on their (eg, for key , , , etc.).

Of , must also the ease of in the - . Other (such as cost) are also but not . To -, OEMs can weigh based on and .

When a to its own in-house, it must the on , have and have the , and and . If a lacks or has , it or joint to it has over key .

If an to , it must the model the , which the and of . When for , with up to two or three .

Our shows that this will cause to drop by more than 65%.

In a "build it or it" , adopt open as they the . , need to clear rules and for using open and pay to , and . , OEMs and need to sign legal to use open in .

, and , as these help learn from each other while up and costs low. Joint also the risks with late entry into the .

In a “build or ” , OEMs keep the of in-house and the of non- to other or . In to the , this will the need for .

C. How to : Agile, ,

, car have paid more to , by . This and must be now that is now a major value in the . This shift car to large-scale agile , and , and the level of test and .

C1。 agile at scale

Agile , when on a large scale to and , allow to and to . agile , in have a 30% in and speed, while in by more than 70%. 6 Agile plays a vital role in by risks to , time, and .

So far, only a few car have agile . many are , on , only a few have agile at scale.

The for the low rate may be that in the have very , it to agile the . , agile tools used in the must be able to , with , and to , , and .

on . To , OEMs can with and adopt large-scale agile . These and and .

, and will and help meet . can use to the of and . This, in turn, high-level input and to the agile team. Based on these , agile teams can and . At the end of the cycle, when the , , and test have the , the team can close the loop.

From a , the goal is to among on the and for units and - . For , and track the of their is for time- such as . In this way, when at the , you only need to those less .

and . Agile are fully in the and , but must and basic of and .

, some may need to be , such as the of (thus with the ISO 26262 ).在传统瀑布式开发模式下，认证组件的生成顺序与工程活动相同，即规划、客户需求、系统架构、软件需求、软件实施和软件测试。而在敏捷开发模式中，*好的方法却是反向认证，即在项目结束时，也就是所有软件需求和代码都确定、固定之后， 创建认证组件。这种做法可*大程度地减少浪费，因为不用多次生成认证组件，并且需要软件安全审核员从项目支出保持一致，且与团队关系良好。软硬件解耦有望进一步简化ISO 26262认证工作，因为重复使用的软件可能会通过经验证的参数进行合规验证，即当其他应用程序已经使用该软件而未出现问题，则证明可使用该软件。

目前，诸如之类的行业标准规定所有需求都必须可追溯，并能够审计所使用的流程和工具。需求的可追溯性与敏捷实践做法兼容，可通过自动化工具链高效实现（请参阅A3部分的需求管理，以及D2部分的标准化工具链）。但是，流程和工具的审计需求可能会限制敏捷技术固有的持续改进系统。尽管“敏捷” 团队可独立地改善其流程和工作方法，但汽车团队却必须符合文件标准的要求，并确保各个团队之间的同步， 这些行动可能拖慢其进度。

何时采用敏捷方法。尽管需要预定义的待办事项以及可审计的流程和工具，汽车软件团队仍可即刻采取大多数敏捷实践。但是这会极大地改变他们的工作方式。

转向敏捷方法时，组织必须对宏观层面的运营（包括项目组合、资源和项目管理）进行关键设计的决策。通常，只有先进的开发部门，例如OEM的“软件工厂”，才采用规模化的敏捷方法，即所有部门都完全采用新的工作方式。但是也有例外，例如，一些汽车先驱企业已实施了规模化敏捷方法，例如规模化敏捷框架（SAFe），指导其总体研发工作。

与之相反，各个团队则应始终遵循已建立的敏捷实践开展业务。例如，跨部门代表和/或团队成员同址办公以及有时间限制的迭代都非常重要。与其他行业一样，在将敏捷方法应用于负责各个功能的团队时，其优势可能*为明显。

当OEM向敏捷流程过渡时，还必须：

将开发供应商集成到其敏捷流程中，促进全面的应用；

调整采购流程，从有明确预定义和预协商的基于规格的合同关系转变为基于冲刺的开发合作伙伴关系；

解决影响供应商与OEM共址办公或敏捷合作的法律问题。

C2.软硬件解耦促进双速开发流程

在流程方面，车企可采用更动态的软件周期计划，支持经常性的发布,而非受限于严格而遥远的车辆平台SOP日期。将产品及生命周期管理与硬件解耦是脱离独立整车(one-)SOP方向的关键。为此，必须保持独立的待办事项和路线图,同时明确软硬件开发之间的同步里程碑。在与供应商合作时，0EM可能需要重新签订新的协议。*后，OEM必须加强自动化软件的使用,集成测试和部署。

与敏捷方法一样，系统开发团队可管理和定义硬件和软件团队之间的接口，明确划分硬件/软件待办事项，确保各层级的同步。显然，如果硬件和软件彼此独立，即可分设架构冻结点，这样就无需同步了。

像敏捷方法一样，解耦也需有若干先决条件,包括标准化和模块化的架构以及可靠的测试方法。如前所述，企业可以使用强大的中间件将软件与硬件解耦，中间件可以提取硬件能力( layer that )，通过标准化API将其提供给需要的功能和服务。但*关键的解耦抓手其实是具有鲁棒性的车辆测试方法。因此，企业必须定义提供和维护测试车辆的方法:例如硬件在环或软件在环系统，或者是更广泛的仿真基础架构。

敏捷方法和硬件/软件开发解耦都对价值链的下游有重大影响，尤其是对于采购组织而言。例如，采购需从传统的瀑布式采购流程转变为更适合敏捷和解耦开发方法的模式。在实践中，这就要求OEM遵循某些*佳实践做法，例如不断评估软件要素对于战略的重要性，了解需求将如何演变以及确定每种情况下*合适的采购模式。这些变化要求对软件总拥有成本以及新的合作模式有所了解，新模式侧重战略合作伙伴关系而非多供应商采购。

C3。提高测试自动化、完善持续集成，确保尽早发现错误

随着软件数量的增加以及对连续功能更新的更大需求，OEM必须尽快发现并解决漏洞和接口错误。如果无法直接解决问题，漏洞可能会大量积压，从而消耗掉所有资源并使问题跟踪复杂化，导致开发延误并产生更多的验证工作。

与敏捷实践一样，几乎没有车企大规模采用持续集成或自动化测试的方法。但只要它们采用这些做法，即可降低发布风险，同时大大提高开发效率。根据我们的经验，企业可将开发效率提高40%以上，同时将残余缺陷密度降低60%以上。

要仿效先行企业，车企应采用两个相互关联的软件开发*佳实践。首先，应每天几次将代码集成到共享存储库中并通过自动构建进行验证。尽早集成代码有助于开发人员“快速失败” （及早发现问题），然后通过持续集成实践、工具和自动化手段，轻松隔离问题，使之不会产生更大的问题。供应商则可独立地在系统层面上获取这些益处。 在整车层面上，OEM需要解决IP限制问题，自研编码（ ）或采用“白盒” 方法，与供应商共享完整代码。解决方案的第二个要素是测试驱动开发和自动化流程， 即在编码开始前就对测试进行定义，然后在代码集成后自动进行测试。

软件设计人员和开发人员（而不是独立的测试部门）在开发过程中与客户一起对测试进行优化和迭代。该方法迫使开发人员在编码开始前即要考虑如何使用系统以及如何实施这个问题。*终，全面的自动化测试套件将使可持续、冲刺成为可能。

D. 如何促进软件开发：性能和工具链

为了优化软件驱动型运营模式的效率，企业应采用**的性能管理方法，并通过构建软件开发工具链，建立*先进的软件开发基础架构。

D1。实施性能管理，涵盖数据驱动的开发效率、项目成熟度和质量度量

随着软件复杂性的提升，车企必须升级其性能管理体系，采用标准化、数据驱动的指标对开发效率、项目成熟度和质量进行度量。 只有自动化的、数据驱动的洞见才能赋能基于事实的实时性能管理方法，主动暴露出时间、成本和质量方面迫在眉睫的软件问题。

**的软件性能管理系统应在以下三个关键事项上脱颖而出：

（1）建立全面的KPI（如成本、时间和质量KPI指标）体系，确保每个指标都与总体业务目标和运营任务挂钩；

（2）开发一个有效的问题上报系统，包括标准会议这种形式，侧重简单、快速的汇报、 决策和上报；

（3）采用工具化、自动化的开发效率测量技术和代码质量衡量指标，确保对软件开发效率和质量进行客观的测量。

D2.升级开发工具链

车企可引入标准化软件开发工具链，支持持续集成和标准API的使用，从而提升开发效率。典型的工具链组件包括侧重构建、持续集成和测试自动化的源代码管理流程和工具，测试自动化包括测试执行、测试结论生成和测试报告生成。如上所述，该工具链还无缝集成了需求管理方面的所有工具。

构建一套集成、高度自动化的工具链可在开发过程中带来极大益处。例如，可降低复杂度从而提升内部效率，可使用来自外部构建模块的成熟技术。根据我们的研究和经验， 先进的工具链可以：

推动更快、更敏捷的开发，将代码发布或构建所需工作减少90%；

通过严格的质量管卡的使用而降低缺陷密度，从而有可能将故障率降低50%。

允许企业每天进行成千上万次编译，而无需任何人工干预总体而言，引入标准化、*先进的开发工具链，是释放自动化测试和敏捷方法30%至40%效率潜力的关键推动力。这种性能水平足以使表现*佳的企业脱颖而出。车企应将这种软件开发工具链视为高效率组织的核心部分，这类组织都支持连续集成和标准API的使用。此类工具链还可确保整个开发过程中软件与硬件开发工具之间高效的自动化接口。

同时，工具链还为若干流程步骤的自动化（例如测试运行）提供了机会。总体而言，目标就是加快开发速度，促进尽早测试。

通常，用到的工具链和工具的数量会增加到难以管理的水平，从而降低透明度。为避免此问题的出现，经验丰富的工具链管理人员应定期检查工具状况，必要时采取纠正措施。

使转型成为现实

许多组织已开始认真采取行动，希望从软件上获取价值，从而抓住电动化、网联化、 智能化、共享化这个“新四化”趋势带来的机遇并从中受益。典型的转型之旅始于某个单一挑战或主题，例如恢复软件项目的即时补救措施、软件“自研或外包”决策或是软件开发绩效方面的重大预期变化。但是，大多数企业发现，单一面向的干预带来的影响非常有限，尤其是当企业缺乏持续改进所需的关键基础时。因此，要建立世界**的软件开发能力，企业应采取端到端的转型视角。 考虑到各自现状的不同，企业可能以不同的方式进行转型。斟酌初始转型侧重点时，可以选择以下的某个切入点：

“是什么”：产品架构和“自研或外包”决策

目的是建立一套目标软件架构，既有具体的内控点，又有外部合作生态圈，从而可实现跨平台的高效且有竞争力的软件交付。

“如何做”：开发效率提升和软件开发方法

重点是利用软件开发的关键效率杠杆（包括敏捷研发、持续集成）和自动化测试，提高软件研发的效率（请参阅C和D2部分）。

“在哪里做”：以合理的成本获得人才

面临产能不足、无法有效提升软件产出的企业可先从该主题切入。解决方案包括改善其业务足迹、使组织对软件人才更具吸引力，从而优化人才和研发成本（请参阅B2 部分）。

“如何设置”：组织与治理

另一个起点是定义*佳的组织架构，明确“ 框线”图架构，并说明具体的运营模式，包括绩效引导和绩效管理，从而加强软件交付。

要克服汽车行业当前的软件复杂性和开发效率难题，就需要对汽车软件研发进行全面的转型。CTO和CEO必须将这一挑战作为其日程上的重中之重，并立即加以应对，才能在当前的行业环境中保持竞争力和成功的市场地位，而且他们还应为更大规模的转型做好准备，因为解决与软件组织及其底层运营模式有关的所有问题可能需要耗时数年之久。

详见报告原文。

（本文仅供参考，不代表本行任何投资建议，如需使用相关信息，请以报告原文为准。）

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等