前言
2025年的汽车行业的智能化竞争，依旧如火如荼：新势力造车、智能驾驶、电动化浪潮席卷全球。在这个“软件定义汽车”的时代，Jira——这个原本服务于互联网企业的敏捷开发工具——在汽车行业也逐渐生根发芽，并有逐渐长大之势。如我之前一篇文章所说，50%汽车人都在拒绝敏捷开发，我们在拒绝什么?有多少人欢迎敏捷开发，就有多少人拒绝敏捷开发，甚至拒绝的比例，早已超过50%。
不过，Jira所代表的敏捷开发理念，进入汽车行业之势，却是不可阻挡。
但Jira真的能解决汽车行业复杂的研发流程吗？它为何能快速渗透到汽车产业链？又为何在智能座舱之外的领域频频“翻车”？本文将从行业趋势、技术逻辑和真实案例出发，分析Jira在汽车行业的局限。
Jira 的崛起：从创业传奇到行业垄断
Jira 在敏捷开发这个项目管理市场的统治力确实太强，几乎成了敏捷开发的代名词。近 5 年财报显示，Atlassian 营收年均增长超 40%，其核心引擎 Jira 占据全球敏捷开发工具 68% 市场份额。
Jira 在敏捷开发场景下确实是六边形战士。有很多很精巧的产品设计，也让我看到了我们自研工具 MappingSpace 发展的未来。
当 Jira 遇到汽车行业 V 模型：流程设计与工具的妥协
当电子电器、智驾等系统需满足 ASPICE L2+/ISO 26262 时，Jira+Confluence 这对组合，也有一系列问题需要解决。
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 中缺乏统计功能，从而无法了解追溯覆盖的完整性。
一个常见的做法是：手工编号，建立 Excel 追溯矩阵，然后对 Excel 表格进行统计。将需求、架构、详细设计 Word 文档，手动转成 Excel 的格式，给每一行的需求、架构、详细设计，人为增加一个编号，然后在 Excel 中增加列填上对应的编号，以此建立追溯性。
2023 年某主机厂功能安全审核，审核员在 4000 行 Excel 里随机抽查 13 条追溯链，其中 5 条找不到对应文件，8 个系统需求追溯到同一个架构 ID，但该架构 ID 又指向完全不同的架构描述。追溯性策略宣告失效，项目推迟 2 个月。
3. 变更管理引起的问题流出
基线管理与变更管理是 V 模型流程中最为复杂的 2 个管理流程。在 ASPICE 4.0 版本中，Baseline 一词出现了 32 次之多。
以某底盘设计团队举例：底盘控制模块的需求、设计文档、测试用例基线，冻结在 Confluence V1.2 页面。开发组基于变更的需要，在 Jira 中提交了一个变更任务。由于追溯性是通过 Excel 矩阵进行管理，因此需要找到变更受影响方，就需要手动一个 Excel、一个 Excel 地查找。最终结果：HIL 测试团队基于冻结的 Confluence V1.2 基线页面进行了测试，忽略了开发团队增加的变更，测试场景遗漏，Bug 流出到下一环节。
究其原因：基线与变更存储在不同的地方，很难保证团队所有人得到变更通知。
4. 插件带来的削足适履
上述提到的一些问题，都可以通过一些额外购买的插件或者定制化开发插件，得到一定程度的缓解。但是基于这种定制化开发而诞生出来的流程，再碰到更高维度的管理时，往往面临着更艰难的抉择：是在这套工具上继续委曲求全，还是从头开始，基于 V 模型重新梳理流程？
比如：不同项目之间的复用如何进行管理？当碰到功能安全、信息安全需求时，HARA、FMEA、FTA、TARA 这些安全分析工作，如何在普通的需求、架构文档上进行更深层次的分析？
写在最后
Jira 在汽车行业的流行与上述提到的这些问题，都指向一个事实：工具的诞生，是基于时代背景下的方法论，但不同的工具，对方法论的落地，却有非常大的影响。 通用领域能够解决一些问题，但对于解决垂直领域的一些深层次的使用场景，可能会有不少 gap。
ASPICE 的本质是系统工程，而非项目管理，通过简单的跨领域的软件工具引进，很难完全覆盖汽车 V 模型全周期的数字流程。
在汽车越来越向消费电子进化的路上，在 ASPICE 越来越向敏捷开发融合的路上，我们既需要一些新的方法论，同时，也需要基于新的方法论、基于这个时代下的汽车开发场景，开发出一些新的软件工具来。
