一、敏捷开发方法在汽车电控软件开发中的应用

1、什么是敏捷开发方法？

敏捷开发方法百度百科的解释是：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发方法的具体应用流程：通过客户需求提炼出产品功能列表，通过计划会讨论需要完成的阶段性的产品功能列表，工程师开始开发-测试-发布的迭代过程，并进行功能的细化，每天都会进行每日站会，完成后交付阶段性的产品功能软件，用于软件发布应用。每次迭代过程工作主要包括：计划会议、每日站会、开发工作、评审会议和回顾会议。

1.1 敏捷开发框架参与人员

根据上图，发现Scrum敏捷开发框架中人员包括：产品负责人Product Owner,教练及团队带头人Scrum Master，开发团队Team。

Product Owner：产品负责人。定义产品功能，决定产品发布，根据市场变化对功能排列优先级，调整产品功能和迭代顺序，认同或者拒绝迭代的交付。

ScrumMaster：教练及团队负责人。领导团队遵循Scrum的原则、方法，排除团队遇到的困难，确保团队高效率的工作。

The team：开发团队。团队成员包含开发人员、测试人员、外部验收人员等等。

1.2 Scrum 整个开发过程分为五个会议

1）待办事项整理会议

由产品负责人将下次需要迭代的用户需求，描述给团队成员，教练及团队成员说出不理解的地方进行讨论，通过完善和解决，最终形成产品功能列表。

2）迭代计划会议

接下来的 Sprint 交付的增量中要包含什么内容？要如何完成交付增量所需的工作？

3）每日站会

每日站会上团队成员需要回答以下3个问题：昨天，我为帮助开发团队达成阶段性功能需求目标做了什么？今天，我为帮助开发团队达成阶段性功能需求目标准备做什么？是否有任何障碍在阻碍我或开发团队达成阶段性功能需求目标？

4）评审会

评审会议在阶段性迭代需求任务快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。在小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。

5）回顾会议

回顾会议的目的在于：检视前一个需求迭代任务中关于人、关系、过程和工具的情况如何；找出并加以排序做得好的和潜在需要改进的主要方面；制定改进 Scrum 团队工作方式的计划。

2、为了推动敏捷开发在全世界的行业应用，发表了敏捷宣言，什么是敏捷宣言？

个人和交互重于开发过程和工具

可用的软件重于复杂的文档

寻求和客户的合作重于对合同的谈判

对变化的响应重于始终遵守固定的计划

3、为什么汽车行业要使用敏捷开发？

如今汽车行业的内卷，并且类似于自动驾驶项目，没有明确的开发需求，以及市场竞争激烈，新鲜科技事物的属性，百家争鸣，百花齐放，谁先发布产品谁就占领市场。敏捷宣言中也提出对变化的响应重于始终遵守固定的计划，因此，引入敏捷开发方法对于类似自动驾驶的项目开发有着重要的优势。

敏捷开发方式，让汽车有持续的生命力和不断产生的价值。通过软件的不断快速迭代和交付，能让客户对汽车产品有新鲜感，有利于品牌价值的提升。

高效，在开发过程中，客户，开发人员和产品负责人强调以客户的需求不断更新，以产品为目的，而不是流程和工具。

敏捷开发模式能够使得开发人员关注产品，通过快速的迭代优化和发布，使得产品性能更优越，让产品保持持续的竞争力。

4、敏捷开发使用的工具有哪些？

产品代办列表：以用户故事的形式来建立产品待办事列表，参考网络上的模板。

冲刺列表：当迭代任务开始后，就会制作冲刺列表来记录当前各个需求所处的开发状态。

燃尽图：显示未完成的需求数量，总体目标数减去已经完成的需求数，按照时间进度的进行排列，用来直观地显示功能开发的进度。

5、敏捷开发方法的如何应用？

对应的软件核心迭代流程就是：总体需求库进行分解为需求组1、需求组2、需求组3、等等。需求组1-开发1-测试1-发布1-需求组2-开发2-测试2-发布2-需求组3-开发3-测试3-发布3。

在需求组1、需求组2、需求组3每次需求迭代的过程中进行计划会议（迭代前）、每日站会（迭代中）、开发工作、评审会议（迭代完成时）和回顾会议（评审会议结束后），并结合敏捷开发的工具，来实现产品按时按质发布的目标。

6、总结

敏捷开发流程确实是很敏捷的，流程简单易用，通俗易懂，但是对于开发人员的专业素质要求很高，要求团队的每个人都是极其专业的人员，能面对各种挑战。同时，敏捷开发流程过于太敏捷，文档记录的方面确实存在欠缺，特别是全新的项目，有着不稳定的因素，因此，需要裁剪其它的开发流程进行融合开发。

二、敏捷在嵌入式软件开发中的应用

引自 < Design Patterns for Embedded Systems in C >

软件开发中的敏捷流程

引言

传统的嵌入式软件开发常常面临诸多挑战，例如：客户需求变化频繁、开发周期漫长、软硬件集成困难、测试验证复杂等。传统的瀑布式开发模型在面对这些挑战时显得力不从心。而敏捷开发作为一种迭代、增量式的软件开发方法，以其快速响应变化、提高开发效率和产品质量的优势，逐渐受到嵌入式软件开发领域的关注。本文将深入探讨敏捷方法如何在嵌入式软件开发中落地生根，并分析其优势、挑战以及相应的解决方案。

