开写前先唠两句,只要与开发工程师多聊两句,你就会很容易地发现,开发工程师几乎是一边倒的支持敏捷开发,笔者曾完整地参与过一次ASPICE认证项目,也在敏捷模式下进行过较长时间开发。从开发工程师的角度出发,使用敏捷进行开发的体验吊打ASPICE(或者V模型)九条街,但我们今天讨论的话题是哪种模式更适合“更快更高质量”地输出产品,而不是哪个模式对工程师更友好。那么我们就来探讨一下这两种开发模式在域控时代的适应性。 当汽车电子电器架构还处于分布式的年代,ASPICE(或V模型)可以说是唯一的答案,就没听说过哪家Tier 1或者OEM是使用敏捷去开发一个发动机控制器的。到了域控时代,新的玩家入场,开发逻辑出现不同声音,特斯拉,蔚小理等硅谷/互联网背景出身的新玩家都使用敏捷进行开发,做出来的产品用户体验确实让消费者有种“诺基亚转安卓”的感觉,难道说敏捷就有如此大的魔力?可以给软件赋予生命力?ASPICE和敏捷的差异和思路究竟在哪? 1. ASPICE:堂正之师1.1. 简述ASPICE的核心思想就是DRIFT(Do things right in first time),ASPICE认为:
因此,ASPICE讲究走一条最康庄平坦的大道: 一份不偏离相关方(stakeholder)意图的工程需求---->按照意图,考虑所有corner case,基于选型芯片资源,设计考虑完备的软件架构---->将软件架构进一步细化到模块与函数级别的详细设计---->与详细设计思路一模一样的编码---->验证是否与详细设计一致的单元测试---->验证是否与软件架构设计一致的集成测试---->验证是否与软件需求一致的合格性测试。 说白了,就是:
1.2. ASPICE的缺点ASPICE统治了汽车软件这么多年,自然有他的必要性与优势,但ASPICE的缺点也非常致命: 1. 难以拥抱变化 从上文可以看出,一套V模型撸下来,都是一环套一环的,下一步的输出完全依赖上一步的输入,如果需求发生了变更,而且需求还是与原需求互斥的,那整个项目的改动量将是灾难性的。所以有些OEM的DRE可能会很疑惑,为什么看起来一个小小的CR(change request)发下去,会被Tier1告知一大笔的开发费用,甚至是拒绝?流程可能就是其中一个原因。只要代码需要变更,好嘛,相应的设计文档作废,重新设计,测试重新做……想想都头疼。而国内的项目氛围又是“最爱”拥抱变化的,hmmm…… 2. 对人力消耗巨大 我贴一下SWE.3(软件详细设计与单元开发)的BP出来给大家感受一下 随便说几个工作量大到离谱的:
其实每个BP要求的工作量都很大,我做过大概的统计,执行ASPICE的人力需求是不执行的3倍,除此以外,就像我之前说的,这个流程既是开发流程,也是质量证据,属于监管与被监管的关系,繁重的文档任务深深的打击了工程师的积极性。 2. 敏捷开发:短平快,拥抱变化2.1. 简述敏捷开发的核心逻辑是解构,把软件需求分解成Epic or story,通过一轮开发迭代(sprint)实现相应的功能。一轮sprint包含:需求确认->方案制定->coding->台架验证->实车验证->rolling candidate版本验证->代码合入 敏捷的优点在于:
2.2. 敏捷的缺点说完敏捷这枚硬币的正面,下面说他的反面。 相比ASPICE或者V模型,敏捷少做的事情:
3. 谁是自动驾驶时代答案?两种开发流程各擅胜场,也有其出现的背景,在传统汽车时代,各个控制器没有花哨的功能,但要求软件稳定可靠,这种情况下,使用ASPICE或者V模型进行开发无疑是非常正确的。 域控时代的来临,最主要的变化有三点:
我的观点是:ASPICE不适合用于开发智驾域控软件,敏捷相对更合适,但必须根据汽车软件的特点,进行适配 (一家之言,如果有使用ASPICE完整开发过智驾域控到SOP的经验,非常非常欢迎留言探讨) 3.1. 为什么ASPICE不合适用于开发域控?第一,ASPICE下对发生变更的代价是巨大的,因此需要一次把所有功能都定义,设计完美。然而在域控这种软件复杂度下,我不认为有哪个人或者团队可以在项目开发初期,就能一次把所有的需求都定到完美。不完美,后期增改功能,好嘛,又一轮完整的V迭代,所有文档改掉,软件配置管理做版本管理,恐怕需求没开发完,工程师跑一大半了。 第二,退一万步讲,就算有优秀的产品团队可以一次把所有需求缕清,肯定也需要漫长的时间,试想下,两家公司同时开始项目,使用敏捷的小步快跑,不断试错,都已经有产品在投放市场了,使用ASPICE的可能还在需求制定阶段…… 3.2. 敏捷开发需要做什么适配?敏捷开发需要克服的困难主要在于提升软件质量和满足功能安全要求。
|
|