2、Jira核心概念速览：项目、问题、工作流、面板，ADAS场景下的概念映射

好，咱们直接进入正题。Jira这东西，乍一看界面花花绿绿的，菜单也多。但你别慌，核心概念其实就四个：项目、问题、工作流、面板。把这四个东西搞明白，Jira在你手里就是个顺手的工具。

我刚开始带ADAS项目时，团队里有人把Jira当Excel用，有人当聊天软件用，乱得一塌糊涂。后来我意识到，不是工具不好，是大家没理解这几个概念在ADAS里到底对应什么。今天我就带你走一遍，顺便把每个概念映射到咱们ADAS的实际场景里。

2.1 项目（Project）—— 你的ADAS开发“容器”

项目是什么？说白了，就是一个独立的“工作空间”。在Jira里，一个项目可以是一个产品、一个平台，或者一个专项攻关。

在ADAS开发中，我习惯这样划分：

• 按功能域划分：比如“ACC自适应巡航项目”、“LKA车道保持项目”、“AEB自动紧急制动项目”。每个项目独立管理自己的需求和缺陷。
• 按平台划分：比如“ADAS域控制器V1.0项目”、“ADAS域控制器V2.0项目”。适合做平台化开发。
• 按阶段划分：比如“ADAS系统需求分析项目”、“ADAS系统集成测试项目”。适合大型团队分工。

2.2 问题（Issue）—— ADAS开发中的“原子任务”

问题是Jira里最核心的单元。你想想看，ADAS开发中所有的事情，都可以抽象成一个“问题”。

Jira预置了几种问题类型，我直接给你映射到ADAS场景：

嗯，这里要注意：Bug和Story是ADAS开发中最常用的两种问题类型。我见过很多团队把Bug当Task用，结果统计缺陷率时数据全乱了。Bug就是Bug，Task就是Task，别混。

2.3 工作流（Workflow）—— ADAS任务的“生命周期”

工作流，说白了就是一个问题从“出生”到“死亡”的完整路径。每个状态代表一个阶段，每个转换代表一个动作。

在ADAS开发中，一个典型的Bug工作流长这样：

新建(New) 
  → 确认中(Confirmed) 
  → 开发中(In Progress) 
  → 修复完成(Resolved) 
  → 测试中(In Testing) 
  → 验证通过(Closed) 
  → 重新打开(Reopened) ← 如果测试不通过

我跟你讲，这个流程看着简单，但实际跑起来坑很多。比如：

• 谁负责“确认中”？ 我建议是系统工程师或测试负责人。不能开发自己确认自己的Bug。
• “修复完成”后谁测试？ 必须是独立的测试人员，不能是写代码的那个人。
• “重新打开”怎么处理？ 我曾经遇到过，一个Bug被反复打开5次，最后发现是需求理解不一致。所以，重新打开超过2次，建议拉个会。

2.4 面板（Board）—— ADAS团队的“作战指挥室”

面板，就是Jira里那个看板视图。它把问题按状态排列，让你一眼看清团队在干什么。

在ADAS开发中，我推荐两种面板：

• Scrum面板：适合按迭代（Sprint）开发。比如每两周一个Sprint，面板上只显示当前Sprint的任务。我习惯在面板上增加一列“阻塞中”，专门放那些被外部依赖卡住的任务。
• Kanban面板：适合持续流动的开发模式。比如缺陷修复、小需求变更。没有固定迭代，任务来了就做，做完就走。

我个人更偏爱Scrum面板做ADAS功能开发，因为ADAS功能开发通常有明确的版本节奏。比如“V1.0版本必须包含AEB和ACC”，那用Sprint来管理就非常清晰。

面板上我还会加几个快速过滤器：

• “只看我的任务”
• “只看高优先级Bug”
• “只看阻塞中的任务”

这些过滤器能帮你从一堆任务里快速找到重点。你想想看，一个ADAS项目动辄几百个问题，没有过滤器，你光翻就翻半天。

2.5 概念映射总结

最后，我画个简单的映射表，方便你记忆：

这四个概念，你只要在脑子里把它们和ADAS的实际工作对应起来，Jira就不再是那个“难用的项目管理工具”，而是你手里一把顺手的刀。下一章，我会带你亲手创建一个ADAS项目，咱们把理论落到实操上。