敏捷开发的核心原则和实践

敏捷开发的核心是敏捷宣言中提出的四大价值观和十二项原则。其中，与嵌入式开发密切相关的实践包括：

迭代开发（Iteration）：敏捷开发以短周期（通常为几周或一个月）的迭代进行开发，每个迭代都产生一个可用的产品增量。Iteration 代表一个较大的迭代周期（例如一个月），而 Nanocycle 则代表更短的开发周期（例如每天的站立会议或更短的编码/测试周期）。这种分层迭代的方式有助于团队更好地规划和跟踪开发进度。

持续集成（Continuous Integration）：持续集成强调频繁地将代码集成到共享代码库中，并通过自动化构建和测试来尽早发现集成问题。在嵌入式环境中，可以使用虚拟硬件、模拟器或目标硬件进行持续集成测试。

测试驱动开发（TDD）：TDD 提倡先编写测试用例，再编写代码，从而确保代码的质量和可测试性。在嵌入式开发中，可以使用单元测试框架和硬件在环测试等方法进行 TDD。

Scrum/Kanban：Scrum 是一种流行的敏捷框架，通过定义角色、事件和工件（如 Product Backlog、Sprint Backlog 等）来规范开发过程。Kanban 则是一种更轻量级的敏捷方法，通过可视化工作流程和限制在制品数量来提高效率。Product Backlog、Release Backlog 和 Iteration Backlog 分别代表不同层级的需求列表，用于规划和跟踪项目进度。Iteration Workflow 展示了一个迭代周期内的工作流程，包括计划、开发、测试和回顾等环节。

每日例会（Daily Meeting）：每日例会是团队成员每天进行的简短会议，用于同步工作进展、发现问题和协调合作。

敏捷在嵌入式软件开发中的优势

更快的上市时间：通过迭代开发和持续集成，可以更快地交付可用的软件增量，缩短产品上市时间。

更高的质量：通过 TDD 和频繁的测试，可以及早发现和修复缺陷，提高产品质量。

更好的适应性：敏捷方法可以更好地应对需求变更，提高项目的灵活性和适应性。

更强的团队协作：敏捷方法强调团队合作和沟通，可以提高团队效率和士气。

敏捷在嵌入式软件开发中的挑战和解决方案

硬件依赖性：嵌入式开发通常需要与硬件紧密结合，这给敏捷开发带来了一些挑战。例如，硬件的可用性、调试工具的限制等。解决方案包括使用虚拟硬件、模型驱动开发和硬件在环测试等方法。

资源限制：嵌入式系统通常资源有限，这需要开发人员在设计和实现时进行权衡。解决方案包括优化代码、使用高效的算法和数据结构等。

安全性、可靠性和安全性要求：嵌入式系统通常对安全性、可靠性和安全性有很高的要求，这需要在敏捷开发过程中加以考虑。解决方案包括进行严格的测试、代码审查和安全分析等。

敏捷方法在嵌入式软件开发中的应用虽然面临一些特有的挑战，但也有不少成功的案例。由于很多公司对具体的项目信息保密，公开的详细案例相对较少。不过，我们可以通过一些公开的资料和案例片段来了解敏捷如何在嵌入式领域发挥作用。

以下是一些敏捷在嵌入式软件开发中的案例和应用场景：

1. 汽车电子系统开发

场景： 汽车电子系统，例如车载信息娱乐系统、高级驾驶辅助系统（ADAS）等，功能复杂、集成了大量的软硬件组件。传统开发周期长，难以快速响应市场需求和技术变化。

敏捷应用： 一些汽车制造商和供应商开始采用敏捷方法进行开发。他们将系统分解为小的功能模块，每个模块由一个独立的敏捷团队负责。通过短周期的迭代开发和持续集成，可以更快地交付新功能和改进现有功能。例如，一个团队负责开发导航模块，他们会通过迭代不断改进地图显示、路线规划等功能。

关键实践：

模型驱动开发（MDD）： 使用模型进行系统设计和仿真，减少对实际硬件的依赖。

硬件在环（HIL）测试： 将软件集成到硬件模拟器中进行测试，尽早发现软硬件集成问题。

持续集成和自动化测试： 建立自动化构建和测试流水线，提高集成和测试效率。

2. 医疗设备开发

场景： 医疗设备对软件的可靠性、安全性要求极高，传统开发模式强调严格的文档和流程，但可能导致开发周期过长。

敏捷应用： 一些医疗设备制造商在保证安全性的前提下，尝试采用敏捷方法。他们通过严格的测试和验证流程，确保每个迭代交付的软件增量都符合安全标准。例如，一个团队负责开发心率监测仪的固件，他们会通过迭代不断改进算法的准确性和稳定性。

关键实践：

严格的测试和验证： 强调单元测试、集成测试、系统测试和用户验收测试，确保软件质量。

代码审查和静态分析： 使用代码审查工具和静态分析工具，及早发现代码缺陷和安全漏洞。

合规性管理： 遵循医疗行业的法规和标准，例如 ISO 13485、IEC 62304 等。

3. 工业自动化控制系统开发

场景： 工业自动化控制系统通常需要与各种硬件设备进行集成，并且对实时性要求较高。

