一、ADAS开发痛点分析：传统开发模式下的任务管理困境
大家好，我是老张，在ADAS领域摸爬滚打了快十年。今天咱们聊聊一个很现实的问题——为什么传统开发模式在ADAS项目里越来越玩不转了？
说实话，我见过太多团队，一开始信心满满，结果被任务管理搞得焦头烂额。你想想看，一个ADAS系统涉及感知、规划、控制、标定、测试……光模块就有十几个。传统方式？嗯，基本就是Excel、邮件、微信群三板斧。结果呢？
1.1 信息孤岛：每个人都在“盲人摸象”
我记得2018年做某个L2+项目时，感知团队说“车道线检测OK了”，规划团队却说“怎么老压线？”——后来一查，感知用的数据集和规划用的场景完全不匹配。这就是典型的信息孤岛。
传统模式下，每个团队各管一摊：
- 需求文档在Word里，改了一版又一版，没人知道最新版在哪
- 测试用例在Excel里，谁改了谁没改，全靠人工核对
- Bug反馈在邮件里，@来@去，最后发现漏掉了关键问题
说白了，这就是个“黑箱”。你永远不知道隔壁团队在干什么，也不知道自己的任务卡在谁手里。
核心痛点：ADAS开发是强依赖的链条式协作。感知输出给规划，规划输出给控制，任何一个环节的信息断层，都会导致整个系统崩盘。
1.2 需求变更：一天变三次，谁受得了？
做ADAS的都懂，需求变更是家常便饭。今天主机厂说“AEB触发速度要调到80km/h”，明天法规更新说“必须支持VRU保护”，后天测试发现“弯道场景误触发太多”……
传统模式下，需求变更怎么处理？
- 产品经理发一封邮件：“各位，需求更新了，请查收附件V3.2”
- 开发人员打开附件，发现改动用红色标注了，但没写改动原因
- 测试人员拿到新需求，发现和之前测的不一样，但不知道哪些用例要重跑
我曾经遇到过一个项目，因为需求变更没同步到位，感知团队按旧需求开发了两个月，结果全部返工。你说痛不痛？
避坑指南：我曾经见过一个团队，用微信群管理需求变更。结果某天晚上10点，产品经理在群里发了条消息“AEB策略改了”，第二天早上开发没看到，直接按旧方案提测……嗯，后果你懂的。
1.3 进度失控：你以为的“快”其实是“慢”
传统模式下，进度管理基本靠“问”。项目经理每天追着问：“那个模块做完了吗？”“还差多少？”“什么时候能测？”
结果呢？
- 开发说“代码写完了，但还在自测”
- 测试说“环境还没搭好，等开发给版本”
- 系统集成说“模块接口对不上，需要联调”
每个人都在等别人。你想想看，一个ADAS系统有几十个模块，每个模块等一天，整个项目就拖一个月。更可怕的是，没人知道真正的瓶颈在哪。
我的经验：我个人习惯用“任务依赖图”来梳理进度。传统Excel根本画不出这种关系，你只能靠脑子记。但人脑是会骗人的——你以为A完成了，其实B还在等A的接口文档。
1.4 质量回溯：出了问题找不到根因
ADAS系统最怕什么？怕路测时突然来个“幽灵刹车”。更怕的是，出了问题后，没人说得清是哪个环节导致的。
传统模式下，质量回溯基本靠“回忆”：
- “这个代码是谁写的？”——开发A说“我写的，但后来B改过”
- “这个测试用例是谁执行的？”——测试C说“我跑的，但环境参数和文档不一样”
- “这个需求是谁提的？”——产品经理D说“我提的，但后来改过两版”
你看，全是“人证”，没有“物证”。没有记录，没有版本，没有关联。说白了，就是一团乱麻。
关键问题：ADAS开发需要可追溯性。从需求到代码，从代码到测试，从测试到问题，每一步都要有记录。传统模式做不到这一点。
1.5 为什么ADAS开发需要Jira？
好了，痛点说完了。你可能会问：“那Jira能解决这些问题吗？”
我的答案是：能，但前提是你得会用。
Jira不是万能的，但它提供了几个核心能力，正好切中ADAS开发的要害：
| 痛点 | Jira的解决方案 |
|---|---|
| 信息孤岛 | 统一的任务管理平台，所有信息集中可见 |
| 需求变更 | 版本控制+变更记录，谁改了什么一目了然 |
| 进度失控 | 看板+燃尽图，实时掌握项目状态 |
| 质量回溯 | 任务关联+字段自定义，从需求到问题全程可追溯 |
我个人习惯把Jira当成ADAS开发的“数字孪生”。什么意思？就是你在Jira里看到的任务状态，就是实际开发的真实映射。不是Excel里的“假数据”，而是每个人每天在更新的真实进度。
一个小建议：刚开始用Jira时，别想着一步到位。先解决最痛的问题——比如需求变更和进度跟踪。等团队习惯了，再慢慢加功能。我见过太多团队，一上来就搞复杂的工作流，结果没人会用，最后又回到Excel了。
好了，这一章我们聊了传统模式的痛点，也简单说了Jira为什么能帮上忙。下一章，我会具体讲讲怎么在Jira里搭建ADAS开发的任务管理体系。嗯，到时候咱们再细聊。