Jira能应对汽车敏捷开发困境么？

以下文章来源于汽车电子与软件作者罗宇超前言2026年的汽车行业的智能化竞争依旧如火如荼新势力造车、智能驾驶、电动化浪潮席卷全球。在这个“软件定义汽车”的时代Jira——这个原本服务于互联网企业的敏捷开发工具——在汽车行业也逐渐生根发芽并有逐渐长大之势。我之前有一篇文章说过50%汽车人都在拒绝敏捷开发我们在拒绝什么?有多少人欢迎敏捷开发就有多少人拒绝敏捷开发甚至拒绝的比例早已超过50%。不过Jira所代表的敏捷开发理念进入汽车行业之势却是不可阻挡。但Jira真的能解决汽车行业复杂的研发流程吗它为何能快速渗透到汽车产业链又为何在智能座舱之外的领域频频“翻车”本文将从行业趋势、技术逻辑和真实案例出发分析Jira在汽车行业的局限。一、Jira的崛起从创业传奇到行业垄断1. 从 9 张信用卡到 490 亿美元市值——Jira 的爽文剧本2002 年两个悉尼青年用 9 张信用卡额度 1 万澳元启动 Atlassian。2010 年拿下 Accel 6,000 万美元首轮外部融资估值 4 亿美元。2015 年纳斯达克上市当天市值 57 亿美元。2023 财年Atlassian 总收入 35.4 亿美元净利润率 18%现金流足以买下两个 GitLab。2014-2015 年中国造车新势力入场把互联网敏捷流程连同 Jira、Confluence、Gitlab、Jenkins 直接搬进汽车软件团队。智能座舱 3 个月一迭代硬件还没 SOPOTA已经推了 5 个版本——Jira 成了“快”的代名词。2.敏捷开发场景下的六边形战士近5年财报显示Atlassian营收年均增长超40%其核心引擎Jira占据全球敏捷开发工具68%市场份额Forrester数据远超其他同类竞品。Jira在敏捷开发这个项目管理市场的统治力确实太强几乎成了敏捷开发的代名词。我个人也是Atlassian官方认证的DC和Cloud双重Admin当时在Atlassian官方网站自学Jira的各类高级操作时也深深为这款工具20多年建立的技术细节所折服。有很多很精巧的产品设计也让我看到了我们自研工具——MappingSpace发展的未来。二、当Jira遇到汽车行业V模型流程设计与工具的妥协当电子电器、智驾等系统需满足ASPICE L2/ISO 26262时JiraConfluence这对组合也有一系列问题需要解决。注意下文示例中所举的案例是我基于过去自己的经验以及与几十家不同客户访谈总结的比较常见的做法。事实上Jira的最大优势之一就是其灵活性、可配置性、可扩展性的能力足够强包括能够做各类型二开因此Jira在不同汽车行业企业内部可能有比较多不同的用法。如下展示的4个场景反映了较大一部分汽车行业的痛点问题。1. 文档管理的双重源头隐形的人力消耗Jira的核心是“Issue跟踪”但汽车行业的文档管理远非“任务清单”可以解决。案例某车企在开发智能驾驶功能时需求、架构设计、详细设计文档以word、excel、pdf或在线文档存储在Confluence为了后续建立追溯性或跟踪方便这些文档又不得不被拆解成Jira Issue在Jira中进行管理。当需求需要更新时团队仅更新Jira中的Issue而Confluence文档未同步导致设计人员基于过期文档开发返工耗时3周。痛点Jira无法直接将Word/Excel文档转为条目化Issue需人工二次录入或者自己编写python脚本并持续维护人力成本增加20%以上。2. 追溯性的数字迷宫链接追溯无法解决的覆盖度统计困境ASPICE要求的需求-设计-测试“全链路追溯”在Jira中很难进行统计如上文所述很多团队会将文档拆解成Jira Issue进行跟踪从而建立需求-设计-测试用例的双向链接追溯。但是此类链接追溯在Jira中缺乏统计功能从而无法了解追溯覆盖的完整性。根据上一段所述由于所有文档都有两个源头Jira Issue更多被作为临时开发任务进行追踪真正的需要统计覆盖度的源头应该是Confluence中的文档。那如何来统计Confluence中文档的覆盖度呢一个常见的做法是手工编号建立excel追溯矩阵然后对excel表格进行统计。将需求、架构、详细设计word文档手动转成excel的格式给每一行的需求、架构、详细设计人为增加一个编号该编号的规则一般由配置工程师指定一般是以类似SYS_Proj_x的形式然后在excel中增加列如“关联需求”“关联架构”等填上对应的编号以此建立追溯性。一方面这带来了额外的人力成本消耗。另外这会有什么风险呢2023 年某主机厂功能安全审核审核员在 4,000 行 Excel 里随机抽查 13 条追溯链其中 5 条找不到对应文件8个系统需求追溯到同一个架构ID但该架构ID又指向完全不同的架构描述。追溯性策略宣告失效追溯性表格需要重新整理项目推迟 2 个月。3. 变更管理引起的问题流出基线管理与变更管理是V模型流程中最为复杂的2个管理流程。在ASPICE 4.0版本中Baseline一词出现了32次之多。说它复杂是因为变更的流程长涉及的范围广不仅需要找到所有的受影响方还需要针对所有受影响方进行修改、受影响分析经过变更委员会的同意之后才能最终实施。这套流程一般如何落地的呢以某底盘设计团队举例底盘控制模块的需求、设计文档、测试用例基线冻结在Confluence V1.2页面所有人只能看而无修改权限开发组基于变更的需要在Jira中提交了一个变更任务ISSUE-7732描述变更的细节。由于追溯性是通过上述所述的excel矩阵进行管理因此需要找到变更受影响方就需要手动一个excel、一个excel的查找并找到其在基线中所在的文档。在ISSUE-7732中详细的描述变更的细节所有受影响的文档都需要修改直至最终获得CCB的同意HIL测试团队在进行测试时基于冻结的Confluence V1.2基线页面进行了测试忽略了开发团队增加的变更最终结果测试场景遗漏bug流出到下一环节。究其原因基线与变更存储在不同的地方很难保证团队所有人得到变更通知。4. 插件带来的削足适履上述提到的一些问题都可以通过一些额外购买的插件或者定制化开发插件得到一定程度的缓解比如但是基于这种定制化开发而诞生出来的流程再碰到更高维度的管理时往往面临着更艰难的抉择是在这套工具上继续委曲求全还是从头开始基于V模型重新梳理流程比如不同项目之间的复用如何进行管理当需求被复用之后架构设计、详细设计、测试用例能否自动建立追溯当碰到功能安全、信息安全需求时需要进行HARA、FMEA、FTA、TARA的安全分析工作由此诞生出来的安全需求、安全架构设计如何在普通的需求、架构文档上进行更深层次的分析还是不得不为此重新整理一份安全需求文档将上述所有分析过程图汇总如下写在最后Jira在汽车行业的流行与上述提到的这些问题都指向一个事实工具的诞生是基于时代背景下的方法论但不同的工具对方法论的落地却有非常大的影响。通用领域能够解决一些问题但对于解决垂直领域的一些深层次的使用场景可能会有不少gap。ASPICE的本质是系统工程而非项目管理通过简单的跨领域的软件工具引进很难完全覆盖汽车V模型全周期的数字流程。一种可能的解决方案是继续在Jira上做更深层次的自定义开发因为Jira提供了非常友好的开发环境、数据库调用、以及一定程度的代码开源。不过我们都不得不承认一个事实每个时代都有每个时代最为优秀的软件代表就像个人PC操作系统的进化之路从70年代的UNIX到80年代的麦金塔、Windows再到2000年前后的Linux、Android、iOS再到如今正在不断进化的华为鸿蒙带来了跨设备协作的非凡体验每个时代诞生的操作系统都力求解决那个时代发展下上一代操作系统无法未卜先知的未来从而未能覆盖的应用场景。因此另一种可能的解决方案是在汽车越来越向消费电子进化的路上在ASPICE越来越向敏捷开发融合的路上我们既需要一些新的方法论同时我们也需要基于新的方法论基于这个时代下的汽车开发场景比如基于CICD的HIL测试比如OTA比如安卓系统上车这些我们在10年前、20年前的车子里完全没有的技术现在已经成为了标配开发出一些新的软件工具来。我们开发的MappingSpace可能是其中的一款AI时代ALM需要再造但无法代表所有人的思考逻辑和理念就像福特带来了流水线理念丰田带来了精益理念我们希望在汽车软件基础设施这个领域也能有更多玩家一起百花齐放百家争鸣成为中国造车带给世界的一种新的车载软件开发理念。作者介绍罗宇超云体科技创始人前蔚来汽车软件质量工程师工具链工程师。