敏捷应用： 一些工业自动化公司采用敏捷方法来开发控制软件。他们通过模拟器和虚拟环境进行早期测试，并在实际硬件上进行最终验证。例如，一个团队负责开发机器人控制软件，他们会通过迭代不断改进机器人的运动控制算法和传感器数据处理。

关键实践：

实时操作系统（RTOS）： 使用 RTOS 来满足系统的实时性要求。

硬件接口和驱动开发： 针对不同的硬件设备开发相应的接口和驱动程序。

集成测试和系统测试： 将软件集成到实际硬件环境中进行测试，验证系统的功能和性能。

通用案例描述

小型团队快速迭代： 一个小型嵌入式团队需要快速开发一个新型传感器的数据采集和处理固件。他们采用 Scrum 框架，以两周为一个迭代周期。每个迭代都包含需求分析、设计、编码、测试和集成等环节。通过持续集成和自动化测试，他们能够快速发现和解决问题，并按时交付可用的固件版本。

应对需求变更： 一个嵌入式项目在开发过程中遇到了客户提出的新需求。如果采用传统的瀑布式开发模式，可能需要重新进行需求分析和设计，导致项目延期。而采用敏捷方法后，团队能够将新需求纳入到下一个迭代的开发计划中，并及时调整开发方向，从而更好地满足客户需求。

总结

以上案例和描述表明，敏捷方法可以在嵌入式软件开发中取得成功。关键在于根据具体的项目特点和约束条件，选择合适的敏捷实践和工具，并结合嵌入式开发的特点进行调整。例如，需要更加重视硬件集成和测试、安全性、可靠性和实时性等方面。

虽然公开的详细案例不多，但越来越多的公司开始尝试将敏捷方法应用到嵌入式软件开发中，并取得了积极的效果。随着相关技术和工具的不断发展，相信敏捷在嵌入式领域将会得到更广泛的应用。

结论

敏捷方法为嵌入式软件开发带来了新的思路和方法，可以有效地应对传统开发模式面临的挑战。虽然敏捷在嵌入式开发中面临一些独特的挑战，但通过采用合适的解决方案，可以充分发挥敏捷的优势，提高开发效率、产品质量和团队协作。随着嵌入式技术的不断发展，敏捷方法将在嵌入式软件开发领域发挥越来越重要的作用。

附：敏捷四大价值观和十二项原则

敏捷宣言（Agile Manifesto）是 2001 年由一群软件开发者共同发布的，旨在推动更有效、更灵活的软件开发方法。它包含四个核心价值观和十二项原则，这些价值观和原则共同构成了敏捷开发的基础。

四大价值观

敏捷宣言强调以下四组对比，并声明虽然右项也有其价值，但我们更重视左项的价值：

• 个体和互动 高于 流程和工具 （Individuals and interactions over processes and tools）

             这意味着，在敏捷开发中，人是最重要的因素。团队成员之间的有效沟通、协作和互动比僵化的流程和工具更为重要。

• 工作的软件 高于 详尽的文档 （Working software over comprehensive documentation）

             这意味着，最终交付可用的软件是首要目标。过度的文档编写可能会延缓开发进度，而敏捷开发更注重快速交付可用的软件版本。

• 客户合作 高于 合同谈判 （Customer collaboration over contract negotiation）

             这意味着，与客户的持续沟通和合作比严格的合同条款更为重要。敏捷开发鼓励开发团队与客户紧密合作，共同定义需求并及时调整开发方向。

• 响应变化 高于 遵循计划 （Responding to change over following a plan）

             这意味着，敏捷开发能够更好地应对需求变化。与其固守原有的计划，不如灵活地调整开发方向，以适应不断变化的市场和客户需求。

十二项原则

基于以上四个价值观，敏捷宣言提出了十二项原则，进一步阐述了敏捷开发的具体实践：

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 （Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.）

强调尽早并持续地交付有价值的软件，以满足客户的需求。

2.欢迎对需求进行变更，即使在开发后期。敏捷过程利用变化来为客户创造竞争优势。 （Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.）

强调拥抱变化，并将其视为机会，而不是障碍。

3.经常地交付可用的软件，从几星期到几个月，并倾向于更短的周期。 （Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.）

强调短周期的迭代开发，以便更快地交付可用的软件版本。

4.业务人员和开发人员必须在整个项目过程中每天一起工作。 （Business people and developers must work together daily throughout the project.）

强调业务人员和开发人员之间的紧密合作和沟通。

5.围绕被激励起来的个体构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 （Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.）

强调以人为本，给予团队成员充分的自主权和信任。

6.在团队内部，最有效的沟通方法是面对面的交谈。 （The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.）

强调面对面沟通的重要性，尤其是在团队内部。

7.可用的软件是衡量进度的主要标准。 （Working software is the primary measure of progress.）

强调以可用的软件作为衡量项目进度的主要标准，而不是其他指标。

8.敏捷过程提倡可持续的开发。赞助商、开发人员和用户应该能够无限期地保持恒定的步调。 （Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.）

强调可持续的开发节奏，避免过度加班和疲劳。

9.不断地关注技术卓越和优秀设计可以增强敏捷性。 （Continuous attention to technical excellence and good design enhances agility.）

强调技术卓越和优秀设计对于提高敏捷性的重要性。

10.简单——最大限度地减少工作量——是根本。 （Simplicity--the art of maximizing the amount of work not done--is essential.）

强调简洁性，避免不必要的工作。

