谈谈汽车电子产品的敏捷开发

01  汽车电子产品研发的痛点

目前汽车电子产品，特别是汽车几大域控（如：智能座舱、智能驾驶、智能网联、车身控制），市场竞争激烈：随着科技的发展，越来越多的企业开始进入这些领域。传统车企、互联网公司、初创企业都在这个领域进行布局，使得市场竞争异常激烈。

另外用户需求变化：随着消费者对汽车的需求逐渐多元化和个性化，用户对座舱和智驾产品的要求也越来越高。他们不仅要求产品具有创新性和科技感，还要求产品能够提供更加优质、便捷的驾驶体验。

在上述因素的加持下，无论是设计方还是软件实现方，均对现状不满意。主要体现在以下几个方面：

1.需求的不断更改

为了能吸引用户，在汽车研发初期，设计方会提出很多新颖的概念，往往这些概念不太成熟，随着时间的积累，设计方通过用户调研、竞争对手分析，会不断地更改和追加新需求来完善想法，提高产品质量和用户体验。但产品的最终交付时间并不会变更。

2. 最终实现和最初期望背离

汽车电子产品具有复杂性的特点，这种复杂性不仅来自于产品软件本身的功能需求，还来自于与汽车各个子系统的交互，以及对于安全性和可靠性的严格要求，一个汽车电子产品需要与多种硬件设备进行集成，如传感器、执行器、控制器等。这些硬件设备的多样性增加了软件的复杂性和开发难度。因为这种复杂性存在，在产品的最终实现和最初的预期往往存在较大的偏差：

3. 整车开发周期越来越短

国内汽车主机厂，特别是新能源车企，整车开发周期越来越短，配套的电子产品的开发周期也相应的被压缩。

02  当前汽车电子产品研发流程

目前汽车产业研发，特别是软件研发，主要采用 V 模型，其是由瀑布模型演变而来的，也是目前汽车行业运用最广的软件开发模型。一种自上而下，过程驱动的开发方法，它强调在项目开始阶段就对需求进行详细的分析和定义，然后依次进行设计、编码、测试等流程，直到项目完成。这种方法着重于规划和质量控制，以确保项目的需求、设计和实现的一致性。因此，V 模型开发方法更适用于需求明确、需求稳定的项目。

V 模型由如下的几个特点：

1、严谨的阶段划分

V 模型将软件开发划分为一系列严谨的阶段，包括需求分析，系统设计，编程，系统测试等。每个阶段都有明确的输入和输出，以及严格的验收标准。

2、 早期验证和验证

V 模型强调在软件开发的早期阶段进行验证和验证，以便尽早发现和修复错误。

3、文档驱动

V 模型强调文档的重要性，每个阶段都需要产生详细的文档，用于记录决策，传递信息，以及后续的维护和支持。

它的优势主要体现在

1、 提高客户满意度

它是标准化软件开发流程，是客户和产品开发方的共同语言，通过实施 V 模型，方便客户进行评审和管控供应商开发质量。

2、提高产品质量

通过规范和标准化软件开发流程，有助于降低产品缺陷率和提高产品质量。

3、 促进持续改进

V 模型重视文档管理，强调持续改进和优化，有利于在开发过程中不断发现问题、分析问题并采取措施解决问题。并且有利于将其他项目或者上一个项目的经验教训展开到现有项目。

它的不足之处体现在

实施成本高

开发周期长

无法及时评审过程产物

03  产品敏捷开发流程管理

作为汽车电子产品开发流程的方案优化，将敏捷开发和 V 模型结合使用。敏捷开发是一种迭代式、增量式的开发方法，强调对需求变化的快速响应和持续交付有价值的软件，将其用于产品的开发，实现敏捷迭代。同时，针对具体产品的特点，强调功能安全的重要性，利用 V 模型的需求管理方法来确保需求的准确性和完整性。通过结合敏捷开发和 V 模型，可以实现对汽车软件开发过程的全面评估和改进，提高产品研发质量和可靠性。

1. 产品敏捷迭代

持续开发、持续集成和持续部署共同构成了敏捷开发过程。通过持续开发，可以快速响应客户需求的变化，提高软件的质量和可靠性；通过持续集成和持续部署，可以确保软件的完整性和稳定性，并最终实现软件的快速上市。

1） 持续开发（Continuous Exploration）

首先，敏捷开发起始于一个敏捷团队和一个计划会议：敏捷团队是跨职能的，每两周一次的协作交付工作系统，这些系统被称为迭代。

迭代开始于一个计划会议，这个会议由产品负责人主持，并负责迭代的工作库（User Stories）。

敏捷团队在会议上决定他们可以在迭代结束时交付哪些用户故事。每天团队需要讨论他们的进展，并在迭代结束时向产品负责人演示结果，以确保他们已经交付了他想要的。

