为什么汽车软件需要开发工具链呢

01.

为什么汽车软件开发需要工具链

 “软件定义汽车”已经达成了共识，对于汽车，软件变得如此重要。如何在短时间之内交付出质量很高，并且又受用户欢迎的软件就至关重要了。汽车行业常见的标准是V字形开发，主要以 ASPICE和 ISO26262为代表。以这套标准作为汽车软件开发的模式，已经有差不多快 20 年的时间了。

国内的新势力造车差不多是从 14 年才开始的。有一个很明显的现象，造车新势力蔚小理，他们软件开发迭代的速度一直是他们的优势，蔚来的车型，即便在交付给车主之后，仍然可以做到每月一小迭代，每三个月一大迭代。这些优势就是借助了软件开发工具链，包括CICD（持续集成、持续交付、持续部署）、OTA等一系列技术。 这就是为什么汽车软件需要开发工具链的原因。

在ASPICE的诞生地德国，咨询公司Knüvener Mackert 楷迈德、KUGLER MAAG CIE，也在积极讨论 ASPICE 和 Agile 融合的事项，并希望推动标准建立。他们是否有可能在近几年的时间内，推出一款融合后的标准，我们拭目以待。  

02.

什么样的工具链是不合适的？

汽车软件对于开发效率的要求逐渐提高，但在造车新势力之前，工具链的设计并没有过多考虑效率这个需求。因为大家已经习惯了一款车型的开发需要3-5年，已经习惯了由供应商负责软件开发，已经习惯了软件开发只需要遵循V字形即可。

但随着汽车行业开始逐渐接纳敏捷思想，越来越多的汽车软件公司，开始考虑那些并不是直接针对汽车行业的软件产品，它们的产品设计上，带有很强的敏捷开发思想，比如Jira、Ones、Pingcode等。 那么究竟什么样的工具链是汽车行业想要的呢？想要搞清楚这个问题，我们首先要知道什么样的工具链是汽车行业不想要的。我根据自己的工作经验总结了以下几点。

第一，工具设计单纯只是为了满足标准的，而不是为了便于工程师工作的

如果一款工具，在使用上不考虑用户友好性，不管能满足多么高大上的标准，那都没有太大实用价值。比如权限设置得过于复杂，没有权限的人又没有得到任何提醒，或者也没有去申请权限的入口，导致用户只能被动地接受权限设置。我们观察到一种现象，有一些汽车软件团队，出于ASPICE或者功能安全的认证需求，去购买某些工具，他们希望通过标准，去搭建团队的研发流程，并最终达到步调一致。他们的本意没问题，最后也通过了认证，但通过之后，发现工具并不高效。他们试图把工具配置得更高效，但由于工具本身支持的流程很重，即完全按照标准流程来使用，一旦偏离了标准流程，工具反而成为了束缚。于是他们把一部分流程还放在这个工具里，另外一些流程则放到另一个工具里，组成了一个拼接的工具链。这违反了下面讲到的第二条经验。

第二，由过多的工具拼凑而成，感觉在使用多款不同的工具

如果我们要需要满足ASPICE标准，那至少会包含16 个域的工作内容，包含需求分析、架构设计、详细设计、测试用例等等。我发现有些团队出于各种各样的原因，使用开源工具Redmine去做问题跟踪，然后使用其他工具（比如doors）去做需求管理，最后还使用了 Excel 做线下的测试用例管理。但工具链的搭建需要一个全局的视角，并不是首先满足局部功能，再把所有工具组装起来就行。

工具链的搭建，既要考虑工具能否打通，还要考虑打通之后的易用性。就算购买了一堆王牌工具，每个工具在自己的领域都是佼佼者，但工具之间如果不支持很好的打通，工程师登录之后，完全像是在使用不同的工具。最后的结果是，每一款工具，都需要付出很高的学习成本，工具费用付了不少，但使用体验却大打折扣。 这块儿我也可以举一个例子，我之前工作过的一家公司，需求管理、任务管理、Bug管理，使用的是Jira，最开始的时候，由于团队开发进度很快，测试管理几乎是没有记录的，纯靠工程师的经验。后来逐渐地通过 Excel 做线下管理。

再后来发现测试用例实在是太多了，改为用开源工具 testlink 来管理。 但testlink 几乎可以说是没有任何美观方面的设计，完全就只是为了满足功能。测试用例需要支持和 Jira 做对接，当时我们花了比较大的力气来打通 testlink 和Jira，但是使用体验并不是特别友好。比如说，在 testlink 里的测试用例成功或者失败之后，这个结果不能直接反馈到Jira那边的需求下面，也无法在测试用例侧创建bug，从需求，到测试用例，再到bug，整个追溯性建立的过程就比较别扭，最终也无法出具需求的覆盖度报告。