11.最好的架构、需求和设计出自自组织团队。 （The best architectures, requirements, and designs emerge from self-organizing teams.）

强调自组织团队的重要性，鼓励团队成员自主管理和决策。

12.每隔一定时间，团队都要反思如何才能更有效，并相应地调整自己的行为。 （At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.）

强调持续改进，团队需要定期反思并调整自身的工作方式。

这些价值观和原则共同构成了敏捷开发的核心理念，指导着敏捷团队进行软件开发。理解并应用这些价值观和原则，可以帮助团队更好地应对变化、提高效率、交付高质量的软件。

三、汽车主机厂实现敏捷开发的15个赋能手段

在汽车智能化的大趋势下，“软件定义汽车”成为产业共识，软件及计算能力成为新时代下汽车的核心。整车厂希望推出有吸引力的软件集成汽车产品，来获得用户的持续认可。科尔尼认为，推进开发流程的敏捷度、提升组织的灵活度，将有助于传统车企面向软件为中心的转型。

01汽车智能化成为共识，软件能力将为主机厂间竞争关键点

随着E/E架构的不断迭代，传统的面向系统为导向的架构正在朝着面向服务为导向转化。这也就意味着，以前高度集成化的硬件和软件正在解耦，使得软件作为独立的中心化平台而运行。

在汽车智能化的大趋势下，“软件定义汽车”成为产业共识，软件及计算能力成为新时代下汽车的核心。软件将深度参与到汽车定义、开发、验证、销售、服务等过程中， 并不断改变和优化各个过程，实现体验持续优化、过程持续优化、价值持续创造。

需求决定软件架构，软件架构决定硬件架构，硬件架构决定整车架构。软件功能作为与用户连接的直接接口，逐渐与硬件一起作为产品力的衡量标准之一。因此，整车厂希望通过推出有吸引力的软件集成汽车产品，来获得用户的持续认可，这是其加强软件开发的根本目的。

下图列出了整车厂和主要高科技厂商在软件研发方面的支出。

在面向软件的组织方式下，参与者需适应不同于传统模式下的诸多变化——软件开发的周期大大缩短，架构从整体化向模块化转变，客户需求从长周期转向实时动态。为了实现对新功能的实时更新与部署，软件架构进行模块化分解，形成标准化、即插即用的组件，以适应软件产品的快速迭代，并达到节省开发成本、提高开发效率的目的。

与此相对应的，为了建立一个以软件为中心的汽车公司，在组织与流程、资源与能力、心态与文化方面都需要做出调整。科尔尼认为，推进开发流程的敏捷度、提升组织的灵活度，将有助于传统车企面向软件为中心的转型。

02敏捷开发优势凸显，愈发受到主机厂重视

目前应用V模型进行软件开发仍是主流

V模型是汽车主机厂对E/E架构平台型软件的开发模型，也是ASPICE(Automotive Software Process Improvement and Capability) 这一汽车行业广泛应用的软件开发体系的基石。

V模型将软件开发过程中的技术要求、需求分析、开发、以及测试环节以V形排布。从整体，到架构层，到系统层，到功能层进行需求分析，再开始开发，待开发工作完成后，又逐层向上从功能测试，到系统测试，到整车测试认证，以及系统集成工作。

通过应用该模型，汽车主机厂可以一步步深化拆解分析需求，在开发后，又能够自下而上的层层验证测试。该模型能够很好的满足车企对于大型复杂系统和软件的管理需求，因而得到了欧美系车企的大力推广和应用。

自A-SPICE于2005年发布以来，越来越多汽车主机厂不仅在自身的研发部门需要使用，甚至开始要求其Tier1一级供应商在进行软件交付时也要应用V模型并符合A-SPICE的标准。

敏捷开发模型由于其在软件快速迭代方面的优势，也越来越受到主机厂重视

随着中央计算架构的不断发展，以及终端功能性应用的日益增多，以及OTA的逐渐普及，主机厂也越来越多地需要快速迭代软件版本，以满足客户需求，同时在与其他车企竞争中能够保持领先一步。

而传统的V模型软件开发则太过复杂庞大，在应对灵活多变的客户需求时，显得冗长拖沓。举例来说，一个完整的V模型开发过程，通常需要12甚至18个月的时间，而软件更新在V模型下也需要3-6个月的时间，而这显然是无法满足客户需求的，因此主机厂开始引入敏捷开发（Agile）模式，希望能够在部分需要快速迭代的软件功能开发上，实现对消费者需求的快速满足。

敏捷模型则是一个闭环的开发流程模型，从规划，代码，编译打包，测试，发布，部署，到反馈，调整持续改进，并最终回到规划环节。

可以看出该模型的特点在于以客户为中心，持续获得反馈，持续改进；由于不像V模型那样每次都将收集获得的全部需求统一分析处理，而是分布式渐进式的逐步改进调整，因此其软件开发以及版本迭代的时间也被大幅缩减。

V模型和敏捷模型这两种开发体系，在适用软件特性，开发时间，灵活度，对客户需求的反应速度上存在差异（敏捷模型更多应用于智能驾驶舱、互联网等相关应用，而关于动力总成、电池等仍然需要依照V模型，其中具体功能可通过敏捷方式迭代）。

