简介Jira作为Atlassian公司主流的项目与任务管理工具广泛应用于软件开发团队的敏捷协作与缺陷跟踪。这份操作说明书定位零基础新手手把手讲解创建任务、权限分配、工作流状态流转、面板配置与迭代管理等核心操作并配有截图辅助尤其适合项目管理员、测试人员和开发工程师快速上手。资源包含1个doc文档压缩包大小6.07MB文档内容从JIRA简介、访问方法、特性到开发/缺陷/其他任务三类工作流再到项目角色、版本模块、问题搜索与批量处理、面板创建与共享、迭代管理等均有覆盖章节结构非常清晰。目前已有531人学习下载便于按目录速查或系统学习是一份可直接对照操作的入门手册。1. 别把 Jira 当 Excel先搞清楚它到底解决什么问题一个 20 人的研发团队如果用 Excel 排期前三周没问题第四周开始就会出现“改了一个状态忘了通知下游”“权限分不清谁能编辑”“版本和迭代对不上账”这三类问题。Jira 这种基于 J2EE 的项目管理系统核心不是给你一张更漂亮的表格而是把需求、任务、缺陷、流程审批放进同一套带状态机的数据模型里让“谁在什么时间该干什么”变成一条可追踪、可追溯、可统计的流水线。很多 jira 使用教程上来就教点按钮反倒把最关键的“状态机”和“角色权限”放在了最后这正好是这篇内容想纠正的地方。适合第一次接手项目配置的项目管理员也适合想知道“流程为什么要这么设计”的开发、测试和产品。即使已经用了一两年 Jira后面关于 JQL 函数、筛选器共享和批量操作的边界问题应该也还有信息量。2. 问题类型、工作流与项目角色搭建 Jira 前必须先想清楚的三件事2.1 问题类型体系从 Epic 到缺陷的层级关系Jira 里最小、最重要的单位叫“问题”。Epic、故事、改进、任务、缺陷、风险本质上都是以问题形式提交到系统中的一条记录。问题类型决定了这条记录走哪套工作流、显示哪些字段、谁能创建。下表是这版手册定义的最常用类型及创建权限问题类型创建人员说明Epic史诗项目管理员大型用户故事可拆成故事/任务可跨多个迭代传递故事项目管理员用户故事描述一个从用户视角出发的功能需求改进项目管理员对现有功能或任务的增强不是新功能任务项目管理员非开发类工作设计、管理、文档编写、实施部署缺陷测试人员损害或阻止产品功能的问题用 BugWorkflow 管理风险项目管理员项目过程中存在的不确定因素需要跟踪我在实际项目中会额外强调两点Epic 和故事之间不是“文件夹”和“文件”的关系而是“叙事的层级关系”。Epic 可以不拆故事也可以挂在迭代里做二者相互独立而风险如果已经发生应当及时转换为缺陷或任务不要留在风险列表里“烂尾”。很多团队把风险建了一堆没人转状态最终风险面板形同虚设。2.2 工作流的三条主线开发、缺陷和其他任务工作流是“问题从创建到完成的路径”。用状态机的视角看它就是一个有向图状态节点、触发动作、可执行动作的角色。Jira 允许每个问题类型独立配置工作流也允许多个类型共用一条这为不同团队留下了定制空间。2.2.1 开发工作流DevelopWorkflow适用于故事和改进。关键路径是“待办 → 开始处理 → 进行中 → 提交测试 → 待测试 → 开始测试 → 测试中 → 测试通过 → 已关闭”另外还有“测试中 → 驳回开发 → 重新打开”和“已关闭 → 恢复 → 待办”两条反向分支。这个流程里有个容易被忽略的设计测试通过后问题直接进入已关闭这一步需要测试人员点击而不是开发自己关。如果开发能关单就会出现“明明没验证却显示已关闭”的假象。2.2.2 缺陷工作流BugWorkflow缺陷流和开发流几乎一致唯一的区别是去掉了“提交评审”环节因为缺陷不需要评审测试就是质检关卡。缺陷流的核心矛盾是“谁说了算”。文档里的约定是测试人员拥有“驳回开发”和“测试通过”的操作权开发只能“开始处理”和“提交测试”这就是测试拥有一票否决权的具体实现。2.2.3 其他任务工作流OtherTaskWorkflow适用于 Epic、风险、任务。这类问题不需要测试验证最后一步是“提交评审 → 待评审 → 评审通过/评审未通过”。执行者是经办人评审者是报告人或主评审人。这里有个实践建议在配置评审人时尽量绑定“项目负责人”这个项目角色而不是某个具体用户。项目负责人换届后工作流不需要跟着改。2.3 项目角色权限边界比功能按钮更先定义Jira 内置五种项目角色Administrators项目管理员、DesignersUI 设计师、Developers开发工程师、Testers测试工程师、Users研发中心全员。我刚接手项目配置时踩过一个真实的坑新员工入职后登录 Jira项目列表是空的因为用户没有进入任何项目角色组而 Jira 的权限模型默认“未授权即不可见”。好在文档里留了一个建议给 jira-users 用户组分配 users 角色这样全员默认可浏览再单独给开发、测试分配操作权限比逐个添加用户省心得多。提示角色和用户组的区别在于用户组是全局的角色是项目级别的。用角色控制“谁能在本项目做什么”用用户组控制“谁能登录 Jira”。2.4 版本与模块发布节奏和问题分派的两条辅助线版本按项目阶段或发布时序创建创建入口在项目面板左侧的“版本”旁的加号。版本之间可以合并但文档特别提醒“版本合并后不能恢复”。我在生产环境操作前会先导出一份版本列表 Excel一旦合并错了至少还有个对照。模块是对问题按功能颗粒度的拆分可以是子系统也可以是一个功能组。添加模块时可以指定“模块负责人”分配问题时经办人会默认带出模块负责人不指定则默认是项目经理。这个机制用好了能省大量人工分派时间但不建议在项目初期就建十几二十个模块——颗粒度太细反而让经办人选项变多创建问题时更难选。3. 从新建问题到验证闭环日常操作怎么落到状态机里3.1 创建问题字段填写的关键不只在于带星号项目管理员或测试人员点击顶部“新建”依次选择项目、问题类型然后按模板填写详情。带星号的是必填项但文档里有一段容易被跳过的提示部分字段页面上没有标星但对流程却是必填的例如故事点、预计完成时间。项目报告人刚接触系统时很难知道哪些字段后面会被统计报表用到所以文档建议结合“QA 问题检查表”判断。以故事类问题为例描述建议按“作为…需要…以便…验收要求”的格式写。这不是形式主义而是因为第四段“验收要求”会直接变成测试人员“测试通过”的判据。没有验收标准的故事测试通过与否只能依赖个人判断。创建完成后报告人可以在问题详情页进行修订和删除操作。这里有一个权限边界只有报告人自己能删除问题其他任何人包括项目管理员都看不到删除按钮。3.2 指定经办人不一定要进问题页再改经办人就是“当前被分配问题的人”。指定经办人有三个入口创建问题页面直接指定、问题查看页面操作、批量编辑。我在实际使用中建议养成“创建时顺手指定”的习惯因为创建后经常忘最后变成一大堆未分配问题堆在“待办”里没人认领。如果使用模块功能经办人字段会自动带出模块负责人不指定模块负责人时默认取项目经理。这个默认值在项目初期比较合理项目大了以后我建议一律显式指定经办人避免问题都堆给项目经理。3.3 处理问题从“已关闭”恢复到“待办”的两个场景经办人登录后从仪表板“分配给我的”小工具或共享筛选器“我未完成的问题”进入工作台。注意这里看到的不是全部项目问题而是与当前用户关联的、状态未结束的问题。点“开始处理”后状态进入“进行中”开发完成后点“提交测试”问题自动流转到“待测试”。三个工作流的状态流转对比当前状态操作结果状态操作人待办开始处理进行中经办人开发进行中提交测试待测试经办人开发待测试开始测试测试中测试人员测试中驳回开发重新打开测试人员测试中测试通过已关闭测试人员重新打开开始处理进行中经办人开发已关闭恢复待办经办人开发这个表里最有争议的是最后一行的“已关闭 → 恢复”。什么情况下需要恢复已关闭的问题我在生产环境遇到过两种一种是验证通过但漏了回归范围发现关联功能被破坏另一种是线上问题反复出现同一张单需要再次进入工作流。恢复不是取消关闭而是让问题重新进入待办从头走一遍流转。如果团队希望“关闭后就不可变”需要在工作流配置里删除这个动作而不是靠口头约束。3.4 问题详情页字段逐项拆解与常见误用问题详情页拿到手先分清右上角三个角色字段报告人问题的创建者经办人当前被分配处理的人责任人造成该问题的人报告人和责任人经常被搞混。报告人是系统里记录在案的创建者责任人则是业务层面“谁该为此负责”的人。不会手动维护责任人的团队默认责任人就是动态的经办人但文档把两者分开是有意为之——当问题多次流转、经办人更换后责任人字段依然保留最初的指认。详情页的操作里有三个容易被误用“分配”指定经办人。任何有权限的人都能操作但建议流程是创建时指定、测试驳回时重新指定而不是处理过程中频繁更换。“移动”更换问题所属的项目和问题类型。移动会要求重新选择工作流状态所以移动后的字段可能出现丢失例如“冲刺”没有复制过去。“复制”会询问是否复制附件和 Sprint values如果不需要沿用旧冲刺信息记得取消勾选。备注模块有三个特性任何人可发表、发表后即所有人可见、只能修改和删除自己的备注。这三个特性意味着备注是“广播”而不是“对话”。要讨论具体实现细节我一般建议放到 Confluence 页面里备注只留结论。附件支持点击添加或拖拽上传开发人员提测时需要附上自测截图或测试地址否则测试人员有权直接驳回。3.5 验证与评审测试人员和评审人的门口关验证发生在问题流转到“待测试”之后。测试人员点击“开始测试”进入“测试中”状态验证不通过时点击“驳回开发”问题回到“重新打开”验证通过则点击“测试通过”问题直接“已关闭”。这里我强烈建议在团队规范里写明驳回理由模板“预期结果 实际结果 复现步骤”三段式。备注栏如果不按模板写驳回信息往往只有一句“不通过”开发需要再花一轮来回才能定位效率损耗非常明显。评审则针对 Epic、风险、任务这类非测试型问题。经办人提交评审后问题流入“待评审”主评审人打开问题页面点击“评审通过”直接关闭或“评审未通过”回到“重新打开”继续处理。4. 面板与迭代让团队节奏从列表变成可视化的协作现场4.1 创建面板不是从零建而是先复制面板是 Jira 里展示问题状态的视图容器。项目管理员和普通用户都能创建面板但创建入口不同项目管理员从项目侧边栏进入普通用户从个人头像下的“面板”菜单进入。我一般不建议从空白面板开始搭。正确做法是先找一个现有面板复制一份再改名字和配置。这样列、泳道、筛选器都继承下来改起来比从零配置快得多。项目启动新迭代时复制上次迭代的面板是目前成本最低的方案。4.2 配置“列”一列可以放多个工作流状态列是看板横向的泳道分区但要注意一个关键点列和工作流状态不是一对一的关系一个列可以聚合多个状态。比如把“进行中”和“待测试”放在同一列因为这两个状态都属于“开发已经动手但还没完成验收”的阶段测试人员扫一眼就知道该盯哪个区域。一个常见的面板列配置{ boardName: 核心交易系统迭代看板, columns: [ { name: 待办, statuses: [待办] }, { name: 开发中, statuses: [进行中, 待测试] }, { name: 测试中, statuses: [测试中] }, { name: 已完成, statuses: [已关闭] } ] }这段 JSON 里的 statuses 数组就是把工作流状态映射到列的配置在面板设置的“列”区域用拖拽方式完成同样效果。配置完成后卡片在列之间移动时Jira 会自动触发对应的状态转换。提示不要把“重新打开”和“待办”放在同一列。重新打开的问题需要测试人员关注回归和待办混在一起会被默认当成“还没开始处理”的新任务。4.3 配置“泳道”按经办人拆比按优先级拆更实用泳道是看板内横向的分组条常见维度有经办人、优先级、组件等。我在多个团队里验证下来的结论是按经办人拆泳道最实用因为每个开发者能直观看到自己名下有哪几张卡、卡在哪一列。按优先级拆则容易造成视觉噪音——高优先级卡片永远只有两三张剩下的低优先级卡片挤在一起既看不清谁在做也看不清进度。泳道配置的入口与列配置在同一页面选择“泳道”标签设置按哪个字段分组即可。项目管理员可以配置泳道默认展开或折叠普通用户只能通过拖拽调整卡片不能自定义泳道。4.4 共享面板比逐个添加用户更省心的权限方案面板创建后默认只有创建者自己可见。要让团队成员看到需要打开面板设置里的“共享”选项按用户组或项目角色授权。共享给项目角色比共享给具体用户好维护因为项目角色会随着项目成员调整自动变化不用每次换人重新配共享。4.5 迭代从创建到关闭的完整动作序列迭代也叫冲刺是敏捷团队按时间盒组织问题的手段。创建迭代的入口在“当前迭代”区域的加号填写名称和时间区间保存即可。迭代创建后处于“未开始”状态需要手动点击“开始迭代”才会把问题纳入统计范围。关闭迭代是另一个容易出问题的点。关闭前要做三件事检查迭代内是否有未完成的问题记录在案把未完成问题拖入下一个迭代或批量移动到待办列表在关闭确认页查看燃尽图最终形态截图留档如果漏了第二步未完成的问题会处于“没有迭代”的游离状态之后的搜索、统计都找不到它们直到有人手动拖入新迭代。5. JQL、自定义筛选器与批量操作处理成百上千个问题的效率手段5.1 从快速搜索到 JQL搜索方式的三个层次Jira 的搜索能力分成三个层次快速搜索在首页右上角输入关键字回车简单但对复杂语义无能为力简单搜索通过点选组合条件适合不熟悉语法的用户高级搜索使用 JQLJira Query Language结构化查询支持函数和自动补全是项目管理员必须掌握的技能。JQL 和普通搜索引擎的区别在于搜索引擎是模糊匹配全文JQL 是结构化条件组合。project 交易系统和文本包含“交易系统”是两种完全不同的语义写错的话返回结果差异巨大。5.2 常用 JQL 语句拆解以下三条是我在缺陷回归和迭代复盘中最常用的 JQLproject 核心交易系统 AND assignee currentUser() AND status 待办 ORDER BY priority DESC, updated DESC这条查询的是当前用户待办的所有问题按优先级从高到低、更新时间从新到旧排列。currentUser()是内置函数会自动替换为当前登录用户在共享给多人时格外好用。sprint 102 AND status changed to (测试中) DURING (startOfDay(-7d), now())sprint 102锁定迭代status changed to (测试中)只统计状态变为“测试中”的问题DURING配合startOfDay(-7d)和now()限定在最近 7 天内的变化适合观察提测密度。issuetype 缺陷 AND resolution 未解决 AND labels not in (不回归)这条用于回归范围评估找到所有未解决的缺陷排除打了“不回归”标签的问题剩下就是标准回归测试范围。JQL 还支持lastLogin、latestReleasedVersion、endOfMonth、membersOf等函数在编写筛选器时可以随时输入字母触发自动补全查看函数签名不用死记硬背。5.3 自定义筛选器让团队共享一套查询口径搜索条件确认无误后点击“保存为筛选器”输入名称和描述完成创建。创建的筛选器可以收藏也可以共享给指定的用户或用户组。我建议把“当前迭代未完成问题”“本周提测清单”“待评审任务”这三个筛选器共享给项目角色大家用同一个入口看数据避免“同一个项目开发看一套数测试看另一套数”的口径不一致问题。5.4 批量操作效率利器同时也是风险源搜索结果左侧会列出匹配的所有问题勾选多个问题后工具栏会弹出一系列批量操作选项。常见的有批量编辑经办人、批量修改状态、批量添加标签、批量关联版本、批量移动问题到其他项目。批量操作节省时间的效果非常直接但有一个必须警惕的坑批量修改状态时如果目标状态所需的必填字段各不相同Jira 会要求补充字段值否则会失败。比如批量把问题从“待办”移动到“测试中”会跳过“提交测试”这个环节自测情况字段为空的记录直接进入测试队列测试人员会因为缺少自测信息而无法验证。# 用 jira-cli 做批量操作前的确认是个好习惯 jira-cli list --jql project 核心交易系统 AND assignee ! currentUser() AND status 待办 --columns key,summary,assignee上面这段命令会在批量操作前先列出所有受影响的问题确认范围无误后再执行真正的批量指令这比直接在界面上勾选更安全。5.5 验证与导出批量操作后如何确认没改错批量操作完成后可以用一个简单的数学关系验证结果总数等于满足条件数加上不满足条件数。先跑一遍变更后的 JQL记录返回数量再跑一条取反条件的查询两者相加应当等于问题总数。搜索结果支持导出为 HTML、XML、RSS、Word 或 Excel。我最常用的是 Excel 导出导出的表格自带全部自定义字段可以用来做离线复核。例如批量指派经办人后导出 Excel 用数据透视表按经办人分组统计数量就能很快发现是否有人的任务量异常过高趁早调配。本文还有配套的精品资源点击获取 Jira实战：工作流、角色权限与JQL查询深度指南
简介Jira作为Atlassian公司主流的项目与任务管理工具广泛应用于软件开发团队的敏捷协作与缺陷跟踪。这份操作说明书定位零基础新手手把手讲解创建任务、权限分配、工作流状态流转、面板配置与迭代管理等核心操作并配有截图辅助尤其适合项目管理员、测试人员和开发工程师快速上手。资源包含1个doc文档压缩包大小6.07MB文档内容从JIRA简介、访问方法、特性到开发/缺陷/其他任务三类工作流再到项目角色、版本模块、问题搜索与批量处理、面板创建与共享、迭代管理等均有覆盖章节结构非常清晰。目前已有531人学习下载便于按目录速查或系统学习是一份可直接对照操作的入门手册。1. 别把 Jira 当 Excel先搞清楚它到底解决什么问题一个 20 人的研发团队如果用 Excel 排期前三周没问题第四周开始就会出现“改了一个状态忘了通知下游”“权限分不清谁能编辑”“版本和迭代对不上账”这三类问题。Jira 这种基于 J2EE 的项目管理系统核心不是给你一张更漂亮的表格而是把需求、任务、缺陷、流程审批放进同一套带状态机的数据模型里让“谁在什么时间该干什么”变成一条可追踪、可追溯、可统计的流水线。很多 jira 使用教程上来就教点按钮反倒把最关键的“状态机”和“角色权限”放在了最后这正好是这篇内容想纠正的地方。适合第一次接手项目配置的项目管理员也适合想知道“流程为什么要这么设计”的开发、测试和产品。即使已经用了一两年 Jira后面关于 JQL 函数、筛选器共享和批量操作的边界问题应该也还有信息量。2. 问题类型、工作流与项目角色搭建 Jira 前必须先想清楚的三件事2.1 问题类型体系从 Epic 到缺陷的层级关系Jira 里最小、最重要的单位叫“问题”。Epic、故事、改进、任务、缺陷、风险本质上都是以问题形式提交到系统中的一条记录。问题类型决定了这条记录走哪套工作流、显示哪些字段、谁能创建。下表是这版手册定义的最常用类型及创建权限问题类型创建人员说明Epic史诗项目管理员大型用户故事可拆成故事/任务可跨多个迭代传递故事项目管理员用户故事描述一个从用户视角出发的功能需求改进项目管理员对现有功能或任务的增强不是新功能任务项目管理员非开发类工作设计、管理、文档编写、实施部署缺陷测试人员损害或阻止产品功能的问题用 BugWorkflow 管理风险项目管理员项目过程中存在的不确定因素需要跟踪我在实际项目中会额外强调两点Epic 和故事之间不是“文件夹”和“文件”的关系而是“叙事的层级关系”。Epic 可以不拆故事也可以挂在迭代里做二者相互独立而风险如果已经发生应当及时转换为缺陷或任务不要留在风险列表里“烂尾”。很多团队把风险建了一堆没人转状态最终风险面板形同虚设。2.2 工作流的三条主线开发、缺陷和其他任务工作流是“问题从创建到完成的路径”。用状态机的视角看它就是一个有向图状态节点、触发动作、可执行动作的角色。Jira 允许每个问题类型独立配置工作流也允许多个类型共用一条这为不同团队留下了定制空间。2.2.1 开发工作流DevelopWorkflow适用于故事和改进。关键路径是“待办 → 开始处理 → 进行中 → 提交测试 → 待测试 → 开始测试 → 测试中 → 测试通过 → 已关闭”另外还有“测试中 → 驳回开发 → 重新打开”和“已关闭 → 恢复 → 待办”两条反向分支。这个流程里有个容易被忽略的设计测试通过后问题直接进入已关闭这一步需要测试人员点击而不是开发自己关。如果开发能关单就会出现“明明没验证却显示已关闭”的假象。2.2.2 缺陷工作流BugWorkflow缺陷流和开发流几乎一致唯一的区别是去掉了“提交评审”环节因为缺陷不需要评审测试就是质检关卡。缺陷流的核心矛盾是“谁说了算”。文档里的约定是测试人员拥有“驳回开发”和“测试通过”的操作权开发只能“开始处理”和“提交测试”这就是测试拥有一票否决权的具体实现。2.2.3 其他任务工作流OtherTaskWorkflow适用于 Epic、风险、任务。这类问题不需要测试验证最后一步是“提交评审 → 待评审 → 评审通过/评审未通过”。执行者是经办人评审者是报告人或主评审人。这里有个实践建议在配置评审人时尽量绑定“项目负责人”这个项目角色而不是某个具体用户。项目负责人换届后工作流不需要跟着改。2.3 项目角色权限边界比功能按钮更先定义Jira 内置五种项目角色Administrators项目管理员、DesignersUI 设计师、Developers开发工程师、Testers测试工程师、Users研发中心全员。我刚接手项目配置时踩过一个真实的坑新员工入职后登录 Jira项目列表是空的因为用户没有进入任何项目角色组而 Jira 的权限模型默认“未授权即不可见”。好在文档里留了一个建议给 jira-users 用户组分配 users 角色这样全员默认可浏览再单独给开发、测试分配操作权限比逐个添加用户省心得多。提示角色和用户组的区别在于用户组是全局的角色是项目级别的。用角色控制“谁能在本项目做什么”用用户组控制“谁能登录 Jira”。2.4 版本与模块发布节奏和问题分派的两条辅助线版本按项目阶段或发布时序创建创建入口在项目面板左侧的“版本”旁的加号。版本之间可以合并但文档特别提醒“版本合并后不能恢复”。我在生产环境操作前会先导出一份版本列表 Excel一旦合并错了至少还有个对照。模块是对问题按功能颗粒度的拆分可以是子系统也可以是一个功能组。添加模块时可以指定“模块负责人”分配问题时经办人会默认带出模块负责人不指定则默认是项目经理。这个机制用好了能省大量人工分派时间但不建议在项目初期就建十几二十个模块——颗粒度太细反而让经办人选项变多创建问题时更难选。3. 从新建问题到验证闭环日常操作怎么落到状态机里3.1 创建问题字段填写的关键不只在于带星号项目管理员或测试人员点击顶部“新建”依次选择项目、问题类型然后按模板填写详情。带星号的是必填项但文档里有一段容易被跳过的提示部分字段页面上没有标星但对流程却是必填的例如故事点、预计完成时间。项目报告人刚接触系统时很难知道哪些字段后面会被统计报表用到所以文档建议结合“QA 问题检查表”判断。以故事类问题为例描述建议按“作为…需要…以便…验收要求”的格式写。这不是形式主义而是因为第四段“验收要求”会直接变成测试人员“测试通过”的判据。没有验收标准的故事测试通过与否只能依赖个人判断。创建完成后报告人可以在问题详情页进行修订和删除操作。这里有一个权限边界只有报告人自己能删除问题其他任何人包括项目管理员都看不到删除按钮。3.2 指定经办人不一定要进问题页再改经办人就是“当前被分配问题的人”。指定经办人有三个入口创建问题页面直接指定、问题查看页面操作、批量编辑。我在实际使用中建议养成“创建时顺手指定”的习惯因为创建后经常忘最后变成一大堆未分配问题堆在“待办”里没人认领。如果使用模块功能经办人字段会自动带出模块负责人不指定模块负责人时默认取项目经理。这个默认值在项目初期比较合理项目大了以后我建议一律显式指定经办人避免问题都堆给项目经理。3.3 处理问题从“已关闭”恢复到“待办”的两个场景经办人登录后从仪表板“分配给我的”小工具或共享筛选器“我未完成的问题”进入工作台。注意这里看到的不是全部项目问题而是与当前用户关联的、状态未结束的问题。点“开始处理”后状态进入“进行中”开发完成后点“提交测试”问题自动流转到“待测试”。三个工作流的状态流转对比当前状态操作结果状态操作人待办开始处理进行中经办人开发进行中提交测试待测试经办人开发待测试开始测试测试中测试人员测试中驳回开发重新打开测试人员测试中测试通过已关闭测试人员重新打开开始处理进行中经办人开发已关闭恢复待办经办人开发这个表里最有争议的是最后一行的“已关闭 → 恢复”。什么情况下需要恢复已关闭的问题我在生产环境遇到过两种一种是验证通过但漏了回归范围发现关联功能被破坏另一种是线上问题反复出现同一张单需要再次进入工作流。恢复不是取消关闭而是让问题重新进入待办从头走一遍流转。如果团队希望“关闭后就不可变”需要在工作流配置里删除这个动作而不是靠口头约束。3.4 问题详情页字段逐项拆解与常见误用问题详情页拿到手先分清右上角三个角色字段报告人问题的创建者经办人当前被分配处理的人责任人造成该问题的人报告人和责任人经常被搞混。报告人是系统里记录在案的创建者责任人则是业务层面“谁该为此负责”的人。不会手动维护责任人的团队默认责任人就是动态的经办人但文档把两者分开是有意为之——当问题多次流转、经办人更换后责任人字段依然保留最初的指认。详情页的操作里有三个容易被误用“分配”指定经办人。任何有权限的人都能操作但建议流程是创建时指定、测试驳回时重新指定而不是处理过程中频繁更换。“移动”更换问题所属的项目和问题类型。移动会要求重新选择工作流状态所以移动后的字段可能出现丢失例如“冲刺”没有复制过去。“复制”会询问是否复制附件和 Sprint values如果不需要沿用旧冲刺信息记得取消勾选。备注模块有三个特性任何人可发表、发表后即所有人可见、只能修改和删除自己的备注。这三个特性意味着备注是“广播”而不是“对话”。要讨论具体实现细节我一般建议放到 Confluence 页面里备注只留结论。附件支持点击添加或拖拽上传开发人员提测时需要附上自测截图或测试地址否则测试人员有权直接驳回。3.5 验证与评审测试人员和评审人的门口关验证发生在问题流转到“待测试”之后。测试人员点击“开始测试”进入“测试中”状态验证不通过时点击“驳回开发”问题回到“重新打开”验证通过则点击“测试通过”问题直接“已关闭”。这里我强烈建议在团队规范里写明驳回理由模板“预期结果 实际结果 复现步骤”三段式。备注栏如果不按模板写驳回信息往往只有一句“不通过”开发需要再花一轮来回才能定位效率损耗非常明显。评审则针对 Epic、风险、任务这类非测试型问题。经办人提交评审后问题流入“待评审”主评审人打开问题页面点击“评审通过”直接关闭或“评审未通过”回到“重新打开”继续处理。4. 面板与迭代让团队节奏从列表变成可视化的协作现场4.1 创建面板不是从零建而是先复制面板是 Jira 里展示问题状态的视图容器。项目管理员和普通用户都能创建面板但创建入口不同项目管理员从项目侧边栏进入普通用户从个人头像下的“面板”菜单进入。我一般不建议从空白面板开始搭。正确做法是先找一个现有面板复制一份再改名字和配置。这样列、泳道、筛选器都继承下来改起来比从零配置快得多。项目启动新迭代时复制上次迭代的面板是目前成本最低的方案。4.2 配置“列”一列可以放多个工作流状态列是看板横向的泳道分区但要注意一个关键点列和工作流状态不是一对一的关系一个列可以聚合多个状态。比如把“进行中”和“待测试”放在同一列因为这两个状态都属于“开发已经动手但还没完成验收”的阶段测试人员扫一眼就知道该盯哪个区域。一个常见的面板列配置{ boardName: 核心交易系统迭代看板, columns: [ { name: 待办, statuses: [待办] }, { name: 开发中, statuses: [进行中, 待测试] }, { name: 测试中, statuses: [测试中] }, { name: 已完成, statuses: [已关闭] } ] }这段 JSON 里的 statuses 数组就是把工作流状态映射到列的配置在面板设置的“列”区域用拖拽方式完成同样效果。配置完成后卡片在列之间移动时Jira 会自动触发对应的状态转换。提示不要把“重新打开”和“待办”放在同一列。重新打开的问题需要测试人员关注回归和待办混在一起会被默认当成“还没开始处理”的新任务。4.3 配置“泳道”按经办人拆比按优先级拆更实用泳道是看板内横向的分组条常见维度有经办人、优先级、组件等。我在多个团队里验证下来的结论是按经办人拆泳道最实用因为每个开发者能直观看到自己名下有哪几张卡、卡在哪一列。按优先级拆则容易造成视觉噪音——高优先级卡片永远只有两三张剩下的低优先级卡片挤在一起既看不清谁在做也看不清进度。泳道配置的入口与列配置在同一页面选择“泳道”标签设置按哪个字段分组即可。项目管理员可以配置泳道默认展开或折叠普通用户只能通过拖拽调整卡片不能自定义泳道。4.4 共享面板比逐个添加用户更省心的权限方案面板创建后默认只有创建者自己可见。要让团队成员看到需要打开面板设置里的“共享”选项按用户组或项目角色授权。共享给项目角色比共享给具体用户好维护因为项目角色会随着项目成员调整自动变化不用每次换人重新配共享。4.5 迭代从创建到关闭的完整动作序列迭代也叫冲刺是敏捷团队按时间盒组织问题的手段。创建迭代的入口在“当前迭代”区域的加号填写名称和时间区间保存即可。迭代创建后处于“未开始”状态需要手动点击“开始迭代”才会把问题纳入统计范围。关闭迭代是另一个容易出问题的点。关闭前要做三件事检查迭代内是否有未完成的问题记录在案把未完成问题拖入下一个迭代或批量移动到待办列表在关闭确认页查看燃尽图最终形态截图留档如果漏了第二步未完成的问题会处于“没有迭代”的游离状态之后的搜索、统计都找不到它们直到有人手动拖入新迭代。5. JQL、自定义筛选器与批量操作处理成百上千个问题的效率手段5.1 从快速搜索到 JQL搜索方式的三个层次Jira 的搜索能力分成三个层次快速搜索在首页右上角输入关键字回车简单但对复杂语义无能为力简单搜索通过点选组合条件适合不熟悉语法的用户高级搜索使用 JQLJira Query Language结构化查询支持函数和自动补全是项目管理员必须掌握的技能。JQL 和普通搜索引擎的区别在于搜索引擎是模糊匹配全文JQL 是结构化条件组合。project 交易系统和文本包含“交易系统”是两种完全不同的语义写错的话返回结果差异巨大。5.2 常用 JQL 语句拆解以下三条是我在缺陷回归和迭代复盘中最常用的 JQLproject 核心交易系统 AND assignee currentUser() AND status 待办 ORDER BY priority DESC, updated DESC这条查询的是当前用户待办的所有问题按优先级从高到低、更新时间从新到旧排列。currentUser()是内置函数会自动替换为当前登录用户在共享给多人时格外好用。sprint 102 AND status changed to (测试中) DURING (startOfDay(-7d), now())sprint 102锁定迭代status changed to (测试中)只统计状态变为“测试中”的问题DURING配合startOfDay(-7d)和now()限定在最近 7 天内的变化适合观察提测密度。issuetype 缺陷 AND resolution 未解决 AND labels not in (不回归)这条用于回归范围评估找到所有未解决的缺陷排除打了“不回归”标签的问题剩下就是标准回归测试范围。JQL 还支持lastLogin、latestReleasedVersion、endOfMonth、membersOf等函数在编写筛选器时可以随时输入字母触发自动补全查看函数签名不用死记硬背。5.3 自定义筛选器让团队共享一套查询口径搜索条件确认无误后点击“保存为筛选器”输入名称和描述完成创建。创建的筛选器可以收藏也可以共享给指定的用户或用户组。我建议把“当前迭代未完成问题”“本周提测清单”“待评审任务”这三个筛选器共享给项目角色大家用同一个入口看数据避免“同一个项目开发看一套数测试看另一套数”的口径不一致问题。5.4 批量操作效率利器同时也是风险源搜索结果左侧会列出匹配的所有问题勾选多个问题后工具栏会弹出一系列批量操作选项。常见的有批量编辑经办人、批量修改状态、批量添加标签、批量关联版本、批量移动问题到其他项目。批量操作节省时间的效果非常直接但有一个必须警惕的坑批量修改状态时如果目标状态所需的必填字段各不相同Jira 会要求补充字段值否则会失败。比如批量把问题从“待办”移动到“测试中”会跳过“提交测试”这个环节自测情况字段为空的记录直接进入测试队列测试人员会因为缺少自测信息而无法验证。# 用 jira-cli 做批量操作前的确认是个好习惯 jira-cli list --jql project 核心交易系统 AND assignee ! currentUser() AND status 待办 --columns key,summary,assignee上面这段命令会在批量操作前先列出所有受影响的问题确认范围无误后再执行真正的批量指令这比直接在界面上勾选更安全。5.5 验证与导出批量操作后如何确认没改错批量操作完成后可以用一个简单的数学关系验证结果总数等于满足条件数加上不满足条件数。先跑一遍变更后的 JQL记录返回数量再跑一条取反条件的查询两者相加应当等于问题总数。搜索结果支持导出为 HTML、XML、RSS、Word 或 Excel。我最常用的是 Excel 导出导出的表格自带全部自定义字段可以用来做离线复核。例如批量指派经办人后导出 Excel 用数据透视表按经办人分组统计数量就能很快发现是否有人的任务量异常过高趁早调配。本文还有配套的精品资源点击获取