作者：汪阳｜QE_LAB

导言

很多人说 Agile 与 ASPICE 是天然冲突的，就像水和油一样，很难融合。

(图片来源：https://knuevenermackert.com/wp-content/uploads/2021/09/Project-Manager-vs-Safety-Manager.jpg)特别是对经历过很多敏捷项目的, 或者是互联网领域进入到汽车研发领域的同学，非常抗拒重流程， 重文档的 ASPICE。

正好趁着 ASPICE 4.0 的发布和项目刚刚在 23 年年底通过了 ASPICE CL1 的评估。我想谈一谈自己对于 ASPICE 实施的一点点感悟。

(图片来源：https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf)

ASPICE 是什么？

ASPICE 全称是 Automotive - Software Process Improvement and Capability Determination. 汽车行业软件过程改进和能力评定模型，由德国汽车工业联合会（VDA）开发的，现在已成为全球汽车行业的事实标准。包含两部分，一部分是过程改进的参考模型 PRM （Process Reference Model），另一部分是过程能力评估模型 PAM (Process Assessment Model)。2023 年 11 月， ASPICE 版本已经更新到了 4.0。

ASPICE 标准并不是全新的东西，简单来说它是汽车行业基于 CMMI，需求工程，系统工程等行业实践经验和方法论为基础，并结合了汽车电子软件严格的质量与安全要求，形成的共识和基础实践，它定义了期望应该做到什么，至于如何做到，并没有限制。

(图片来源：https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf)这里就不介绍 ASPICE 标准具体的内容，如果大家感兴趣可以直接阅读官方 100 多页的标准文档。

为什么需要 ASPICE？

ASPICE 标准在汽车行业全面应用也是在近十年，这十年也是汽车电子电气架构与汽车软件飞速发展的十年。汽车行业也面临了日益严峻的挑战：

软件复杂度指数级增加：

随着软件定义汽车（Software Defined Vehicle）时代的到来，汽车行业从机械化，电动化，走向了智能化，网联化，汽车行业面临百年未有之大变革，预计到 2025 年，软件在整车价值中的占比将超过 50%，自动驾驶系统与智能座舱成为汽车最为核心的竞争力之一。

与此同时，汽车软件的代码总量也快速超过了 1 亿行，而一架波音 787 客机软件系统的代码总量也不过 650 万行。更有汽车业内人士预测，一辆 L5 级别全自动驾驶车辆的软件代码将升至 10 亿行。

软件复杂庞大的代码量可能引入更多的缺陷；复杂场景组合与庞大代码量使得测试验证的充分性难以保证，在过去的一年汽车召回的统计中，因软件召回的车辆数量占比约 50%，说明软件是企业最容易出现问题的地方，从而更能凸显出软件质量的重要性。

(图片来源：https://informationisbeautiful.net/visualizations/million-lines-of-code/)

大规模软件团队协作：

汽车研发制造涉及全球供应链，这使得汽车制造商需要一套通用的方法来确保所有供应商提供的软件都满足相同的质量标准，以保证整车的质量和安全性。

现在汽车电子软件的分工，和以前有明显的区别， 以往都是 Tier-1 负责零部件的软硬件整体交付， 软件作为黑盒提供给主机厂，主机厂只负责需求定义与需求验收。 而如今，主机厂自研能力也在不断增强，同时在智能座舱和自动驾驶等系统上， 主机厂和 Tier-1 共同研发的模式也越来越普遍。动辄数百上千人的项目研发团队规模，主机厂如何与众多的软件供应商高效协作开发，并且保持一致性，也是一个巨大的挑战。

日趋严苛的标准与法规要求：

尽管汽车越来越智能化，但是汽车不是电子消费品，关乎生命安全，因此各国对于汽车软件的安全与可靠性要求非常严格。如国际标准的 ISO 26262 功能安全要求，ISO/SAE 21434 网络与信息安全要求，以及欧盟的 RN155/156 和一系列对应的国标要求等。

这些标准虽然发布也有一段时间， 但是如何将复杂的标准要求融合到汽车软件研发流程和活动中，仍然是各大车企面临的挑战之一。

因此，对于大型复杂系统软件开发，大规模分布式团队协作，以及日益严苛的监管要求， 如果不统一标准，对齐认知，是很难进行有效管控的 (效率与质量)。在这样的背景下，ASPICE 应运而生。

ASPICE 如何融入敏捷研发流程？

敏捷不是具体方法论，更不是教条主义。Be Agile not Do Agile.汽车软件开发选择敏捷开发模式也是基于业务特点决定的（如下图所示）。

而 ASPICE 仍然是当下汽车行业软件工程发展阶段，相对成熟的一套模型和标准。但是未来是否随着生成式 AI 的不断发展和成熟，软件工程范式发生变革后，会出现新的开发模式，我们也可以期待。

回答上面的问题， ASPICE 和 Agile 并不是本质冲突的，他们并不是一个层面。ASPICE 主要是从 WHAT 层面，要求你必须有那些内容。至于你如何达成，也就是 HOW 的部分，并没有强制要求。并不是说 ASPICE 就只能用瀑布式开发。

那么在当下，我们如何既能敏捷开发，又能满足 ASPICE 合规性的要求呢？

比较好的方式就是将 ASPICE V 模型融入到每一个敏捷迭代中。

由于汽车行业的独特性和 ASPICE 标准的要求，当引入敏捷开发方法时，我们必须进行一些适应性调整。结合具体的实践，我们完全可以基于 SAFe + Scrum 的规模化敏捷开发方式，并且在每个迭代中完成 ASPICE 要求的对应内容，将 ASPICE V 模型装进每一个 Sprint 迭代中；并且将 ASPICE 要求的计划与监控调整，与 SAFe 的 PI Planning, Sprint Planning, Retro 等活动结合起来。

(图片来源：https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf)ASPICE 标准要求我们逐级验证，以实现最终的对外发布。这包括软件单元验证、软件集成测试、软件合格性测试、系统集成测试和系统合格性测试。很明显，这些任务不可能在较短的 Sprint 周期内完成。因此，我们需要根据敏捷开发中的 DoD 明确每个 Sprint 中的发布准备程度。同时对于 ASPICE 要求的一些文档类和评审类工作，我们可以拆解到产品开发阶段不同的迭代中完成。

实施过程中的挑战与应对

大部分项目都会面临： 时间紧，任务重，资源紧缺等问题。相信我，如果一个项目这三个问题都不存在，那么这个项目一定会失败。

实施 ASPICE，我们也面临了一些挑战：

1. 人员认知上的问题

2. 粒度把控问题

3. 交付与质量的权衡

4. 缺乏工具链的支撑

尽管存在这些挑战，但实施 ASPICE 可以为汽车行业的组织带来重大利益，包括提高软件产品的质量和可靠性、提高客户满意度以及降低返工和缺陷相关的成本。

人员认知上的问题：

人员认知的问题包含两方面，一个是开发团队对于实施 ASPICE 价值的认知。另一个是管理层对于 ASPICE 能带来什么价值的认知。

如果开发人员没有意识到 ASPICE 要求的价值，缺乏主观能动性（Motivation），只是机械式的完成任务，是很难交付出高质量的工作产品的。

同样，如果管理层对于 ASPICE 实施的价值与成本投入缺乏必要的了解，没有给予充分的支持，也会让开发团队陷入资源紧缺等问题。

应对策略：

1. 定期培训与 workshop 工作坊：定期组织流程策略相关的培训，包括团队最佳实践的分享，从理论（Why）层面对操作背后的设计理念进行了解释，帮助团队知其然，也知其所以然。特别是关键角色，如管理层，Tech Lead，PM 等。

2. 将流程要求固化到工具链：如在 Jira 上的 review workflow 设计，内嵌 checklist 等。以及在 Gitlab 上设置质量门禁，Peer Review 的角色等。将标准要求做到工具中，达到统一性。

3. 以检代训：仅仅靠培训，很难让一线开发完全理解 ASPICE 的要求，只有在工作产品与流程检查中，对相应的开发进行持续的理念灌输，才能让他们逐步建立意识。

4. 换位思考：ASPICE 实施团队不能只提要求，要到一线去，看到一线工程师的工作现状，发现他们实施过程中的痛点，找出切实可行的办法，从而获得一线工程师的拥护。

通过上面几种方式，持续赋能，帮助组织提升对 ASPICE 实施价值的认知与意识。

粒度把控问题：

ASPICE 对架构设计的要求非常全面，但是在敏捷开发过程中，变化是常态。如需求变化，会导致架构设计，详细设计，代码，用例都有可能发生变化，如果我们的粒度太细，那么变更的成本也是团队难以承受的， 事无巨细的设计对开发团队的工作量也是巨大的。但是粒度太粗的话，也无法指导设计与实现，更没法保证质量。如何把控实施的粒度，对团队来说也是一个挑战。

应对策略：取得平衡点很重要；抓主要，放次要；分层设计与增量式设计。将设计分解为合适的层次。高层次的架构设计可能是静态图，为整体架构提供方向；中层次的设计可能包括模块或组件设计，提供更具体的指导；低层次的设计可能是代码级别的设计，指导具体的实现。

进行持续架构设计，如在 High-Level 层面，仅仅设计关键的部分，构建灵活且可变的架构。采用模块化、可扩展的设计模式，使架构能够更好地适应需求变更，减少对整体架构的影响。

而详细设计部分可以融合进具体的迭代中，进行增量设计。在敏捷环境下，详细设计与实现，有时候并不完全是先后关系，而是一种相互交织的，螺旋式关系。

同时简化设计文档的格式化要求，可以采用 markdown 结合 plantuml 的方式来编写架构设计文档，不限制必须是 word 格式。

交付与质量的权衡：

我们总能听到开发团队的抱怨：如果满足的质量要求，就无法满足交付要求。这个问题本质在于前期欠下了太多的技术债， 第二个就是团队整体质量能力欠缺。

应对策略：我们必须客观地认清现状，质量能力的提升很难在短期内一步到位。通过实践证实，建立质量增量（Quality Increment）活动是一个有效的方式，将债务分解到每个迭代中，分而治之，它能够帮助团队逐步提升质量能力并且持续改善工作产品的质量。

缺乏工具链的支撑：

当谈到软件基础设施建设时，有一句俗语是非常贴切的：要想富，先修路。在现代软件开发中，软件基础设施的建设至关重要。缺乏良好的工具链支持将使得满足 ASPICE 要求中的追溯性和一致性变得异常困难，难以高效实施。因此，构建一个符合 ASPICE 要求的工具链体系，成为团队必须优先考虑的问题。

应对策略：尽管从 ASPICE 规范的角度来看，这个问题的答案是非常清晰的：ASPICE 关注的是需求的本质，而非实现方式。因此，并没有对特定工具有普适性的要求。然而，在 ASPICE 中，确实存在一些需要依赖工具才能实现或者更容易实现的要求。其中最显著的是，这些工具能够有效帮助实现对可追溯性和一致性这两个方面的要求，这在 ASPICE 中是普遍而重要的。

有没有一套工具链或者是平台能够百分百支持 ASPICE 所有要求呢？

答案是没有的。

我们能做的就是因地制宜，充分利用工具链的特性，来满足 ASPICE 要求。如在 Jira 上通过 Jira 插件 R4J 帮助建立需求基线。在 Jira 上建立不同层级需求之间，以及需求与测试用例之间，测试用例与测试结果之间的双向追溯性等等。

过程与质量改进实践

限于篇幅原因，在这里我想重点讲一下我们在需求与架构设计上面的一些质量改进实践。

需求质量差：

从很多经验看下来，一个做得烂的项目基本都有一套混乱的需求。当想要治理项目时，几乎都应该从需求开始。因此我们从需求信息模型设计，需求语法结构统一以及需求准入准出标准定义等几个方面进行需求质量的改善。

需求信息模型设计

需求的层级和需求的管理，是属于需求工程的范畴。特别是对于汽车电子系统开发，需求来源多样，有客户的要求，有标准法规的要求，也有质量安全，或企业内部相关的要求。同时涉及到软件，硬件，机械等各个部分。

因此定义清晰的需求信息模型对于各方对齐需求，和拆解需求尤为重要。

很多人会说，按照奥卡姆剃刀原则，如无必要，勿增实体。这么多实体带来的理解成本是否太高了。直接 Feature -> User Story -> Task 三层结构不就可以了？

具体的原因比较复杂，主要是汽车行业历史背景导致的，汽车软件开发虽然朝着软硬解耦的方式发展。但是目前还不能完全独立，软件发布的里程碑还是和整车硬件，机械开发的样件节奏保持一致性。

所以对于需求工程师来说，有一个清晰的 FROP （Function Rollout Plan），能够很容易了解需求的释放计划和完成度；同时有一份完整的 SwRS 需求文档，也能够帮助各方更全面了解需求的背景与上下文。

需求语法结构

一个 PO 或许可以按照自己熟悉的风格编写软件需求，但是对于复杂的汽车软件项目，几十个 PO ，如果不约定需求语法结构，各种风格的需求传递与沟通必然会存在不清晰，不一致的地方。

需求的准入与准出标准

我们以软件需求为例。首先定义需求就绪的标准：Definition of Ready (DoR)Example:

1. 需求描述符合模板要求

2. 需求建立了与上游需求和系统架构的追溯性

3. 需求有对应的验证准则

4. 需求描述符合相关特征，如完整性，可理解性，可测性，可行性等

5. 进行了需求影响分析

6. …

其次定义需求的完成标准： Definition of Done (DoD)Example:

1. 需求完成了相关方评审

2. 需求完成了基线

3. 需求已经集成到对应的版本

4. 需求完成了合格性测试，并测试通过

5. …

只有统一需求标准，拥有“共同语言”，形成认知上的共识，才能更好地进行跨团队协作与沟通，降低信息传递的损耗。

设计不一致：

对于一个复杂的汽车电子软件系统开发，做好架构设计是非常重要的一件工作。

我们开发团队人员有来自不同的主机厂，Tier-1，互联网等行业背景，对于架构设计要求，架构元素的认知也有较大的差异。因此在项目中统一架构元素定义，架构设计要求。是架构设计的前提条件。

架构元素定义

合理定义架构元素的概念。在 ASPICE 中架构元素描述的是抽象概念（如下图所示），那么如何与项目和组织中的技术维度层面对齐，是需要进行充分设计与映射的。

(图片来源：https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf)

ASPICE 的定义过于抽象，Element，Component, Unit 等。而业界实践中多以 Layer, Group, Module, Sub-Module 等划分架构层次。

如上图所示，架构元素拆分的越细致，后续集成的层次就越多，对于集成测试的要求也越全面。

持续评审与反馈机制

架构设计文档不是写给自己看的。建立持续的设计评审机制, 在团队中引入设计评审会议或工作流程，以确保设计方案得到适当的反馈和修正。这有助于避免过度设计，同时提供质量保证。如在架构设计过程中的 ADR 架构决策记录, 周期性的 TAB 架构评估会议等。

总结

除了需求与架构设计上的改进，我们 ASPICE 实施涉及到了整个软件研发过程的优化，包括代码质量，验证与自动化测试，质量保障以及组织协作方面的流程与实践改进，后续会专题分享相关的话题。

总的来说，实施 ASPICE 最关键的三大因素：

1. 人员认知与 Motivation

2. 管理层的支持

3. 工具链的支撑

没有一套方法论是能够解决系统性问题的。只有把标准，流程，方法与实践融入到团队日常研发活动和工程师文化，以及工程师做事的原则和行为方式中，形成组织的 Way of Working , 才能真正的做到实践不退化，以及持续改进。