第三，过多使用线下工具

在我上一篇文章里面，我举了一个例子，说有些团队是用 word 来实现追溯性的。有很多网友说不对，ASPICE没有说要用 word 来实现追溯性。我同意这位网友说的，ASPICE甚至通篇都没有告诉读者，需要用什么工具来实现，这正是它的特点：只提出要求，不给出方案。使用线下工具有一个非常明显的缺陷：无法作为团队协同的工具，一旦有变更的话，无法实时反馈给团队其他人。

有些团队说，可以把 Word、Excel 放到公共盘里面，大家都可以进来编辑，以此实现协同。比如说直接放到公共盘里面，这种时候就要考虑到多人无法同时编辑的情况，影响编辑效率。有些团队将公共盘换成SVN，这样的话可以解决多人同时编辑的问题，但是这种方式，任何人是不能够实时看到文件的，必须把它打开或者下载下来。当存储的文件过多的时候，整个效率体验都会受到影响。而且SVN本身的工作流并不直观，对于非开发人员，是有较高的学习成本的。

第四，学习曲线陡峭的，设计不合理的，需要反复培训的

这块儿我举一个真实的例子，有一家国外公司，专门做针对汽车行业的研发管理软件，他们的产品本身也提供SaaS 注册。国内有一家新手客户问，可以注册你们的产品试用一下吗？销售回答说可以，但是你们可能不会用，需要我们至少来给您培训一个月才会使用。 如果工具需要售前培训一个月才能使用的话，这个工具本身的设计就是不合理的。

说明他的学习曲线特别陡峭，或者它的界面的设计可能是不合理的，是违反人性的。从来没有听说微信需要培训一个月才能使用的，最近传播度很高的飞书办公工具，一天差不多就能使用，使用一个星期，整个团队差不多就能在上面自如的工作了。

第五，缺少线上培训资料的，发现问题只能由原厂解决的

这点我也是深有体验。我觉得在这块做得非常好的公司，是澳洲的atlassion。很多人认识它，是从Jira工具开始的。Jira作为一款优秀的敏捷项目管理软件，在国内的使用范围也非常广，很多人被Jira强大的功能和生态能力折服。任何时候有关于Jira的任何问题，不管使用的是哪个搜索引擎，在互联网上随便搜一下关键词，都会有大量的视频、论坛文章去解答你的疑惑。

与此相反，有另外一款汽车行业的研发管理工具，去互联网上搜它，不管是在墙内还是墙外，不管在任何的视频网站，都会发现，它的使用教学视频非常少。如果在使用中发现问题，只能靠团队里面已经踏过坑的人来告诉你。或者也可以向原厂求助，但是他的原厂又在国外，在国内只有销售代理。这种时候就会发现，整个软件的使用体验变得特别差。  

03.

理想情况下的汽车行业工具链

那究竟什么样的工具链才是汽车行业想要的呢？这块我基于我们自己的产品设计理念，总结了一些经验，供大家参考。

第一，工程师满足ASPICE标准的过程不繁琐，同时又能让工程师高效工作

说到高效工作，在软件开发里面，效率比较高的必然会提到敏捷开发。虽然敏捷开发是否要引入到汽车行业还在争论不休，但我们都无法忽视一点：敏捷开发在在开发效率方面，确实有它独特的优势，所以汽车行业的工具链，至少也必须预留出，能够实现敏捷开发的入口。 ASPICE的标准那么复杂，超过100 页，那么究竟要如何满足哪些标准呢？我也总结了几点，供大家参考。这些也是在以前的工作中，我自己觉得难度特别高的。

第一块是追溯性。追溯性意味着，能够从需求，追溯到架构，追溯到详细设计，追溯到对应的所有测试用例，追溯性建立的同时，又需要考虑可操作性。像我上一篇文章举的例子，使用word、excel，追溯性是建立了，但工程师累死了，项目越复杂，操作难度呈指数型增长。渐渐地，工程师就会放弃主动建立追溯性了。

第二块是文档合规性。文档合规性意味着，需要有测试计划的文档，需要有测试执行相关的记录，需要有需求分析文档，需要有架构分析文档等等。这就意味着，工具不仅要支持敏捷开发，能把所有的任务项都拆分成一条一条，便于跟踪，同时也能够支持文档性的阅读。在必要的时候是可以直接导出成文档的。

