前言
2025年的汽车行业的智能化竞争，依旧如火如荼：新势力造车、智能驾驶、电动化浪潮席卷全球。在这个“软件定义汽车”的时代，Jira——这个原本服务于互联网企业的敏捷开发工具——在汽车行业也逐渐生根发芽，并有逐渐长大之势。如我之前一篇文章所说，50%汽车人都在拒绝敏捷开发，我们在拒绝什么?有多少人欢迎敏捷开发，就有多少人拒绝敏捷开发，甚至拒绝的比例，早已超过50%。
不过，Jira所代表的敏捷开发理念，进入汽车行业之势，却是不可阻挡。
但Jira真的能解决汽车行业复杂的研发流程吗？它为何能快速渗透到汽车产业链？又为何在智能座舱之外的领域频频“翻车”？本文将从行业趋势、技术逻辑和真实案例出发，分析Jira在汽车行业的局限。
1
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 个月一迭代，硬件还没 SOP，OTA已经推了 5 个版本——Jira 成了“快”的代名词。
2.敏捷开发场景下的六边形战士
近5年财报显示，Atlassian营收年均增长超40%，其核心引擎Jira占据全球敏捷开发工具68%市场份额（Forrester数据），远超其他同类竞品。
Jira在敏捷开发这个项目管理市场的统治力确实太强，几乎成了敏捷开发的代名词。我个人也是Atlassian官方认证的DC和Cloud双重Admin，当时在Atlassian官方网站自学Jira的各类高级操作时，也深深为这款工具20多年建立的技术细节所折服。有很多很精巧的产品设计，也让我看到了我们自研工具——MappingSpace发展的未来。
2
当Jira遇到汽车行业V模型：
流程设计与工具的妥协
当电子电器、智驾等系统需满足ASPICE L2+/ISO 26262时，Jira+Confluence这对组合，也有一系列问题需要解决。
注意：下文示例中所举的案例，是我基于过去自己的经验，以及与几十家不同客户访谈，总结的比较常见的做法。事实上，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的安全分析工作，由此诞生出来的安全需求、安全架构设计，如何在普通的需求、架构文档上，进行更深层次的分析？还是不得不为此，重新整理一份安全需求文档？
将上述所有分析过程图，汇总如下：
3
写在最后
Jira在汽车行业的流行与上述提到的这些问题，都指向一个事实：工具的诞生，是基于时代背景下的方法论，但不同的工具，对方法论的落地，却有非常大的影响。通用领域能够解决一些问题，但对于解决垂直领域的一些深层次的使用场景，可能会有不少gap。
ASPICE的本质是系统工程，而非项目管理，通过简单的跨领域的软件工具引进，很难完全覆盖汽车V模型全周期的数字流程。
一种可能的解决方案是，继续在Jira上做更深层次的自定义开发，因为Jira提供了非常友好的开发环境、数据库调用、以及一定程度的代码开源。
不过，我们都不得不承认一个事实：每个时代都有每个时代最为优秀的软件代表，就像个人PC操作系统的进化之路，从70年代的UNIX，到80年代的麦金塔、Windows，再到2000年前后的Linux、Android、iOS，再到如今正在不断进化的华为鸿蒙，带来了跨设备协作的非凡体验，每个时代诞生的操作系统，都力求解决那个时代发展下，上一代操作系统无法未卜先知的未来，从而未能覆盖的应用场景。
因此，另一种可能的解决方案是：在汽车越来越向消费电子进化的路上，在ASPICE越来越向敏捷开发融合的路上，我们既需要一些新的方法论，同时，我们也需要基于新的方法论，基于这个时代下的汽车开发场景（比如基于CICD的HIL测试，比如OTA，比如安卓系统上车，这些我们在10年前、20年前的车子里完全没有的技术，现在已经成为了标配），开发出一些新的软件工具来。我们开发的MappingSpace可能是其中的一款，AI时代，ALM需要再造但无法代表所有人的思考逻辑和理念，就像福特带来了流水线理念，丰田带来了精益理念，我们希望在汽车软件基础设施这个领域，也能有更多玩家一起，百花齐放百家争鸣，成为中国造车带给世界的一种新的车载软件开发理念。