长期看两者会共存，也因此主机厂需要熟练掌握这两类开发体系。对于V模型，各个主机厂近年来已经有了较多的应用；对于敏捷模式，由于是从高科技行业引入，传统主机厂还需要进一步掌握该流程的使用，而具有互联网基因的新兴主机厂如Tesla，蔚小理等，则已经能够比较好的应用该模式进行开发工作。

03卓越敏捷开发的15个赋能手段

科尔尼根据敏捷开发模型的特点，分析了从开发测试到部署到改进优化的端到端流程，并提炼出了实现卓越开发的15个赋能手段，帮助主机厂更好地实现敏捷开发。

15个赋能手段可以根据主机厂对敏捷开发的应用熟练度分为三个阶段，分别是“敏捷软件开发能力建设”，“敏捷软件开发可规模化扩张”，以及“敏捷软件开发成为战略优势”。

其中第一个阶段是主机厂建设敏捷软件开发的重要阶段，本文将会围绕第一阶段“敏捷软件开发能力建设”下的重点举措做详细阐述和说明，分别包括：

②以功能为导向的敏捷开发；

③以功能为导向的软件设计与架构；

④关键人才赋能的软件开发；

⑦端到端测试与集成的自动化更新机制；

⑩已售出车辆的持续更新与集成流程。

②以功能为导向的敏捷开发

在代码阶段，要实现卓越，就需要一个以功能为导向的敏捷开发组织，其人员一般来自于传统的部门架构，由业务单元高层管理人员、工程与软件团队的核心人员、以及开发工程师组成，但其工作方式则以功能开发为导向。

在职能分工上，不再强调人员在企业内的上下级汇报关系，而是会设定一个核心领导负责项目规划、时间计划以及功能集成，其他人员则包括：系统经理负责项目预算及资源调配，测试工程师负责验证，软件硬件工程师负责软硬件需求分析、方案设计与集成，客户需求服务工程师负责分析客户需求及其解决方案规划，制造工程师负责在硬件制造方面的需求对接与系统集成。该团队在敏捷开发的规划阶段一起工作，然后将并行开展开发和集成与测试工作。

这样的工作方式可以最大化地实现以客户需求为导向，以产品为核心的开发，以及成本高效的持续迭代。

③以功能为导向的软件设计与架构

除了开发团队以外，要实现卓越，也需要在代码阶段考虑以功能为导向的软件设计与系统架构。中央计算架构在此则起到了重要的作用。现今虽然中央计算架构被各大车企反复提及，但真正得到实际量产应用的平台并不多，以特斯拉为例，其中央架构涵盖了目前与客户感受最相关的自动驾驶域、座舱娱乐域以及网络安全与车联网域。基由此设计，可以将软件需求拆解为上车软件以及后台软件，通过网关实现交互。

这样的中央平台架构可以实现通用的软件设计，并且能够应用一个软件版本去覆盖大多数在售车型。综上所述，有中央平台架构做基础，通过高成本性价比的架构，高通用性的软件，以及基于不同平台定制化的模块软件，能够帮助主机厂实现卓越的敏捷开发。

④关键人才赋能的软件开发

实现卓越也需要在人才层面进行储备、培养与赋能，并建立起与之匹配的人才机制。

在人才储备层面，需建立起完善的招募与培养机制来保证具有全局观或是具备某个模块专长的技术人员储备——包括整车系统层面、应用层面、车联网方向、移动端开发方向等；

在授权管控层面，创建扁平化的决策委员会机制，并充分考虑技术因素与决策的敏捷性。决策委员会成员以各BU主要负责人和技术领导人作为主导，其他各相关方辅助配合，保证决策会议有效记录，会议结果的输出是产品特征优先级排序；

在赋能机制层面，充分赋予每一位工程师参与产品建议的权力，充分调动每一位技术人员的积极性，以保证全员参与到产品提升的过程中。

这样的人才机制能够大大提高流程效率。通过将决策权交给真正有能力的工程师，能够最大限度地发挥人才潜力；通过扁平化和高效率的决策流程能够快速应对消费者反馈与市场变化。

⑦端到端测试与集成的自动化更新机制

持续集成和持续交付需要快速完成计划、编码、测试、发布的循环，自动化的测试和自动化的发布是不可或缺的组成部分。而这一过程应用于每一次提交，意味着每一次代码的提交、合并都会经过自动化的测试，成为一个新的发布版本。

以特斯拉为例，在硬件、系统与整车层面建立平行测试机制，依托Jenkins开源软件工具创建自动化的测试体系，在每一次软件版本更新迭代后自动触发。依次通过软件虚拟模拟、真实/虚拟外设环境下的硬件测试、真实外设环境下的系统测试、整车系统测试、真人道路测试环节，其中硬件、系统与整车层面的全部测试能够在20小时内完成，从而使得全部测试时间控制在24小时以内。

这样的自动化测试机制提供了一个全自动的中心化测试机制，使得全部测试与集成能够在24小时内完成，并且可以在无需更改已经通过验证的功能下完成自动化更新。

⑩已售出车辆的持续更新与集成流程

对于已售出车辆的持续更新与整合也是卓越开发的重要一环。根据软件开发的分支管理模型，分别按照软件开发、软件测试和已售管理三个典型分支进行（实际可能存在更多分支），并对应单一的数据存储库。

