摘要：“想清楚再干”，还是“先干了再说”？敏捷开发模型提供新思路
文 | 王怿恺 桂灵峰 祖欣然 曹裕
编辑 | 王静仪
软件定义汽车已成汽车行业共识。软件正深度参与到汽车定义、开发、验证、销售、服务等过程中，并不断改变和优化各个过程，实现体验持续优化、过程持续优化、价值持续创造。
在面向软件的组织方式下，传统的软件开发模型显得太过复杂庞大，在应对灵活多变的客户需求时，显得冗长拖沓。这体现在结果上，就是整车厂即使把软件提到了企业战略的高度，其在关键控制点还是会出现战略不清、组织分工不明的情况，使得整个组织在数字化转型、软件技术开发相关的领域里决策失效。
因此，源自科技行业的敏捷开发模式逐渐被初创车企采用，并逐渐普及到全行业——对软件架构进行模块化分解，形成标准化、即插即用的组件，以适应软件产品的快速迭代，并达到节省开发成本、提高开发效率的目的。
与此相对应的，车企在组织与流程、资源与能力、心态与文化方面都需要做出调整。我们认为，传统车企面向软件的转型，需要推进开发流程的敏捷度、提升组织的灵活度，具体涉及五大核心能力，历经三大关键阶段。
01
研发投入很大，但效率高吗？
我们发现，整车厂和主要高科技厂商在软件研发方面的支出有明显区别。
谷歌每年的软件研发支出是320亿美元，苹果是220亿美元，在所有统计对象中遥遥领先。在整车厂中，大众汽车集团和旗下软件公司Cariad的软件支出最多，为每年35亿美元；随后是丰田，每年20亿美元；梅赛德斯、斯特兰蒂斯、宝马、福特、通用等老牌整车厂，每年在软件研发上的开销大概在8亿美元到15亿美元之间。
我们留意到，Rivian、特斯拉和蔚来等初创车企，也致力于大力投入软件研发，每年花在软件上的钱分别是7.5亿、6亿和5.5亿美元，甚至投入规模超过了部分传统整车厂。
总体投入规模和车企销量规模有密不可分的关系，这也是大众和丰田作为全球汽车销量前两名，在软件研发上的投入同样领先行业的原因之一。因此，研发效率，也就是单辆汽车的软件研发支出，是同样值得关注的指标。
数据显示，Rivian和蔚来的单车研发成本最高，都超过了1000美元，每辆车上的软件研发成本分别是1500美元和1100美元。当然，这是因为两家初创车企的销量规模还比较小，在总体投入规模大的前提下，单车成本无法被摊薄。
更值得关注的信号是，传统车企的单车研发成本高。比如梅赛德斯的单车软件成本是750美元，宝马是400美元，大众汽车集团和旗下软件公司Cariad的这一数字是350美元。
传统整车厂的单车研发成本高，这背后有三个方面原因。
首先，传统整车厂在新技术领域，尤其是软件技术方面的投入和成熟度并不高，导致即使把软件提到了企业战略的高度，其在关键控制点还是会出现战略不清、组织分工不明的情况。
以德系整车厂为例，新成立的软件部门关键岗位人员往往还是以传统汽车背景，甚至是硬件工程类背景为主，使得整个组织在数字化转型、软件技术开发相关的领域里决策失效。
另外更直接的影响也在于，软件相关智能网联功能的开发周期，在保证高可用性体验和更新及时性的同时，无法与传统硬件周期有效协同。这一系列的“运行不畅”可能会进一步造成产品管理、生产、乃至营销体系的堵点，从而造成不可避免的管理成本。
我们在初创企业里面看到的精英团队主义、明星产品经理主义，是以团队的主观能动性，组织的敏捷性，和精英向的企业文化为前提的。针对这类企业，软件研发投入高的原因主要还是对于自研比例的追求，还有前期“学费型”的投入过高。
以蔚来为例，其在软件领域的组织能力形成也走过了相对较久的摸索期，深深体会到对于“想要何种数字化体验”、“软硬件载体和环境选择”、“自研还是外采”、“需要哪种研发协同组织“、”招募哪类人才和如何激励”这几个阶段的从无到有，其实没有捷径可走。
其次，在市场需求理解层面，双方也有区别。
传统整车厂由于受到内部话语权和产品规划设计流程机制影响，对客户需求及其体验水平缺乏系统化定义，尤其是创新功能与服务，个人主观判断仍占主导。
尽管普遍采取定期调研、第三方数据整合等做法大量采集数据，但用户需求的盲点依然存在，且对所得数据的系统化处理、大数据分析能力等尚待提升。即使能够在当前产品周期开始之前及时获得了准确的客户洞察，仍需要多部门高效地把洞察转化为产品定义的需求，并整合到全生命周期管理的环节当中去。
最后，在合作伙伴层面，传统整车厂的集采加整合的路径，在数字化软件领域不再适用，导致不得不重新摸索全新生态环境下，与软件开发商、内容和数字化服务提供商的合作模式。这就意味着全新的供应商体系搭建，包括能力评估要求、合作框架，甚至数字信息的合规化运营。而每一项变革都会给厂商带来额外的运营成本。
对于大部分日系美系、及部分欧洲整车厂而言，软件研发投入比例还没有那么显性的原因，或许是在于各厂商的战略野心与实际落地方案之间的平衡，虽然耗时，但事实上大部分整车厂还是更愿意“想清楚再干”。
因为在搭建软件能力和数字化产品体系的同时，务必会带来更多与终端客户的数字触点，如何规整这些触点的体验，让其能够传递一致的品牌信息与调性，并让这些额外产生的数字交互为己所用。
这样往小了说，能够承接各条线的业务目标和战略，比如网络直销带来的增量销量，和用户社区带来的用户粘性；往大了说，就能加速拉动整体研发组织的数字化转型，比如设计与测试阶段的仿真应用，更进一步打通软硬件周期、赋能技术创新。
以此为愿景，我们可以预期接下来很长一段时间内，这些后发制人的整车厂或许会出现更高比例的投入支出。
02
旧模型日显拖沓，源自科技行业的新模型顶上
目前应用V模型进行软件开发是整车厂的主流，也是A-SPICE（Automotive Software Process Improvement and Capability）这一汽车行业广泛应用的软件开发体系的基石。
V模型将软件开发过程中的技术要求、需求分析、开发、以及测试环节以V形排布。从整体，到架构层，到系统层，到功能层进行需求分析，再开始开发，待开发工作完成后，又逐层向上从功能测试，到系统测试，到整车测试认证，以及系统集成工作。
通过应用该模型，汽车整车厂可以一步步深化拆解分析需求，在开发后，又能够自下而上的层层验证测试。该模型能够很好的满足车企对于大型复杂系统和软件的管理需求，因而得到了欧美系车企的大力推广和应用。自A-SPICE于2005年发布以来，越来越多汽车整车厂不仅在自身的研发部门需要使用，甚至开始要求其Tier1一级供应商在进行软件交付时也要应用V模型并符合A-SPICE的标准。
但问题是，传统的V模型软件开发则太过复杂庞大，在应对灵活多变的客户需求时，显得冗长拖沓。随着中央计算架构的不断发展，以及OTA的逐渐普及，终端功能性应用的日益增多，整车厂也越来越多地需要快速迭代软件版本，以满足客户需求，同时在与其他车企竞争中能够保持领先一步。
举例来说，一个完整的V模型开发过程，通常需要12个-18个月的时间，而软件更新在V模型下也需要3个-6个月的时间，而这显然是无法满足客户需求的，因此整车厂开始引入敏捷开发（Agile）模式，希望能够在部分需要快速迭代的软件功能开发上，实现对消费者需求的快速满足。
何为敏捷开发？这是一个闭环的开发流程模型，从规划，代码，编译打包，测试，发布，部署，到反馈，调整持续改进，并最终回到规划环节。可以看出该模型的特点在于以客户为中心，持续获得反馈，持续改进；由于不像V模型那样每次都将收集获得的全部需求统一分析处理，而是分布式渐进式的逐步改进调整，因此其软件开发以及版本迭代的时间也被大幅缩减。
V模型和敏捷模型这两种开发体系，在适用软件特性、开发时间、灵活度以及对客户需求的反应速度上存在差异。比如敏捷模型更多应用于智能驾驶舱、互联网等相关应用，而关于动力总成、电池等仍然需要依照V模型，其中具体功能可通过敏捷方式迭代。
长期来看，两者会共存，也因此整车厂需要熟练掌握这两类开发体系。对于V模型，各个整车厂近年来已经有了较多的应用；对于敏捷模式，由于是从高科技行业引入，传统整车厂还需要进一步掌握该流程的使用，而具有互联网基因的新兴整车厂如特斯拉、“蔚小理”（蔚来、理想、小鹏）等，则已经能够比较好的应用该模式进行开发工作。
03
五大核心能力，三大关键阶段
根据敏捷开发模型的特点，我们分析了从开发测试到部署再到改进优化的端到端流程，并提炼出了实现卓越开发的15个赋能手段，帮助整车厂更好地实现敏捷开发。
15个阶段的赋能手段可以根据整车厂对敏捷开发的应用熟练度分为三个阶段，分别是“敏捷软件开发能力建设”，“敏捷软件开发可规模化扩张”，以及“敏捷软件开发成为战略优势”。
其中第一阶段可谓重中之重，是二、三阶段顺利开展的先决条件，整车厂需要在第一阶段夯实能力基础，包括以功能为导向的敏捷开发、以功能为导向的软件设计与架构、关键人才赋能的软件开发、端到端测试与集成的自动化更新机制和已售出车辆的持续更新与集成流程，后续才能在中长期的第二、三阶段发挥优势。
接下来我们会重点分析第一阶段的五大措施。
第一，以功能为导向的敏捷开发，意味着在代码阶段，就需要一个以功能为导向的敏捷开发组织，其人员一般来自于传统的部门架构，由业务单元高层管理人员、工程与软件团队的核心人员、以及开发工程师组成，但其工作方式则以功能开发为导向。
在职能分工上，不再强调人员在企业内的上下级汇报关系，而是会设定一个核心领导负责项目规划、时间计划以及功能集成，其他人员则包括：系统经理负责项目预算及资源调配，测试工程师负责验证，软件硬件工程师负责软硬件需求分析、方案设计与集成，客户需求服务工程师负责分析客户需求及其解决方案规划，制造工程师负责在硬件制造方面的需求对接与系统集成。该团队在敏捷开发的规划阶段一起工作，然后将并行开展开发和集成与测试工作。
这样的工作方式可以最大化地实现以客户需求为导向，以产品为核心的开发，以及成本高效的持续迭代。
第二，除了开发团队以外，也需要在代码阶段考虑以功能为导向的软件设计与系统架构。中央计算架构在此则起到了重要的作用。现今虽然中央计算架构被各大车企反复提及，但真正得到实际量产应用的平台并不多，以特斯拉为例，其中央架构涵盖了目前与客户感受最相关的自动驾驶域、座舱娱乐域以及网络安全与车联网域。基由此设计，可以将软件需求拆解为上车软件以及后台软件，通过网关实现交互。
这样的中央平台架构可以实现通用的软件设计，并且能够应用一个软件版本去覆盖大多数在售车型。综上所述，有中央平台架构做基础，通过高成本性价比的架构，高通用性的软件，以及基于不同平台定制化的模块软件，能够帮助整车厂实现卓越的敏捷开发。
第三，也需要在人才层面进行储备、培养与赋能，并建立起与之匹配的人才机制，进行关键人才赋能的软件开发。
在人才储备层面，需建立起完善的招募与培养机制来保证具有全局观或是具备某个模块专长的技术人员储备——包括整车系统层面、应用层面、车联网方向、移动端开发方向等；
在授权管控层面，创建扁平化的决策委员会机制，并充分考虑技术因素与决策的敏捷性。决策委员会成员以各BU主要负责人和技术领导人作为主导，其他各相关方辅助配合，保证决策会议有效记录，会议结果的输出是产品特征优先级排序；
在赋能机制层面，充分赋予每一位工程师参与产品建议的权力，充分调动每一位技术人员的积极性，以保证全员参与到产品提升的过程中。
这样的人才机制能够大大提高流程效率。通过将决策权交给真正有能力的工程师，能够最大限度地发挥人才潜力；通过扁平化和高效率的决策流程能够快速应对消费者反馈与市场变化。
第四，建立端到端测试与集成的自动化更新机制。持续集成和持续交付需要快速完成计划、编码、测试、发布的循环，自动化的测试和自动化的发布是不可或缺的组成部分。而这一过程应用于每一次提交，意味着每一次代码的提交、合并都会经过自动化的测试，成为一个新的发布版本。
以特斯拉为例，在硬件、系统与整车层面建立平行测试机制，依托Jenkins开源软件工具创建自动化的测试体系，在每一次软件版本更新迭代后自动触发。依次通过软件虚拟模拟、真实/虚拟外设环境下的硬件测试、真实外设环境下的系统测试、整车系统测试、真人道路测试环节，其中硬件、系统与整车层面的全部测试能够在20小时内完成，从而使得全部测试时间控制在24小时以内。
这样的自动化测试机制提供了一个全自动的中心化测试机制，使得全部测试与集成能够在24小时内完成，并且可以在无需更改已经通过验证的功能下完成自动化更新。
第五，对于已售出车辆的持续更新与整合也是卓越开发的重要一环。根据软件开发的分支管理模型，分别按照软件开发、软件测试和已售管理三个典型分支进行（实际可能存在更多分支），并对应单一的数据存储库。
以特斯拉为例，对于开发分支而言，在软件构建阶段保证每周200次的更新，以及测试与集成阶段每周7次更新和15%的完成率；对于测试分支，在软件构建阶段保证每周30次的更新，以及测试与集成阶段每周14次更新和50%的完成率，以及在现场部署阶段每周0.5次更新；对于客户分支，在软件构建阶段保证每周20次的更新，以及测试与集成阶段每周10次更新和80%的完成率，以及在现场部署阶段每周3次更新。
这种已售车辆的更新与集成模型以模块化发布的方式进行，能够根据发布的准备成熟度来保证集成或是排除某一特定功能。并使得功能分支在单一的存储库中随时更新，尤其是对于已售车辆的客户端功能保持在80%及以上部署完成的状态。
经过敏捷模型第一阶段的发展，整车厂将完成向敏捷软件开发的初步转型，并形成以下五大核心基础能力，为“敏捷软件开发可规模化扩张”（第二阶段），以及“敏捷软件开发成为战略优势”（第三阶段）奠定坚实基础：
1．以客户需求为导向、软件功能为核心、贯穿规划-开发-集成与测试环节的敏捷组织架构。确保全员围绕敏捷开发为核心愿景，进行全链路资源的长期合理分配；
2．基于中央平台架构的模块化、通用化、定制化软件设计体系。以优异的性价比和适配性助力整车厂实现规模化扩张；
3．软件人才的长期储备、培养与赋能体系。激发精英人才潜力，提高流程效率，持续保障产品竞争力，并为最终实现敏捷软件开发战略优势提供长期人才支撑；
4．高效的端到端、全自动、中心化测试与更新机制。大幅缩短软件更新迭代周期，形成以市场敏捷应对为核心的软件开发战略优势；
5．模块化的已售车辆软件持续管理与更新机制。基于功能成熟度匹配最合理的发布周期，有效平衡功能部署完成率与优质的客户使用体验，降低已售车辆管理复杂度，以实现更为快速、平稳的规模化扩张。