ASPICE项目实施落地大局观（上）
摘要：ASPICE是汽车行业用于评价软件开发团队研发能力水平的模型框架，目的是为了指导汽车零部件研发的软件开发流程，从而改善车载软件的质量。本文基于作者多年的ASPICE项目实施经验，有感而发，试图从多个维度与各位探讨成功实施ASPICE项目所需要注意的一些方面。
▍ 导言
Automotive SPICE是从ISO体系独立出来，由德国汽车工业联合会（VDA）的质量管理中心（QMC）运营发展的汽车行业软件开发团队研发过程标准。当前最新版本是2017年底发布的3.1版本，有中文翻译版。
在ASPICE这个生态中，除了标准的制定方外，另外几个重要的参与方包括支撑ASPICE落地的工具（平台）提供商、提供ASPICE体系咨询的咨询公司、以及客户。本文是从平台提供商的视角，侧重描述ASPICE项目如何实施落地，当然也包含了对于客户的一些建议，以帮助那些想启动ASPICE项目的客户做出理性决策。
这里的实施落地不是指仅仅满足ASPICE标准的要求，通过ASPICE评估，而是要让整个团队从思想上理解ASPICE标准，在实践上真正提高研发管理水平，而后者才是ASPICE实施时的一大难点，也是我们致力追求的。
与互联网行业的研发不同，汽车行业的软件研发有其自身的特点，为此，我们需要建立与这一特点相适应的研发体系。这一研发体系需要考虑的方方面面较多，在本序列文章中，谨探讨其中的三个最为重要的方面：
-
搭建融合创新、满足ASPICE标准的研发流程体系；
-
工具链整合
-
基于平台的复用
▍ 凡事预则立，不预则废
ASPICE标准是一个大块头，凡是想要实施ASPICE的企业或者研发团队，不可抱有“突击作战”的念头，期望在短时间内达到ASPCE标准所提的要求。我相信没有人能逃过“熵增定律”，突击方式无法持久，因此，我们首先要建立相应的组织机构来负责体系的持续建设。
这一组织机构可以是一个联合体，至少应该包含三个方面的职能：过程改进小组，负责持续的过程改进体系建设；IT；以及KBU（关键业务用户）。在有些企业，它的过程改进小组可能是由各个部门的人员抽调而成，有些规模大一些企业的过程改进小组可能是一个独立的部门，当然这样对于ASPICE建设工作的开展是最好的。对于规模小一些的企业，其过程改进和IT的职能可能都被弱化，一人身兼多职，但我们仍然需要有这样的意识，要意识到在做某个事情的时候，是以什么样的角色在做；在规划工作开展的时候，要考虑到这三个方面应该做到的一些事情。例如，作为过程改进角色，要持续建立企业的过程资产，并要思考过程资产的标准化，即使只有一个项目在实施ASPICE的时候，也要未雨绸缪，要考虑到这一方面，这样在将来从ASPICE二级往三级过渡的时候，能更平滑一些；作为IT角色，要考虑数据如何备份，要经常进行防灾演练，要从IT规划的角度，考虑ALM平台与企业其他平台的整合；作为KBU，要考虑自身团队的现状和水平，考虑适宜的导入路径，并进行时刻检视，动态调整策略。
在这个联合体中，需要找出一个牵头的部门。具体选择哪个部门作为牵头部门，各个企业各有不同，由此带来的实施效果或可持续性也会各有不同。
ASPICE实施是一把手工程，有了领导的支持与授权，项目实施在遇到阻力时，才能更好的克服困难，走出困境，继续前进。
实施团队确立后，下一步就是要选择实施的范围。ASPICE涵盖32个过程域，但一般来说，大家普遍选择的是VDA Scope：
图：上图中的数字表示VDA Scope所属的过程域
由于过程域众多，因此实施团队中就需要有各个专业领域的工程师，同时，由于各个过程域之间存在内在的衔接与逻辑关系，还需要至少有一个能统领全局的“帅才”，这也是ASPICE实施的另一个难点，因为就业市场能找到的更多是专才。
在实施落地时，实施团队除了要有职业精神外，还需要有“布道”的心态。要像传教士一样，传播ASPICE的知识与理念，要到一线去，看到一线工程师的工作现状，发现他们的痛点，找出切实可行的办法，从而获得一线工程师的拥护。在有些开展了“导师”制或“师徒制”的企业，要让导师或师傅们先获得ASPICE知识，从而可以融入到日常的传帮带中。
由于ASPICE标准工作在“What”层面，并不涉及“How”。因此，企业在实施落地时，切忌拿来主义，千人一面，而应该是根据自身研发团队的规模、所研发产品的特点等，制定自己的“How”。这一点对于ASPICE实施的成败是非常关键的。
▍ ASPICE体系建设的融合创新
ASPICE是V模型开发流程，从某种意义来说，是“变形”的瀑布流程。实践中，如果我们一板一眼的按照ASPICE流程来开展我们的研发工作，会难以避免出现“窝工”的现象，严重影响研发效率。特别是现在大量开展的自动驾驶、车联网等项目，大家都在摸索，需求不可能冻结，再加上市场竞争激烈，需要尽早发布，以获得市场先机。为了应对这一挑战，我们就有必要在遵循ASPICE标准的同时，引入能帮助我们更好响应变化的敏捷方法论。
汽车行业软件开发中另一个重要的标准就是功能安全。对于涉及到功能安全的产品的研发，研发团队既要遵循ASPICE，也要满足功能安全的要求。这就要求我们在研发管理平台建设上要充分考虑二者的融合，使得工程师们一件事情只需要做一遍，就能同时满足这两个标准的要求。
▎ 敏捷，还是敏捷
由于汽车行业的特点以及ASPICE标准的要求，在引入敏捷开发方法论时，我们需要做一些调整。
ASPICE要求我们必须进行逐级验证，才能实现最终的对外发布。这包括软件的单元测试、软件集成测试、软件合格性测试、系统集成测试、以及系统合格性测试，这些工作很明显是无法在较短的Sprint周期内完成的。因此，我们需要使用敏捷开发中的DoD，明确Sprint中的发布成熟度等级，有的Sprint，只需要做到编译通过即可，有的则要求执行完整的HiL测试，有的还要求相关负责人执行严格的签署程序。另外，我们要充分地利用工程效率技术，实现与各种自动化测试工具的集成。
在DoD中还要明确要交付的文档。ASPICE要求交付的文档列表（工作产品）比较多，这些文档的延迟交付也会使迭代失败。我们一方面要尽可能通过自动化的方式来在过程中自动生成文档，另一方面也可以考虑将文档分解到整个产品开发阶段的不同迭代中完成。在Polarion官方研发团队的敏捷实践中，也是有这样的Sprint，用来完善产品最终对外发布前的文档工作（请参考“Polarion Goes Scrum”白皮书）。
FusionXfor ASPICE是Teamlive基于西门子Polarion ALM平台研发的汽车行业解决方案。FusionX代表“融合创新、加速实现价值”的含义。在FusionX for ASPICE解决方案中，敏捷/精益方法论与ASPICE实现了“无缝”的融合。
图：FusionX for ASPICE解决方案
在解决方案的实施上，为了配合客户项目的研发节奏，帮助客户尽早实现投资回报，Teamlive通过FusionX for ASPICE解决方案以及敏捷实施模式，极大压缩了项目上线所需的时间，极大压缩了整体实施所需周期与成本。
图：敏捷实施模式
▎ 与功能安全融合
功能安全与ASPICE类似，有着非常对称的过程体系结构。我们完全可以通过解读这两个标准，形成合并后的组织级的标准开发流程。如下图所示：
图：融合ISO26262和ASPICE，形成企业开发流程
限于篇幅，在这里就不再展开，留到以后有机会再另起文章描述。
▎ 内嵌交互式指引，提升ASPICE解决方案采纳成功率
在平台的建设过程中，虽然我们编写了使用手册，进行了培训，上线后还会提供一段时间的技术支持，然而，实践中还是会遇到一些问题：
-
手册太长了，用户不愿意看；
-
平台的功能、业务规则等在持续演进，手册很快就过时了，存在维护不及时，或根本没人维护的窘境；
-
培训参与度不够，或在高强度、“填鸭式”的培训方式下，能吸收的知识极其有限，等到要使用的时候，已经忘得差不多了；
-
新人入职、人员换岗等都需要及时给予培训；
-
工作繁忙，希望在遇到操作问题时，能得到及时的帮助，而不是需要等较长时间
-
异地分布式研发团队的支持问题
-
…
基于上述原因，我们在FusionX for ASPICE解决方案中创新性的引入了内嵌交互式指引Newired Journey，她为使用者提供了内置的、实时的培训与使用支持，可激发用户的积极性，极大节省组织的推广成本，从而强化与确保ASPICE解决方案的落地。
Journey不仅从操作层面解决了如何使用FusionX for ASPICE的问题，也从理论（Why）层面对操作背后的设计理念进行了解释，帮助用户知其然，也知其所以然。
Newired - Demo on ALM - Polarion
http://www.teamlive.com.cn/products/newired/index.html
▍ 回顾与下一步
这是本序列文章的第一篇：“搭建融合创新、满足ASPICE标准的研发流程体系”。这里的融合创新，既有方法论的融合（融合敏捷与精益），也有标准的融合（融合ISO26262），还有创新技术的融合（融合Newired Journey，以及LiveExcel、LiveCalendar等技术）。限于篇幅，这三个方面的融合找机会再展开。
请关注后续文章《ASPICE实施落地大局观（中）》。
请关注8月6日Teamlive将要举办的FusionX for ASPICE行业解决方案发布会。
微信扫一扫
关注该公众号