以特斯拉为例，对于开发分支而言，在软件构建阶段保证每周200次的更新，以及测试与集成阶段每周7次更新和15%的完成率；对于测试分支，在软件构建阶段保证每周30次的更新，以及测试与集成阶段每周14次更新和50%的完成率，以及在现场部署阶段每周0.5次更新；对于客户分支，在软件构建阶段保证每周20次的更新，以及测试与集成阶段每周10次更新和80%的完成率，以及在现场部署阶段每周3次更新。

这种已售车辆的更新与集成模型以模块化发布的方式进行，能够根据发布的准备成熟度来保证集成或是排除某一特定功能。并使得功能分支在单一的存储库中随时更新，尤其是对于已售车辆的客户端功能保持在~80%及以上部署完成的状态。

在实现第一阶段“敏捷软件开发能力建设”的要求后，软件开发能力的基础得到修复。

接下来的第二阶段将进一步实现软件开发能力的可规模化扩张，在基础能力建设完成后实现向软件业务的转型，此阶段的重点在于激活端到端的工程建设能力与标准化的流程体系。

进一步地，第三阶段旨在实现差异化的软件开发能力，使得敏捷软件开发成为具有竞争优势的战略路线，此阶段需要进一步地拓展OTA架构，升级数据收集与发布等。

后续阶段的升级与拓展都需要建立在第一阶段顺利完成地基础上，从而打好第一阶段的基础至关重要。

四、知识丨汽车软件开发中如何应用敏捷框架

1前言

为了确保汽车中安全攸关（safety critical）系统的安全性和可回溯性（Traceability），以及为了明确责任认定， 汽车软件行业如今普遍采用了ISO 26262和ASPICE等标准，作为软件开发的方法和流程。汽车行业的供应商们多数采用传统的“瀑布式流程”或“V型流程”来进行软件开发，并编制出大量的相关支持文档。这套流程不仅繁琐，而且越来越不适用于如今快速变化的市场需求。

而开发汽车控制软件毫无疑问是一个“系统工程”。像目前的“V型流程”定义的那样，先“冻结”需求，再让软件和测试团队以此开始他们的工作，这在工程实际中其实是一件很难实现的事情。因为客户需求经常是在不断变化的，并且软件团队对需求最初的理解也很可能有误。

事实上，在每个汽车软件项目中，软件团队都必须经过多次“循环迭代”，才能编制出一个合格的软件系统，而工程师们宝贵的时间和资源往往在这些较长的循环迭代中被浪费。为了应对日益挑战的市场，越来越多的软件团队如今倾向于使用敏捷框架进行软件开发，并以此来缩短软件迭代的时间、在保证软件安全性和完备性的前提下，更好地实现跨职能团队之间的协作。

然而，对大多数汽车供应商而言，敏捷开发流程目前往往仅被应用于产品研发的阶段，而不是量产的整个过程，因为敏捷开发流程仍被认为“不能满足安全攸关软件开发的全部要求”。随着通用汽车和沃尔沃等主机厂要求供应商们根据主机厂制定的敏捷流程里程碑（Agile Cadence milestones）来发布软件，敏捷框架也越来越受到重视。但是业界对如何在安全攸关系统的开发中应用敏捷框架基本上还是一头雾水。

那么，应用敏捷框架也能做到与ASPICE合规吗？应用敏捷框架还能继续遵循ISO26262标准吗？

虽然应用ASPICE流程也并不能一定保证产品质量，但每种优质的质量流程（无论是敏捷流程还是传统的V型开发流程）都应该符合ASPICE和ISO 26262的精神和原则。

与任何其他流程一样，敏捷流程只有在开发团队正确应用的的前提下才能高效地发挥作用。在汽车行业生搬硬套其他行业的所谓“敏捷”流程并不一定能成功。把敏捷开发流程应用到汽车行业，则必须根据汽车行业强调安全性和责任性的特点进行修改和剪裁。本文旨在探讨一种在符合ASPICE与ISO26262标准的前提下，将敏捷框架应用到汽车行业软件开发的方法。

2 汽车软件敏捷团队

和传统的敏捷团队一样，汽车软件敏捷开发团队也必须由“多功能团队”（cross-functional team）组成。另外， 如果项目团队由分布在全球各地的不同团队组成，那么这个项目也很难建立敏捷框架。

表1：汽车敏捷团队组成

表1给出了一个应用本文讨论的敏捷框架的汽车敏捷团队规模及其组成。团队成员必须能够对彼此的工作进行同行评议（peer review），以确保每项工作都经过了正确的审核和批准流程。

3 汽车软件敏捷团队成员

每个敏捷团队成员都必须以成为“全栈专家”（译者注：原文是Generalising Specialist）为目标。这意味着他们对所设计系统的各个方面（系统，软件，测试和安全）都有很好的认识，同时又在他们自己的领域有深刻而专业的理解。对于敏捷的汽车团队而言，这样的团队成员比纯粹的“专家”更有价值。建立这样一个团队成员当然需要时间，但具有“T型[1]”技能的敏捷团队可能会更成功。

（译者按：这一段其实我不太认同。作者把项目团队想得有些理想化了。实际情况往往是，如果一个团队成员被培养成了“全栈专家”，那么他所做的第一件事就是要么跳槽、要么谋求一个技术经理的职位，而不会甘心在团队里继续做一个开发工程师...因为我就是这么一个人哈哈）

4 汽车软件敏捷开发框架