第三块是基线管理。这个我认为在汽车行业是特别需要的，在ASPICE标准里面也提到了基线管理的重要性。这块在互联网，并没有像汽车行业这么重视，汽车行业的供应链比较长，涉及到的供应商比较多，对于变更尤其谨慎，而且变更可能意味着重新开模，代价非常大。所以基线管理和变更评审这两块一般来说是一起的。团队一旦制定了一条基线，就意味着在今后可长可短的一段时间内，都是基于这条基线来开发。如果基线本身发生了变化，那么整个团队是需要很方便地获得通知的。如果不知道的话，整个开发测试流程都会形成障碍。最后造成开发出来的产品，和需求不一致的情况。

第四就是变更评审。由于变更会造成整个上下游和合作方都会受到影响，所以汽车行业的变更评审一般是由变更委员会来进行共同评审的。评审通过之后，才能够正式地被放到 backlog 中，以待后面的开发。 说到变更评审，首先是需要有多人评审，其次是需要有评审记录的。很多团队把这个过程放到线下，但需求、开发任务、测试用例等等，一般是放在线上的，而变更又直接影响了需求、开发任务、测试用例，这就导致了线上线下的不一致，或者说从线上追溯到线下，再从线下追溯到线上，可操作性很差。

第五就是线上测试管理。一般来说，测试体系的建立，相对是比较晚的，很多团队，最开始的时候都没有测试用例，完全靠工程师的经验手动随机测试，随着开发的进行才开始逐渐完善测试用例管理，实现测试自动化。在完善的过程中，很多团队还是习惯于用 Excel 来管理测试用例。这也造成了一个问题，如果需求、开发任务、Bug都已经在线上系统中跟踪，但是测试用例又放到了线下，线上的需求和开发任务会根据需求变化不断迭代，这就意味着，测试用例也需要不断迭代，有时候可能还需要保存测试用例的不同版本。线下管理的复杂性就会大大提高。线下管理测试用例的另一个难点就是，不方便出具测试报告。测试执行报告可能还行，但是Bug 遗留的情况， Bug 状态的分布，需求覆盖度、测试用例覆盖度等报告，就非常难以提供。

第二，使用一站式的工具，或者至少使用体验是一站式的

最佳的情况是，能够在一个工具上执行所有过程，比如说系统需求分析、系统架构设计、软件需求分析、软件架构详设计、详细设计、代码管理、CICD、测试管理，项目管理、质量管理、供应商管理、问题管理，变更管理等过程。 有一些工具号称自己是汽车软件开发全生命周期的解决方案，至少在我看来虚假宣传的。比如说在代码管理这块，目前很少有可能绕开 Git、SVN 这些工具的。

如果这些工具都没有号称能够提供汽车软件开发全生命周期的解决方案的话，其他的工具就更不可能了。所以有些时候我们不得不打通几款工具，打造出一款满足汽车ASPICE标准的工具链。但是我们必须记住一点，引入的工具越多，打通的成本就越高，对于工程师来说，学习的成本越高，使用体验上肯定是会有影响的；对于公司来说，意味着费用越高，人效越低。所以要尽可能少地使用工具，如果确实需要纳入多个工具，至少在使用体验上需要尽可能地保持一致。

第三，学习曲线是平缓的，有很多线上的学习资料和线上的交通渠道

这一点在汽车行业可能没有那么受重视。 长期以来，虽然汽车是一个to C 端的产品，但是它的销售方式，是先把车辆销售给 4S 店，然后再由 4S 店销售给具体的每一个用户。4S 店对客户的反馈不怎么感兴趣。他们感兴趣的唯一的点就是，如何在尽可能短的时间内把车辆销售出去，减少库存。这种倾向，似乎也传递到汽车软件研发管理上。

虽然研发管理工具的销售本身是 to B 端的，但是最终的用户，是每一个具体的工程师，因此工具厂商需要和 C 端建立一个良好的通道。当工程师有任何问题的时候，都能够在线上找到很多的学习资料，并且线上是有交流渠道的。

第四，能够平滑扩展到 ISO 26262

一般来说要做满足ASPICE标准的工具链，后续有极大的可能会做功能安全相关的。假如在做功能安全相关的时候，又要使用另外一套工具，这就会造成工具本身的增加。但ISO 26262和ASPICE是非常相似的，很多过程，甚至可以直接使用ASPICE的一些做法，只不过在功能安全的评级层面，有一些自己独特的东西。



审核编辑：刘清