在 9 月 15 日的第七届 CSN 大会上,思码逸研发效能专家王艳萍受邀分享了《汽车行业研发效能提升的挑战与实践案例》。演讲包含了思码逸对多家汽车企业服务过程中总结出的行业痛点、解决方案,以及实践案例。
以下为演讲实录:
思码逸与很多知名汽车企业都有合作。我们这次的演讲会先简单介绍一下思码逸,然后重点分享我们与汽车企业在研发效能层面的实践,汽车软件研发效能与传统软件研发效能的差异,以及在汽车行业中,软件研发效能度量的痛点与解决方案等。
思码逸成立于 2018 年,专注于软件研发效能度量与分析。基于深度代码分析技术,思码逸产品从代码和 DevOps 工具链中提取数据,呈现研发效率、软件工程质量、组织与人才发展等多视角数据洞察,提高研发过程可见性,辅助团队决策,推动开发者自驱成长。
思码逸独有的研发效能指标“代码当量”已经作为核心指标,被信通院采纳。我们也受信通院邀请,与京东、腾讯、百度、网易等等 40 多家公司,一起起草了《软件研发效能度量规范》。
我们目前服务了上百家企业,其中来自汽车行业的包括理想、蔚来、宝马、保时捷、沃尔沃等。
汽车行业的软件研发效能特征与挑战
相比传统的软件研发,汽车软件的研发会更加复杂,主要体现在两方面,一方面是项目复杂,另一方面是人员复杂。
首先,项目方面存在以下特点:
体量大:规模大、交付周期长,子项目类型多
版本众多:为了适配各种硬件,需要更多版本,所以每个版本中的模块复用度高。一旦模块底层需要修改,那么带来的技术维护难度大,所以有更高的质量要求。
嵌入式开发:软硬结合的开发方式,在软件测试时,需要适应物理环境及硬件接口,所以会导致测试效率比传统软件开发要慢。
安全性要求高:相比传统软件开发,汽车软件对安全的要求非常高, 包括功能安全、网络安全等,一旦出现问题,就可能危及用户生命。
由于项目的复杂度高,所以相应地会在人员上带来更高的复杂度,主要体现在两方面。一方面是人员构成比较复杂,不仅有公司内部的研发团队,还有外包团队。在人员岗位上,除了传统的前端、后端、算法,还会包含嵌入式开发等硬件相关的研发人员。
基于以上特点,汽车软件研发对效能度量的要求会比较高。我们总结了一下我们客户经常遇到的研发效能度量的诉求。
首先由于研发项目体量大,所以即使效率提升一个百分点,也可以节省巨大的成本。所以第一个诉求就是“提升整体效率,做更准确的需求预估”。另一个诉求,就是“及时判断卡点,找到影响交付速度的关键因素”,从而提升项目整体的效率。
因为整个软汽车行业对安全可靠性的要求非常高,这就要求我们能在整个研发过程中及时地发现问题,保证可以在最终测试和交付之前解决掉关键问题,而不是在最后发现问题,再回过头去修改。
在人员管理方面,主要诉求就是“建立考核标准,制定研发流程规范”,通过科学的方法来管理复杂的团队。
最后从项目和人员管理两个角度综合来看,还有一个诉求就是“合理调配资源,避免忙闲不均或者资源错配带来的浪费”。
由这些诉求出发,结合我们与多个汽车企业合作的经验来看,我们可以看到汽车行业做研发效能度量的四个难点:
第一,数据分散。研发数据可能分散在多个不同的工具中,整合数据是一个难点。
第二,缺少可靠的数据基础指标。例如要统计这个工时内完成了多少需求、功能点,这些数据的填写大多是依赖个人主观判断的,所以没有统一的标准,那么这就给后续的数据分析带来难题。同时,还有大量的代码复用、功能点大小不一等问题,都是由于缺少基础的指标。
第三,分析维度、视角多。一个项目可能会涉及到多个子项目、版本,每个子项目背后可能还有不同的团队、不同的人。在团队中,高层、中层对项目的关注点都不同,所以会涉及到非常多的维度和视角。我们有很多客户都是说“我们有很多指标,但就是用不起来”,其背后的原因就是因为你给出分析结果,并不一定是这个管理者或角色他想看到的。高管不希望看到那么多细节信息,而基层管理者却希望从细节中发现改进点。
第四,定位问题困难。由于项目周期长、项目复杂度高,甚至可能还会涉及到较多的外包资源,所以很难快速地定位问题。
解决方案与实践案例
我们为汽车行业提供了这样一套解决方案,如下图所示。我们从数据采集、建模、指标体系,到分析,提供了一套全流程的度量与分析平台。我们已经把常用的代码仓库、项目管理工具、质量扫描工具和 CI/CD工具的数据接口打通了,可以通过简单配置就将数据接入进来。如果你使用的是我们还未支持的工具,也可以通过 CSV 的形式将数据导入到平台中。我们的平台会清洗数据,并基于数据建模输出事务管理、代码效率、质量管理等模型。
在平台中,我们根据对上百家企业的服务经验,默认预置了 100+研发效能指标,根据你的模型会推荐一些指标,并支持用户自定义指标。
在分析层面,我们支持根据不同角色进行多维度的数据展示和分析。如果是需要了解更多细节信息的管理者,还可以针对数据进行下钻分析,直至找到问题的根源。
另外,我们还提供一些行业基线和组织基线,让你可以知道目前团队的研发效能、项目质量在行业中所处的水平是怎样的,以及与自身相比是否在持续进步,甚至于公司内其他团队相比处于什么样的位置。为了让管理者更容易去分析数据,我们还在平台中提供了智能专家系统,来辅助解读数据指标和现状。
我们已经把大部分的高频指标都放在平台中了。我们简单介绍一下核心指标“代码当量”。大家可以将它理解为与“代码行数”对标的一个指标。但是代码行数可能会遇到空行、注释、第三方引用等。这让代码行数无法真实体现产出效率。“代码当量”是基于深度代码分析算法产生的,它会将代码书写过程中这些“水分”挤掉,而且这套算法的计算机制较为复杂,所以很难造假,可以提供更客观的度量数据。
下面我们举几个例子。我们平台提供了 30 多种图表的展示,图中的一些异常点都可以直接点击进去看更深层的数据,进行下钻分析。用户可以根据不同管理者的需求定制自己的看板。比如高层关注整体的指标,可以看 ROI、整体交付速度、交付效率,以及资源配置是否均衡等。
对于项目经理或团队 Leader,可以关注团队的项目进展等更细的数据。例如下图左边的交付效率中,处于右下角的“后端团队”的交付效率就比较低,那么点击它,就可以进一步下钻寻找原因。那这个原因到底是什么?有可能是某一个地方遇到了卡点,或者是这个需求涉及的产品设计时间比较长,也有可能是需求颗粒度不稳定,所以他交付的需求少,还有可能是遇到了比较大的 Bug 需要较长的时间修复。这些问题都可以从下钻分析中发现。
从质量层面,我们可以看整体项目上线的 bug、事故数量,代码的内建质量,以及bug 的修复工作量。我们也会推荐一些重点关注的函数,比如某些代码的圈复杂度比较高或被引用次数比较多,那么会优先推荐进行一些测试。
以上就是对于思码逸解决方案的一个大致的介绍。接下来,我们来看一个汽车行业的实践案例。
这个案例源自某个车企,他们的研发规模有 200 多人,他们有很大比例的外包人员,所以他们希望可以准确预估整体的工作量,并建立对外包供应商的评估体系。他们原先使用“事故点”、“工时”去评估需求颗粒度,这对于资源需求以及如何调配来讲,缺少客观参考信息。针对这个问题,我们基于代码当量,量化了需求颗粒度,保证需求颗粒度的稳定性,并且估算研发交付的带宽。
另一个问题就是,他们有大量的外包团队,他们对这些团队的管理不是很到位,缺少体系化的度量,无法准确判断外包整体的效率。针对这个问题,我们基于代码当量,帮助他们设计了一个供应商评分体系。
如下图显示,我们可以理解为这就是通过代码当量来计算出的研发产能。图中显示的是代码产能与需求个数的拟合曲线。拟合优度大于 60%的时候,就代表这个团队的工作产能是可预测的。对于不可预测的团队,我们可能要去找原因,为什么这周产出多,下周产出少。如果大家都处于比较稳定的水平时,就可以知道每个团队交付的贷款是多少。
另外一点是从需求的角度进行分析。如下图右侧所示,你可以看到一些稳定性较高的需求,我们可以通过他们来预估各个需求的工作量。根据刚刚的交付贷款和工作量的预测,就可以计算出应该怎么做资源的配比。
下面这张图是我们基于客户的需求设计的评分体系。比如在产能方面,我们不只是看代码当量的产出,还会看代码活跃度;在质量方面会看发版的质量、底层的质量,这样可以一目了然每个供应商的表现如何。
提问 对于需求工作量的预测,你们是基于什么逻辑来做的?如果要预测需求的工作量,对我们的要求是什么?
回答 这里讲的需求更多是开发的需求。由于每个产品经理拆需求的时候大小不一。所以我们的逻辑是,基于代码当量,来度量一遍历史的需求,能看出每个需求的代码当量是多少,比如这个需求是 1000 当量,另一个是 500 当量。如果需求的当量相对稳定,那就可以预估之后这个需求大概是怎样的量级,它的偏差幅度在 10%-20%以内,是可以评估这个需求大概需要多少工作量。然后结合我们对团队交付能力的评估,比如一个团队一周能交付 500 当量,或 1000 当量的代码,那么这个需求就需要这个团队一周的时间来完成。
如果发现需求拆分的颗粒度大小不一,那么就需要溯源,查找原因,调节拆分需求的逻辑和方法。
可访问 链接 获取 演讲PDF