 
 4、质量驱动，迭代改进——质量驱动架构 软件定义汽车，质量驱动架构！ 在汽车中软件占比不断提升的今天，“软件定义汽车”早已成为共识，那么用什么来保证软件质量？行业或制定新的标准如针对网络安全的ISO21434、或IATF16949，对软件质量在特定领域提出了更严格、更具体的管控要求。 那诸多针对特定领域的行业标准如何融合落地？ ASPICE就成了兵家必争之地：功能安全需要它的追溯、信息安全需要它的设计、IATF16949需要它的体系，虽然实际落地考虑成本都有各自的算盘，但各家在口头上对ASPICE实施这件事上就没有谁会直截了当的说“不”。 ASPICE如此厚重如何在快速迭代的短周期开发中落地？ 毕竟ASPICE在流程层面只提到了做什么，至于“怎么做则是由各企业的流程体系中定义的。为了满足快速开发快速迭代，那么“Agile”的开发方式自然就提上议事日程了，用敏捷的方式落地ASPICE，应该可以事半功倍吧？ 用敏捷的方式如何落地ASPICE呢？ 哪些过程域和实践可以裁剪、任务的优先级如何设定、如何在裁剪之后仍然能满足质量要求、工具链应当如何选取如何配置如何使用、取舍之下主机厂和供应商在哪些方面可以达成共识……，这一系列的问题并没有因为采取了敏捷得到解决，如果没有合适的方法论和扎实的落地能力，最终看到的也许只是一地鸡毛，什么敏捷，还不如按照原来的做法呢，至少还省掉了白折腾的时间。 有什么方法不白折腾就能部署一套适用的流程么？ 很多厂商在一顿折腾后又回到了原点，没有丰富实践和方法论的流程咨询，别说ASPICE和敏捷，任何的流程改进都是空谈。而这也是当年为什么华为要斥巨资请IBM进行流程咨询，最终形成了以IPD为代表的一套体系流程实现组织的持续发展。 咨询公司靠谱么？ 实际上并不是所有的厂商都如华为有如此财力、魄力引入咨询公司的流程体系自我革新，况且外来的流程体系还有“水土不服”的风险。咨询公司在流程体系方面固然可能很专业，但毕竟是外人，对本组织的技术细节和业务发展理解有限，就算有了深入理解合同期满也不再负责。因而即使请了咨询公司，内部也需要一个团队负责流程落地的责任。例如埃森哲针对汽车电子的开发，结合敏捷、ASPICE、功能安全、信息安全等标准和方法论定制出来AutoScrum，在流程部署上倒是面面俱到。 公司内部如何建立部署流程的咨询团队呢？ 内部咨询团队不单要熟悉流程体系，而且也需要对本组织的技术细节和业务发展有深入理解，确保不是“纸上谈兵”，毕竟应付客户已经不易，再给工程师团队头上加个“大爷”（如下图），那比起“白折腾”更受不了。事实上，相对于重新建立一个团队，不如优化已有的团队——软件质量团队是最好的人选，首先他们得天独厚的熟悉流程体系、对具体的项目和工程团队的各个角色（项目经理、产品经理、架构师、程序员、测试组）都会每天打交道、因监管需要有权限查看各个项目资料，而且本来就是“大爷”之一了的QA经理，最关键的，是要让这个团队转型成为一个可以驱动组织变革的咨询性团队。  五、质量驱动，迭代改进——从价值观到方法论 阻力与困境 当质量人员聚在一起分享ASPICE推行的心得时，不可避免地会提及来自工程团队的各种阻力—— “客户合同里都没要求ASPICE，我们凭什么要做？” “最近有人离职资源不足，老板让我们集中精力先把东西做出来。” “最近实在太忙全员每天都在加班，等过段时间好些了一定把流程文档都给你补上！” …… 怎么办？看到晚上灯火通明办公室里加班的小伙伴们确实心下不忍，再加上工程团队或委婉拖延或强势拒绝的说辞，也不自觉地会怀疑自己的价值—— “我这样努力地推行的ASPICE真的有意义么？” “如果真的有意义为什么大家会这样抵触？” “既然大家都不想做为什么公司还要推行？” 事实上，作为质量人员面临各样的推诿拒绝是家常便饭，每个人也都有自己的应对之策，身处这类困境时作为个体的质量人员如何回归专业进一步树立对自己定位的信心，往往才是能“走下去”的关键。个人在十多年的软件质量工作中，在面对此类困境应用比较多的思维框架是ISO9001的7大质量管理原则。 理论与实践 ISO9001的7大质量管理原则列表如下，应当是每个质量人员都能达成的共识，也是我们非常熟悉的理论，而是否能将框架内化到质量思维中，则是只有经历过实际质量工作的困境才能深刻体会到的。  在软件质量领域，ASPICE在公司里的落地，本质上是属于“过程方法”，也就是7大质量管理原则的第4个，质量人员在思考为什么组织定义的过程方法为什么没能贯彻下去的时候，不可忽略的前提是“前三个原则”落实的怎样了？ 1.客户为中心 2.领导力 3.全员参与 在7大原则中，这前3项原则处在价值观层的层面，而后4项原则属于方法论的范畴，而前3项的价值观，则是决定包含“过程方法”在内的后4项原则的方法论能够落实的前提。 如果“客户为中心”只是停留在销售对甲方的服务，关于代码质量、流程监管等的条款项目工程团队选择性忽略只顾着拿到需求往下做，那别提ASPICE，简单的确保测试覆盖率100%都得打折扣； 如果“领导力”中的总监们对ASPICE缺乏基本常识，把这个针对具体项目特定过程域的评估当成公司的认证进行宣传，那么让他们投入资源在项目中落地规范的难度可想而知 ； 如果“全员参与”达成的共识是流程文档都是给质量团队做的，那么应付式文档只能是常态。 所以，当一个过程方法推行的时候，如果遇到的主要阻力是关于“要不要做”的各种推诿拒绝，那么很明显是价值观层面出了问题；而如果遇到的主要阻力是“该怎么做”的各种具体难度，那么就应当在方法论上进行提升，将理论落地实践做好。 六、质量驱动，迭代改进——软件质量团队的定位之争 第一次听到ASPICE，是2008年在日本参加培训时一位同事进行的知识分享，当时对这个与CMMI很相似但是更加契合汽车电子开发的流程体系印象非常深刻。于是问了培训者一个问题，“我们会在开发过程中遵循ASPICE的方法么？“然而得到的回复是——”还不行，ASPICE还没有成为行业共识的标准，目前软件开发还是按照CMMI来做“。 时间一晃来到2022，历时将近14年之后的今天，汽车电子行业已经发生了天翻地覆的变化，而ASPICE也正在逐渐成为行业共识的标准。不知不觉中，焦点已经从“要不要做“变成了”怎么做“。 为了落地必须进行自上而下的推行，以及全员参与的落地，而ASPICE本身只定义了”What（做什么）”，关于解决“How（怎么做）“的定义符合组织实际的过程方法的问题，则需要一个专业团队来负责牵头。在大多数的组织里，软件质量团队就当仁不让地被分配成了这个牵头的角色，因而这个角色的定位也就代表了企业对于ASPICE推行的态度和成熟度。这并没有对错之分，而是根据实际情况所做的定制，而在这定位的过程中最关键的是回答以下两个问题——