本文讨论的是如何将敏捷开发应用于任何安全攸关汽车产品开发的典型CV（概念验证，Concept Validation）和DV（设计验证，Design Validation）阶段。在CV阶段，产品开发的重点是开发出一个可工作的系统，并产生“将降适当”数量的文档，以确保在产品开发过程进行了一定程度的“尽职调查”。然后，DV阶段应该将在CV阶段研发的软件进行重构，以符合相关的安全需求以及行业标准、法律法规。DV阶段的测试应偏向于证明系统的安全性，例如通过进行FIT（Fault Insertion Tests，故障注入测试）来证明软件系统不仅功能正确，还具有完备的诊断覆盖。

每个CV / DV阶段可分为三个不同的子阶段，以适应敏捷框架：

Pre-Sprint - 分析，计划和准备阶段

Sprint - 应用敏捷框架开发产品

Post Sprint - 回顾和总结阶段

图1：一个典型的应用敏捷框架的汽车软件CV阶段开发过程

图1展示了一个高度概括的汽车产品开发典型的CV阶段，同时还展示了在每个子阶段完成时所得到的输出产品。图一还对敏捷框架与传统的V型流程进行了比较，以确保在子阶段结束时软件符合ASPICE及IS026262的要求。

Pre-Sprint阶段

在此阶段，软件团队聚合在一起，讨论与编制软件开发所需的关键输入和先导事项。该阶段还将进行Sprint规划。这将有助于团队明确目标，并使所有团队成员有一个清晰而统一的项目计划和项目目标。

敏捷宣言指出，在开发团队内部传达信息最有效的方式是面对面讨论。Pre-Sprint阶段必切实进行充电的面对面讨论，以确保团队具有统一的CV目标、具体的交付日期、里程碑和并以此建立一个明确的计划展示板（Program Board）。

图2：Pre-Sprint 阶段

在CV期间，Pre-Sprint阶段一般持续4-6周，并在所有团队成员的参与下达成一个DIA（Development Interface Agreement, 开发接口协议），系统级需求和FSC / TSC（Functional Safety Concept 功能安全概念/ Technical Safety Concept 技术安全概念）。这些文档将作为锚点（anchor），指导敏捷团队完成整个CV sprint，并确保CV阶段具有明确的目标和任务规划。

对于DV阶段，Pre-Sprint需要稍长一些（8-12周）。DV阶段的Pre-Sprint需要在CV阶段产出的可工作系统上对需求进行细致而系统的分析，并进行HARA（Harzard Analysis，Risk Assessment）、软件FMEA，最终形成一个合格的Safety Case。

（译者注：Safety Case 我不太确定要如何翻译，它是指一个全部安全相关文档的总集，一旦编制成功就进入冻结模式，以作为后续软件开发的安全指导。如果将来产品发生安全责任事故，Safety Case也是划分责任的重要依据。）

在此阶段结束时，团队将创建清晰的DV backlog（待执行任务集？），以指导团队在Sprint阶段实现明确的产品安全目标。

Sprint 阶段：

Pre-sprint阶段为项目设立了明确的目标，而Sprint阶段则是汽车软件敏捷框架的核心。敏捷团队将以此编制软件需求文档和完整的软件并进行完备的测试。每个Sprint将持续4到6周。需要特别注意的是，在每个Sprint都应该迭代出一个新的、可工作或者说“可展示”的软件。如果一个项目阶段没有任何“可工作”的成果软件或者产品，则这个项目是绝对不适用敏捷开发框架的。比如说这个项目阶段的成果不能是DOORS 模块（译者注：DOORS是一个汽车行业通用的需求管理软件），也不能使Word 文档，而必须是"可工作"的：可以是一个可执行文件，或者是一个可运行的仿真程序。

图1和图4展示了软件Sprint阶段的工作过程。软件在每个Sprint中迭代开发，并随着Sprint的进行而逐渐完备成熟。这种开发流程的一个明显优势是将软件需求文档的编写与软件编制实现结合在了一起。如果某些软件设计不正确，那么相应的需求文档将被重新编写，软件进行重构并快速集成这个新的变更，并且很快就能得到测试的反馈。在某种程度上而言，每个Sprint代表了一个迷你的V型循环。因此，根据定义，当每个Sprint完成时，团队产出一个可工作的软件，以及和该软件内容匹配的需求文档及测试用例文档。这使得整个软件开发过程变得非常灵活，随时可以应对来自各方得任何新要求。当面对新需求时，团队所需要做的就是对其进行评估并，引入到下一个Sprint中即可。

图3. Sprint 阶段

对于CV阶段的Sprint，团队的目标是在所有Sprint完成时拥有一个可工作的软件，并且其相关文档全部完整。也许该系统仍不能应用于公共道路，但是它必须拥有足够的安全机制来满足在封闭的测试场中使用（这也是为什么在CV阶段一定要建立FSC和TSC）。

对于DV 阶段的Sprint，团队的目标是在Sprint结束时对CV阶段的软件进行了基于安全需求分析的重构，并完成了全部诊断功能的编制。这个软件必须经过了充分的测试以验证所有功能和安全性。最终DV阶段产出的软件需要能够在公共道路上使用。

图4：应用敏捷框架的汽车软件DV阶段开发过程

Post-Sprint 阶段

另外，Post-Sprint阶段的另一个重要任务是完善从需求文档到测试文档的可回溯性文档，以便在阶段结束时实现对ASPICE过程的合规。

5写在最后

