开写前先唠两句，只要与开发工程师多聊两句，你就会很容易地发现，开发工程师几乎是一边倒的支持敏捷开发，笔者曾完整地参与过一次ASPICE认证项目，也在敏捷模式下进行过较长时间开发。从开发工程师的角度出发，使用敏捷进行开发的体验吊打ASPICE(或者V模型)九条街，但我们今天讨论的话题是哪种模式更适合“更快更高质量”地输出产品，而不是哪个模式对工程师更友好。那么我们就来探讨一下这两种开发模式在域控时代的适应性。
当汽车电子电器架构还处于分布式的年代，ASPICE（或V模型）可以说是唯一的答案，就没听说过哪家Tier 1或者OEM是使用敏捷去开发一个发动机控制器的。到了域控时代，新的玩家入场，开发逻辑出现不同声音，特斯拉，蔚小理等硅谷/互联网背景出身的新玩家都使用敏捷进行开发，做出来的产品用户体验确实让消费者有种“诺基亚转安卓”的感觉，难道说敏捷就有如此大的魔力？可以给软件赋予生命力？ASPICE和敏捷的差异和思路究竟在哪？
ASPICE的核心思想就是DRIFT(Do things right in first time)，ASPICE认为：
软件缺陷修复的成本是随着软件进度的开展，成倍数级提升的，BUG越早发现，成本越低；
BUG在不同阶段引入的修复成本
在关键控制器上（比如动力总成的ECU），某些Bug可能是致命的（字面意义上的）且难以被发现的，因此，对代码的态度必须慎之又慎；
传统的合作关系上，通常是Tier1供控制器（Turn-key or Customer-sharing），OEM集成到车上，对于软件这种无形的资产，又是闭源交付，OEM管控是很难的，唯一的监管方式就是交付物，所以ASPICE既是开发过程，也是质量证据。
因此，ASPICE讲究走一条最康庄平坦的大道：
一份不偏离相关方（stakeholder）意图的工程需求---->按照意图，考虑所有corner case，基于选型芯片资源，设计考虑完备的软件架构---->将软件架构进一步细化到模块与函数级别的详细设计---->与详细设计思路一模一样的编码---->验证是否与详细设计一致的单元测试---->验证是否与软件架构设计一致的集成测试---->验证是否与软件需求一致的合格性测试。
说白了，就是：
V左半边：保证每一行代码都能知道是为哪一条需求服务的。
V右半边：保证每一行代码都在正确的实现每一条需求。
ASPICE统治了汽车软件这么多年，自然有他的必要性与优势，但ASPICE的缺点也非常致命：
1. 难以拥抱变化
从上文可以看出，一套V模型撸下来，都是一环套一环的，下一步的输出完全依赖上一步的输入，如果需求发生了变更，而且需求还是与原需求互斥的，那整个项目的改动量将是灾难性的。所以有些OEM的DRE可能会很疑惑，为什么看起来一个小小的CR（change request）发下去，会被Tier1告知一大笔的开发费用，甚至是拒绝？流程可能就是其中一个原因。只要代码需要变更，好嘛，相应的设计文档作废，重新设计，测试重新做……想想都头疼。而国内的项目氛围又是“最爱”拥抱变化的，hmmm……
2. 对人力消耗巨大
我贴一下SWE.3（软件详细设计与单元开发）的BP出来给大家感受一下
SWE.3 BP
随便说几个工作量大到离谱的：
BP3：很多时候模块间交互是很难穷尽描述的，特别是大型软件，应用层，或者高聚低耦做得没那么好的模块，在不同场景，不同条件下，都可能走不同逻辑，整个交互路径都穷举一遍是很难的，画出来的seq图也很难阅读
BP5：每一步的流程都要求这个，做过的dddd（懂的都懂），有DOORS相对好点，用excel去管理这玩意就是个灾难，还感觉没什么卵用
其实每个BP要求的工作量都很大，我做过大概的统计，执行ASPICE的人力需求是不执行的3倍，除此以外，就像我之前说的，这个流程既是开发流程，也是质量证据，属于监管与被监管的关系，繁重的文档任务深深的打击了工程师的积极性。
单次sprint流程
敏捷开发的核心逻辑是解构，把软件需求分解成Epic or story，通过一轮开发迭代（sprint）实现相应的功能。一轮sprint包含：需求确认->方案制定->coding->台架验证->实车验证->rolling candidate版本验证->代码合入
敏捷的优点在于：
拥抱不确定性，发生需求变更，那就直接来一轮sprint，如果还不够，那就来两轮；
出活快，一个sprint的迭代以周为单位；
充分调动工程师积极性，（相对）轻文档，重代码；
说完敏捷这枚硬币的正面，下面说他的反面。
相比ASPICE或者V模型，敏捷少做的事情：
缺少统筹全局的进行软件架构设计，导致模块很难做到高类聚低耦合，比如Sprint A实现的一个功能，其底层模块其实可以被Sprint B的某个功能部分复用，但由于Sprint A没有考虑Sprint B的开发需求，所以该底层模块并不能被完全复用，Sprint B可能就要重新开发一个底层模块去覆盖他自己的需求。多轮sprint下来，可能会有重复造相似轮子的情况出现。这样会导致软件比较臃肿，代码量大，执行效率低，且代码质量不高；
缺少集成测试，导致新加的功能可能对已实现的功能有潜在的影响而不能被发现；
由于短平快的特性，很多时候单元测试也不能充分进行，比如动态单元测试；
与FUSA的流程完全不兼容。26262也好，61508也好，34590也好，都是植根于V模型，使用敏捷开发的软件，很难满足功能安全的开发要求，也无法做功能安全分析，无法做FFI。
两种开发流程各擅胜场，也有其出现的背景，在传统汽车时代，各个控制器没有花哨的功能，但要求软件稳定可靠，这种情况下，使用ASPICE或者V模型进行开发无疑是非常正确的。
域控时代的来临，最主要的变化有三点：
功能众多：带来的变化是软件复杂度指数式上涨，相关方众多
产业链合作关系改变：从一功能一盒子，由Tier1软硬件一起交付，OEM负责集成，到所有功能集中在域控，Tier1只提供底软和硬件，应用软件由Tier1，Tier2，OEM联合开发
电子电气架构演变
我的观点是：ASPICE不适合用于开发智驾域控软件，敏捷相对更合适，但必须根据汽车软件的特点，进行适配
（一家之言，如果有使用ASPICE完整开发过智驾域控到SOP的经验，非常非常欢迎留言探讨）
第一，ASPICE下对发生变更的代价是巨大的，因此需要一次把所有功能都定义，设计完美。然而在域控这种软件复杂度下，我不认为有哪个人或者团队可以在项目开发初期，就能一次把所有的需求都定到完美。不完美，后期增改功能，好嘛，又一轮完整的V迭代，所有文档改掉，软件配置管理做版本管理，恐怕需求没开发完，工程师跑一大半了。
第二，退一万步讲，就算有优秀的产品团队可以一次把所有需求缕清，肯定也需要漫长的时间，试想下，两家公司同时开始项目，使用敏捷的小步快跑，不断试错，都已经有产品在投放市场了，使用ASPICE的可能还在需求制定阶段……
敏捷开发需要克服的困难主要在于提升软件质量和满足功能安全要求。
并不是用敏捷开发出来的软件架构就会松散，臃肿，而是敏捷的环境让工程师更容易输出这样的结果。所以我认为以下措施的执行能有效改善软件质量：
适当延长sprint周期；
严格的编码规范与培训；
使用TDD（测试驱动开发）思路
强大的devops能力作为技术保证；
引入自动化单元检查工具；
满足功能安全要求，话只有一句，其实是个悖论，因为软件功能安全=V模型开发。可能的一个解决方案，是利用26262中FFI的思路，通过前期技术规划，将软件架构分解成功能：QM(D)和功能安全软件D(D)，功能分区使用敏捷开发小步快走，功能安全分区还是按V模型进行开发（思路是这么个思路，但做软件安全分析和安全架构设计需要非常小心，而且仅适用于safety goal为fail safe的域控，如果L4以上需要做fail operational的，又不能这么玩了）。
版权声明：本文为知乎「FragmentedSword」的原创文章，已获作者发表许可。
推荐阅读
分享不易，恳请点个【👍】和【在看】
