汽车行业的软件开发标准，最著名的应该是V模型。以V模型为代表的有ASPICE、 ISO 26262 和 ISO/SAE 21434。今天我们主要以ASPICE为基础，探讨V模型在当前汽车软件变革时代的特点。
传统的V模型标准在当前这个阶段，有点使不上劲儿。
这个要怎么理解呢？首先我们要明确ASPICE的一个特点。ASPICE标准采用的是一种“命题提纲”式的写法。十几年了，还在使用，并且我们一直没有听说，有什么大的错误，因为写得足够宽泛。
我们举几个例子。在 ASPICE 的供应商监控部分，他写了 5 条BP，分别是：
第一个BP是，要和供应商之间达成并且维护一个联合开发的措施或接口，使得信息可以进行交换（至于联合的过程，或者接口应该是什么样的，在ASPICE 里面并没有进行描述）。
第二个 BP 是，交换所有经过双方同意的信息。
第三个BP是，和供应商一起评审技术开发过程。
第四个 BP 是，评审供应商的进度。
第五个 BP 是。对偏差有所行动。
可以看到，这些BP，实际上是一种非常宽泛的行为描述。至于这个行为应该怎么做，在标准里面是没有体现的。
所以ASPICE的标准，有非常大的灵活度去进行解读。这也是为什么，在十几年的过程中，它一直没有什么大的错误的原因。它所说的这些过程，其实是一个正常的产品开发或者项目管理的通用过程。但是在当前这个汽车软件变革的阶段，我们需要的是，标准告诉我们怎么做，而不再是给我们一个命题作文。
从传统汽车向智能网联汽车转型的时代，所有人对这种新模式，都是处在一个探索的过程。这种探索既包括软件供应商，还有主机厂。如果ASPICE真是一剂神药，那标准的制订方之一，德国大众的新车，就不至于在停车场趴窝几个月了。
所以，这就是我的结论：传统的V模型开发标准，在当前这个阶段使不上劲儿，单纯的命题作文，在这个阶段不奏效，还需要实际的解题方法。
在当前这个阶段，越来越多的主机厂和新势力，采取了另外一种开发模式，敏捷开发。
敏捷开发尚未形成一个标准，而只是一些思想、工具和实践。敏捷开发，更多的好像是一个非常优秀的“考生”，写的一份备考指南，里面讲到了很多方法。这个考生上来就说：你不要想着一次就把事情做对、做完（因为事情太复杂了），你先去做就好了，做出一个原型，通过快速验证，你很快就能发现其中的问题，再去改，保证你的每一次，都比上次做得好，而且你的每一次，都是当前这个阶段最想要的。
然后他开始告诉你，这个过程中，你的武器库里面有多少武器可以使用，比如敏捷看板、需求优先级的排序、敏捷报表、功能回顾会、每日站会等等。正是由于这位“考生”写作的出发点，导致了很多争议。因为我们知道，同样一份考卷，同样一个应用题，不同的人去做，可以采用不同的方法，并且大家都能够做对。这就像，市面上有黄冈老师的答题技巧，也有人大附中的答题技巧，但是高考出题提纲只有一份。
敏捷开发这套思想的推动者，最开始并没有太大野心。他们想做的只是告诉程序员，告诉项目管理者，怎样去管理一个项目，怎样在不同的角色之间进行协作。它没有对行业做什么要求，它也并不是针对汽车行业的。所以这样的一种方法，在被汽车行业运用的时候，必然会产生很多的争论。
我之前也写过了一篇文章**《ASPICE 还值得做吗?》**，从评论中也可以看得出来，敏捷开发在汽车行业充满了争论。有些人对敏捷开发保持了冷嘲热讽的态度。实际上包括特斯拉以及国内的造车新势力，基本上都在采用一种小步快跑，持续迭代的的方式来做软件开发。特斯拉的FSD功能，在已交付的车辆上，以肉眼可见的速度进化和升级。当汽车行业很多头部企业，都已经在或多或少尝试敏捷开发的思想时，还有一些人仍然停留在自己的看法里。
当然，我们不得不承认的一个事实是，敏捷开发在汽车行业尚未得到大规模的认可，我觉得这个也很正常，当前汽车行业正在进行一场变革，在变革的过程中肯定是百家争鸣，大家都有各自方式。而且也未形成变革后的统一标准，在这个时候产生比较多的争论，是有益于行业进步的。
今天文章的主题，我想预测一下，汽车行业的软件开发标准，将向一个什么样的方向进行演进。
我预测的第一点是，V模型将吸纳敏捷开发的特点，形成新的标准。
虽然敏捷开发并未形成汽车行业的标准，但却有非常多的团队以此种方法来进行实践。
有很多公司找我们咨询汽车行业敏捷开发相关的工具链，我们发现他们或多或少都已经开始使用敏捷项目管理工具。业界对这种趋势应该有更加明显的感受。
在汽车行业新的软件标准中，我预计，一定会是接纳并且认可小步快跑、持续迭代这样一种思想的。V模型也不应该简单地被看作是瀑布流。V模型的编写方式，并未提到它是一个瀑布流。但是我们从它上下文的行文中，很容易把它理解成一个瀑布流。比如，在我们做软件架构设计的时候，一定是对软件需求分析已经经过了大量的讨论，经过了大家的认可，但是并未提到，如果需求本身不全会怎样？如果需求没有理清楚，没有经过充分的讨论，我们是否能够去做架构方面的设计？是否可以并行？需求是逐渐完善的过程、架构也是逐渐完善的过程，在完善的过程中，再逐渐去建立追溯性，是否可行？
变更在开发过程中，是不可避免的，但在ASPICE中，变更管理是一个支持性流程，好像变更并不是在每个过程中进行的，而像是项目做到一定阶段之后，反过来进行的、偶尔的偏差改动。但实际上，变更管理应该被提到一个更重要、更频繁的位置，因为在汽车变革的过程中，我们所做的很多技术和产品，不确定性是非常高的，我们会面临更加频繁的变更。
在产品的初期，我们可能没有办法考虑到方方面面，我们拥有的是一个产品的Roadmap。但是针对 Roadmap 里面的每一个功能点，可能并不是在最开始的时候，就去详细地写出所有需求的细节，而是在做的过程中不断完善。通过不断地交付出一些可工作的产物，对需求也会不断做出调整。
第二点，我预计新的标准，会对 BP 进行更多的细化，并且也会推荐一些敏捷开发方法。
前面我们已经举过例子，在ASPICE里面，BP一般写的都比较粗。具体怎么做，其实没有很多的方法推荐。我估计新的标准中，会比较多的推荐敏捷开发的方法。如果某种解题方法是比较好的，我们需要把这种方法在标准里面体现出来，虽然这并不是强制性要求，但至少给我们提供了一些参考。这样才能让标准能够逐渐融合敏捷开发。
第三点是，如何与第三方进行合作，将会是标准的重要组成部分。
在ASPICE原来的标准中，针对如何与第三方进行合作，其实篇幅很少，有一块叫做供应商管理。
但是，在新的标准中，如何与第三方合作，应该有大量的篇幅去解读它。在当前的汽车软件开发过程中，我们发现，联合开发变成了一种常态，导致了像 Tier 0. 5 这样一些合作方式出现。
在传统的标准中，我们一般只是强调，需要和供应商之间进行沟通，需要有与供应商之间进行信息交换的渠道，需要与供应商达成统一等等。
但在新的开发过程中，我们需要意识到，我们不仅与供应商之间会进行联合开发，与甲方客户之间也需要进行联合开发。而且联合开发的过程相比于原来会更加频繁和紧密，它不再是一个交钥匙的工程。对于一个软件或系统的开发，不同的软件组件可能是由不同的参与方来执行的。这个时候就要求我们在需求管控、问题管理上拥有更加实时的交流渠道，互相可以对对方提需求、提bug，并且大家好像是在一个管理系统上进行工作。这对于提升软件的开发效率是非常有必要的。
第四点是，CICD 将成为 BP 之一，缺少 CICD 的基础设施，意味着产品不具备持续迭代的属性。
在 ASPICE原来的标准中，对于持续集成、持续交付、持续部署，并没有特地强调。只是描述了针对软件的验证过程，需要有软件单元测试、软件集成测试、软件功能测试等等。更多还是强调，针对需求、架构、详细设计的可追溯性和完全覆盖。至于验证的过程要怎么做，并未提出要求。可以预见，未来甲方的需求会越来越多，且越来越频繁，CICD基础设施将是响应这一变化的关键。我们有一家做气体传感器的客户，其德方客户明确提出要求，研发过程必须上系统，且必须拥有统一的代码仓库和持续集成的能力（虽然这家客户本身的代码量不多，之前的代码全部放在工程师的电脑里进行管理）。但德方客户考虑到，后续市场或法规对于车内空气的更高要求，可能需要在更短时间内，提供更新迭代的产品。