然后他们会聚在一起回顾他们可以在下一个迭代中改进什么，然后再开始一个新的计划会议。

项目级别和团队级别的工作流程非常相似，是一个由多个团队组成的更大的团队，共同交付一个更大的系统，人数范围从50到125人不等。这个更大团队被称为敏捷发布列车或ART，其工作产出称为项目增量或 PI，一般默认由五个迭代完成，每个 PI 的内容由程序待办事项中的产品经理以特性的形式确定，并提供大部分团队待办事项的内容。列车由 RTE 或发布列车工程师管理，他充当列车 Scrum Master，确保主干平稳并确保行驶在正确的轨道上，他是项目级别的产品经理。

2）持续集成（Continuous Integration）

持续集成要求团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。持续集成指的是，频繁地（一天多次）将代码集成到主干。它的好处主要有两个：

快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。

防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

3）持续部署（Continuous Deployment）

持续部署是持续交付的下一步或者说更高阶段，指的是代码通过评审以后（或者是通过自动化测试以后），自动部署到生产环境。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。

持续部署的目标是代码在任何时刻都是可部署的，可以进入生产阶段。它的核心措施是，代码通过评审以后，自动部署到生产环境。如果没有制度的约束或其它条件的影响，每个改动都应该尽快地部署到生产环境。持续部署是否适合某个公司是基于该公司的业务需求，而不是技术限制。

在持续部署的实践过程中，一个最小化的持续集成系统需要包含以下几个要素：版本管理系统、构建脚本&工具以及自动化测试。

2. 敏捷开发在汽车软件开发上的应用

2.1 需求驱动

减少需求层级，适应快速敏捷的需求：传统 V 模型的开发流程中有 4-5 级的需求文档，每层均对应一个团队，每层均需要文档编写、上下游对齐时间，阻碍了敏捷开发。在运用了敏捷模型的汽车软件开发团队，将需求层级减少为 1-2 级，最终完成从产品需求到软件需求。这些需求编写同样采取敏捷迭代的方式进行。

产品负责人驱动产品&软件开发：传统V 模型的开发流程中是由项目经理驱动软件开发，在运用了敏捷模型的汽车软件开发团队，产品经理负责产品和软件需求，由产品经理将需求下派到软件开发团队，并确定开发计划、验证计划等，最终完成产品的验收。

2.2 功能和安全事项不同的开发管理方法

对于不涉及汽车安全的功能或产品，采用快速迭代的敏捷开发方式：对于不涉及汽车安全的功能或产品，强调的是快速回应用户需求和满足用户体验，允许在软件系统鲁棒性方面进行迭代改善（包含量产后的迭代改善—OTA）对于功能安全需求，采用 V 模型进行开发：对于功能安全需求，强调的开发受控，达到减少用户危害、同时满足严苛的（对内&对外）审核的要求，需要重视流程和文档管理，采取 V 模型进行开发。

04  总结与展望

随着智能汽车的蓬勃发展，汽车功能日新月异，软件代码量日益增加，传统 V 模型下的瀑布式开发已经不堪重负，为了快速交付给客户最迫切需要的功能，软件开发流程的转变至关重要。目前，越来越多的开发公司转向了敏捷开发。但在实际工作中，要实现敏捷转型，也面临不小的挑战。

根据敏捷年度报告中的统计，敏捷转型中面临的挑战主要有以下方面：

从占比最高的前三项可以看出，对于很多组织来说，内部文化仍然是敏捷转型的巨大阻碍。

因此，汽车软件开发流程向敏捷开发转变的过程，也是内部组织架构调整的过程。主要需要解决以下问题：

1.缺乏领导层的支持：

实行敏捷，组织架构上的微调是必不可免的，例如，一个SCRUM 团队，需要产品、开发、测试、集成等各个职能人员，而这些人员通常分属不同部门管理，SCRUM 团队管理者想要有序推进工作，就需要领导层的支持才能保证团队各成员的配合。

2.组织对变革的阻力：

接受新的观念、流程对很多人都较为困难，且在转型初期会较为痛苦；

敏捷特别讲究量化数据，这会使得一些浑水摸鱼、工作量较少的员工暴露出来，他们天然会反抗这种转型；

敏捷转型后，整个组织自驱力越来越强，需要的管理人员则会变少，造成的人员冗余问题又会导致内部产生阻力。

综上所述，敏捷开发将会是汽车软件开发流程的转变趋势，但转向敏捷的过程仍面临组织内部的巨大阻力。同时，目前汽车行业仍然要求软件开发必须符合 ASPICE 认证要求，这导致软件开发团队无法彻底摆脱传统开发模式的束缚。当前 ASPICE 与敏捷开发的结合，往往也是敏捷主导着整个开发流程，而 ASPICE 流于形式。转向敏捷开发，不仅需要软件开发企业内部管理的调整，也依赖于未来行业标准的转变。