归属决定了这个团队的汇报对象和负责部门，而路线则决定了招什么人和做什么事。 归属之争 有人可能很自然地回答，有什么好争的，软件质量团队当然归属于独立的质量部门，若质量不独立则监管不给力。就像自己的代码自己测总找不出问题一样，如果监管流程的质量部门都归属工程团队了，发现了重大缺陷真的有权限叫停么？ 也有人说，从知识体系和工作内容看软件质量团队都应当归属工程部门，脱离软件开发实践活动的质量人员就是个外行，最多能看看文档版本格式对不对，根本起不到发现实际问题的作用。 双方各执一词，而这也并不是一个非黑即白的问题，要回答这个问题，需要分别先看看质量部门与工程部门的组成。 先来看看质量部门。 汽车电子开发是一个复杂的系统工程，即使在质量部门内部，根据服务对象的差异、所处流程的不同，相关成员的知识体系和工作内容都有可能天差地别—— 
…… 诚然，没有独立的授权，软件质量团队很难推行一套流程或者叫停一个行动，但确实也存在知识能力维度的局限。ASPICE的各个过程域无论是系统架构的搭建、软件中CICD的各种指标、测试覆盖率的确认、项目管理的协调等等，作为软件质量人员进行相关的检查都需要相当专业的知识，而这却又因为知识体系的差异不是其他质量团队可以提供的。 反观工程团队，从ASPICE过程域的分工看，项目经理PM负责MAN的管理类过程域，系统团队负责SYS相关PA、软件团队负责SWE相关、SUP/ACQ过程域除了SUP.1归属软件质量则由各部门协商出人负责，各司其职如有未定事项则有PM拍板。这样在知识维度上确实可以做到互补，同一个团队的软件质量人员可以更好与工程团队配合。但是，在这之下的一个问题是，质量人员的话语权能有多少呢？交付优先的原则之下，别说ASPICE就连交付前的release audit也很难保证独立性。  两难之下如何取舍，个人的观点是依据组织的实际情况进行规划。 对初创公司而言，质量管理注重的是“快”，更多关注快速响应而非完善步骤，多数情况下软件质量可能依附于工程部门存在。从流程模板编写、到审计流程评审代码、到搭建CI环境配置管理、到收集度量生成报告……有可能一个人就搞定，哪会像在大公司里那样“这块不归我管”，不懂就马上学上手干。当下国内造车新势力可能会比较适用该种情况 公司中期突破瓶颈之时，质量管理的重心在“广”，随着业务的铺开各种技术难度之大涉猎之广，唯有依靠团队的力量才能突破瓶颈。质量人员不可能成为所有领域的技术专家，而要把控质量必须依靠数据指标，此时关注工程参数过于流程指标，而工程参数也需要抓到重点否则流于形式反而成为负担。此时，兼具技术能力和质量理论的专业团队就必须成型，而且要求相对的独立性，谋求转型的各大OEM、Tier1当属此类情况。 公司长期发展的远景规划中，质量管理则更加注重“稳”。例如当年华为斥巨资请IBM为其做流程咨询完善管理体制，是在其规模效应形成而关注长期发展之时所做的，此时质量部在完善流程体系之下独立运行可按部就班。“大企业病”可能会带来流程冗余的弊端引发工程人员的吐槽，质量人员也有可能因此怀疑自己的价值。因此“稳”就是非常可贵的品质，在坚持原则的同时需要保持一定的灵活性，这是有一定难度的。在该种情况下，质量部门无疑应当是作为独立且强势的部门存在的。 路线之辩 归属明确了，那要招什么人，做什么事呢？ 如果你说要找个架构师到质量团队来验证质量，结果checklist的检查项全都是琐碎的确认文档格式、评审记录之类，那不是大材小用么？ 一般情况下，软件质量团队的路线有三种：技术、产品、流程。个人观点也是根据实际情况进行区分—— 初创公司，或者刚开始部署ASPICE的组织，应当重在技术路线。流程的部署是依赖工具链的，把时间花在填EXCEL做PPT上，不如踏踏实实的把工具链部署好——让程序员通过Jenkins中每天更新的dashboard看到自己注入的warning及时修改；让需求人员通过JIRA / Polarion同步各个功能的细节；让架构师的Enterprise Architect中使用的图例都符合规范……Linux操作系统的创始人Linus Torvalds有一句话“Talk is cheap. Show me the code”（空谈容易，给我代码！）。纵然不用自己写代码，质量人员对应该维持与代码的零距离状态。 中期转型公司则可以走产品路线，将质量需求作为Stakeholder Requirement的一部分写进product backlog里并且明确DoD，然后实打实地把它实现出来。 至于稳定的企业里质量部门当然是流程路线，无论工具链开发流程都已经相对成熟，就只需要专职的质量人员定期审计、培训、评估等等例行公事即可，当然，到了这个时候行业也走向稳定乃至下行了吧。 个人认为，在当下ASPICE标准本身还不完善行业趋势风起云涌之际，无论什么企业，都应当把姿态放低将自己作为一家初创公司带着好奇心走技术路线，认认真真把工具链落实好才是正道。 七、打通工具，实时协同 从物理现象引申到团队合作，无论是产业链、供应链、工具链……任何的链条都适用于这个理论，链条上的最弱一环将可能导致满盘皆输的结局，这也是为什么“卡脖子”的策略能奏效的原因。  如果把主机厂和供应商当做供应链两端主体，那么在软件比重不断提升的今天，链接双方的环节的状态是怎么样的呢？也许是SQE收集到的乙方进度报告质量度量等的PPT，也许是工程团队的验收报告测试结果的EXCEL，又或许是DRE针对各种问题收到的分析报告……是的，这些都是根据流程定义的非常有意义的内容，但为什么总有缺了什么的感觉。甚至当主机厂收到了供应商最详尽的ASPICE评估报告，所有关键过程域都是三级，对于产品质量还是没底。 事实上，以上列举的报告、结果、评估，都是事后的滞后指标，而没有事前或实时的先导指标。 由于缺少实时性，双方的协同不可避免的会出现滞后，而这非常有可能引发链条的断裂风险，例如重大缺陷无法按时修复、物料不足等等等等，那么如何应对这个问题呢？ 以色列学者伊利雅胡·高德拉特基于链条的原理曾提出限制理论，主张一个复杂的系统隐含着简单化。即使在任何时间，一个复杂的系统可能是由成千上万人和一系列设备所组成。但是只有非常少的变数或只有一个，称为限制，它会限制（或阻碍）此系统达到更高的目标。作为解决方法，以下是TOC的五步聚焦法的图例。  TOC应用比较广泛的是在机器工业领域，针对的也是流水线上的各个环节，切换到软件开发领域，流水线就成了工具链——项目管理的Jira、需求的Polarion、设计的EA、开发的Matlab、编译的Jenkins、测试的CANOE……而不是Office的PPT、Excel。 如果主机厂和供应商的链接是基于工具链进行互动，如双方PM针对Jira上的一个story跟踪状态、双方需求人员基于同一个Polarion里的工作项进行评审、双方程序员看到的是同一个Jenkins发出来的代码状态dashboard进行修复……是不是可以省掉修饰PPT排版、调整Excel格式、各种邮件飞来飞去的内耗呢？ ——理想很丰满，现实很骨感。且不说双方的工具链是否统一、信息安全条例是否允许、领导层是否可以达成互信，就算万一真的排除了一切障碍真的达到了这样的互通，出了问题是不是能坐在一起共同解决而不是互相甩锅，还是个问号。 当然，这也许只是发展的问题，很多改革都是倒逼的，软件工程比起已经发展多年的机械工程还只属于发展的初期，现在我们看到的许多问题随着时间的发展用后世的眼光看也许根本不是问题，到时候“打通工具，实时协同”也许就是基本操作了，至于双方达成共识的依据是ASPICE或是其他的标准，那就交给时间来回答了。 |
|
|