通过本文的讨论，在汽车软件开发中应用敏捷框架也可以高度满足ASPICE和ISO26262的要求。与传统的“瀑布式”或“V型”流程相比，这种方法更适合当前快速变化的汽车市场。在CV 过程中同步编写需求文档和软件并进行迭代测试，将显著减少传统开发流程中的“长循环”所浪费的时间。在DV 过程中对软件进行基于安全分析的重构，保证了软件的安全性，可以完全符合ASPICE和ISO26262的要求。

最后，业界多年来在如何开发安全的汽车系统方面产生了大量的经验教训。如果没有真正将适合汽车行业特点的敏捷框架建立起来，就贸然投身这股“敏捷”的潮流，只会编制出缺乏安全性和完备性的软件系统，并且让公众失去对汽车行业来之不易的信任。我希望这篇文章能够证明在汽车软件开发中应用敏捷框架是可行的，并且应用敏捷框架所带来的收益，将远远超过转变到敏捷框架的过程中所带来的损失。

五、汽车电控软件开发流程的最佳答案：融合ASPICE+敏捷的软件开发流程（二）

一、ASPICE软件开发流程

ASPICE的优势

• 提升软件质量。

• 提升产品的竞争力。

• 实现供应商统一的开发流程，让沟通更顺畅。

• 它为嵌入式汽车软件和系统部件的质量保证提供了最佳实践和流程。

• 标准提供了不断改进实施的过程，能够让供应商及软件团队开发出的软件质量越来越好。

ASPICE的劣势

• 标准流程复杂，交付周期长。

• 设计变更时，需要针对大部分的流程进行输出产物变更，耗费大量的人力物力。

• 不符合当前的汽车行业形势，针对当前的需求进行开发，需要2-3年才能交付软件，当随着时间推移，产品的竞争力将大幅下降。工作思路：需求-开发-测试-开发-测试-开发-测试-发布。

• 软件开发过程类似于V方法，按照特定的步骤进行开发后，才能进行下一步开发工作，明确了下一步应执行活动和交付工作产品的特定顺序。

二、敏捷开发(Scrum)的开发流程

敏捷开发的优势

在当前汽车以客户为中心的理念下，敏捷方法论或其要素在汽车项目中非常有效，通过短时间的工作，可以对客户需求进行测试，然后根据用户反馈进行调整。工作思路：需求-开发-测试-发布-需求-开发-测试-发布。

敏捷软件开发遵循增量方法，并在完成初始规划后提供进行更改的灵活性。

敏捷开发的劣势

如果开发的项目是全新的项目，直接进行敏捷开发，将文档、输出物的地位进行弱化，随着人员的流动，将对于产品的售后和后期的变更将是重大的灾难。

三、ASPICE及敏捷开发的流程融合：

ASPICE则注重提高软件开发过程的质量和效率，以确保软件产品符合要求。敏捷开发注重快速响应需求变化和高度灵活性，而将敏捷和ASPICE相结合，可以兼顾快速开发和高质量软件的需求，同时降低软件开发成本，具体方法如下：

确定需求并持续迭代：在敏捷开发中，需求是通过持续迭代来发现和实现的。在ASPICE中，需求开发及管理是其过程中的一个关键环节。因此，将敏捷和ASPICE相结合，可以通过敏捷的迭代方式来确定需求，并通过ASPICE的需求管理来确保需求的准确性和完整性，从而提高软件开发的质量和效率。

集成测试和自动化测试：在敏捷开发中，集成测试和自动化测试是非常重要的，可以帮助团队快速发现和修复问题。在ASPICE中，测试是软件开发过程中的关键环节，它可以帮助确保软件产品的质量。因此，将敏捷和ASPICE相结合，可以通过集成测试和自动化测试来提高软件开发效率，同时通过ASPICE的测试要求来确保测试的覆盖率和准确性。

持续改进和过程改进：敏捷开发注重持续改进，通过持续反馈和迭代来不断提高软件产品的质量和效率。ASPICE也注重持续改进，通过评估和改进软件开发过程来提高软件开发能力和质量。因此，将敏捷和ASPICE相结合，可以通过持续反馈和评估来进行过程改进，从而不断提高软件开发的效率和质量。

方案一：对于全新的项目采用ASPICE的开发模式，对于成熟的项目进行设计变更可以采用敏捷开发的模式，进行快速的测试验证，对客户需求进行开发，然后根据用户的反馈决定是否设计变更，如果执行，再按照ASPICE的流程执行活动和交付工作产物。

方案二：百度将敏捷开发的模型做了一次彻底的拆解。百度王博表示：“当我们将敏捷开发里边的一个‘迭代’拆开之后，会发现其实它在一定程度上是可以通过V模型来承载的。这个时候，我们再将ASPICE®进行一定的改造，就可以‘装进’敏捷的每一个‘迭代’中，从而使我们的每一个‘迭代’符合ASPICE要求。”

ASPICE解决的做什么的问题，是传统OEM对于Tier的要求，敏捷开发解决的是怎么做的问题，是Tier对自己自身的要求。也就是说，ASPICE是一个要求，OEM要求Tier做什么。敏捷是说，Tier怎么来快速地完成这个任务。图中Sprint的意思是 被执行的需求，一次迭代的需求。Sprint Backlog的意思是 被选中的需求，任务清单。Product Backlog的意思是 原始需求，概要文档。