首先汽车行业没有敏捷开发的说法是错误的，敏捷开发这个理念也适用于汽车软件的开发，更有理念的坚定支持者，比如特斯拉，把敏捷开发的理念贯彻到整车的开发中（优劣先不评判）。
一、为什么汽车行业没有敏捷开发的说法，而是ASPICE的V型开发模型
首先汽车行业没有敏捷开发的说法是错误的，敏捷开发这个理念也适用于汽车软件的开发，更有理念的坚定支持者，比如特斯拉，把敏捷开发的理念贯彻到整车的开发中（优劣先不评判）。
ASPICE里的Process reference model里有一大过程分类中包含系统工程和软件工程的开发过程，这个过程套用的就是V型开发模型。
这里面提到的软件工程是依据系统工程开发时所衍生出的软件需求管理，所以也包含在系统工程的框架中。
以传动系统中的控制软件为例，控制软件的前期需求是确切的，开发过程中很少有变更的需求，更多的需求在于如何完美的实现，而且软件的开发也依托在传动系统的开发流程上，所以自然而然地就使用V型开发模型了。
敏捷开发需要做什么适配
敏捷开发需要克服的困难主要在于提升软件质量和满足功能安全要求。
- 并不是用敏捷开发出来的软件架构就会松散，臃肿，而是敏捷的环境让工程师更容易输出这样的结果。所以我认为以下措施的执行能有效改善软件质量：
- 适当延长Sprint周期；
- 严格的编码规范与培训；
- 使用TDD（测试驱动开发）思路
- 强大的devops能力作为技术保证；
- 引入自动化单元检查工具；
- 满足功能安全要求，话只有一句，其实是个悖论，因为软件功能安全=V模型开发。可能的一个解决方案，是利用26262中FFI的思路，通过前期技术规划，将软件架构分解成功能：QM(D)和功能安全软件D(D)，功能分区使用敏捷开发小步快走，功能安全分区还是按V模型进行开发（思路是这么个思路，但做软件安全分析和安全架构设计需要非常小心，而且仅适用于SAFety goal为fail SAFe的域控，如果L4以上需要做fail operational的，又不能这么玩了）。
延伸阅读：
二、敏捷的缺点
相比ASPICE或者V模型，敏捷少做的事情：
- 缺少统筹全局的进行软件架构设计，导致模块很难做到高类聚低耦合，比如Sprint A实现的一个功能，其底层模块其实可以被Sprint B的某个功能部分复用，但由于Sprint A没有考虑Sprint B的开发需求，所以该底层模块并不能被完全复用，Sprint B可能就要重新开发一个底层模块去覆盖他自己的需求。多轮Sprint下来，可能会有重复造相似轮子的情况出现。这样会导致软件比较臃肿，代码量大，执行效率低，且代码质量不高；
- 缺少集成测试，导致新加的功能可能对已实现的功能有潜在的影响而不能被发现；
- 由于短平快的特性，很多时候单元测试也不能充分进行，比如动态单元测试；
- 与FUSA的流程完全不兼容。26262也好，61508也好，34590也好，都是植根于V模型，使用敏捷开发的软件，很难满足功能安全的开发要求，也无法做功能安全分析，无法做FFI。
