企业官网建设流程全解析

简介：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 和故事之间不是“文件夹”和“文件”的关系，而是“叙事的层级关系”。Epic 可以不拆，故事也可以挂在迭代里做，二者相互独立；而风险如果已经发生，应当及时转换为缺陷或任务，不要留在风险列表里“烂尾”。很多团队把风险建了一堆，没人转状态，最终风险面板形同虚设。

2.2 工作流的三条主线：开发、缺陷和其他任务

工作流是“问题从创建到完成的路径”。用状态机的视角看，它就是一个有向图：状态节点、触发动作、可执行动作的角色。Jira 允许每个问题类型独立配置工作流，也允许多个类型共用一条，这为不同团队留下了定制空间。

2.2.1 开发工作流（DevelopWorkflow）

适用于故事和改进。关键路径是“待办 → 开始处理 → 进行中 → 提交测试 → 待测试 → 开始测试 → 测试中 → 测试通过 → 已关闭”，另外还有“测试中 → 驳回开发 → 重新打开”和“已关闭 → 恢复 → 待办”两条反向分支。这个流程里有个容易被忽略的设计：测试通过后问题直接进入已关闭，这一步需要测试人员点击，而不是开发自己关。如果开发能关单，就会出现“明明没验证却显示已关闭”的假象。

2.2.2 缺陷工作流（BugWorkflow）

缺陷流和开发流几乎一致，唯一的区别是去掉了“提交评审”环节，因为缺陷不需要评审，测试就是质检关卡。缺陷流的核心矛盾是“谁说了算”。文档里的约定是测试人员拥有“驳回开发”和“测试通过”的操作权，开发只能“开始处理”和“提交测试”，这就是测试拥有一票否决权的具体实现。

2.2.3 其他任务工作流（OtherTaskWorkflow）

适用于 Epic、风险、任务。这类问题不需要测试验证，最后一步是“提交评审 → 待评审 → 评审通过/评审未通过”。执行者是经办人，评审者是报告人或主评审人。这里有个实践建议：在配置评审人时，尽量绑定“项目负责人”这个项目角色，而不是某个具体用户。项目负责人换届后，工作流不需要跟着改。

2.3 项目角色：权限边界比功能按钮更先定义

Jira 内置五种项目角色：Administrators（项目管理员）、Designers（UI 设计师）、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 迭代：从创建到关闭的完整动作序列

迭代也叫冲刺，是敏捷团队按时间盒组织问题的手段。创建迭代的入口在“当前迭代”区域的加号，填写名称和时间区间保存即可。迭代创建后处于“未开始”状态，需要手动点击“开始迭代”才会把问题纳入统计范围。

关闭迭代是另一个容易出问题的点。关闭前要做三件事：

1. 检查迭代内是否有未完成的问题，记录在案
2. 把未完成问题拖入下一个迭代，或批量移动到待办列表
3. 在关闭确认页查看燃尽图最终形态，截图留档

如果漏了第二步，未完成的问题会处于“没有迭代”的游离状态，之后的搜索、统计都找不到它们，直到有人手动拖入新迭代。

5. JQL、自定义筛选器与批量操作：处理成百上千个问题的效率手段

5.1 从快速搜索到 JQL：搜索方式的三个层次

Jira 的搜索能力分成三个层次：快速搜索在首页右上角，输入关键字回车，简单但对复杂语义无能为力；简单搜索通过点选组合条件，适合不熟悉语法的用户；高级搜索使用 JQL（Jira Query Language）结构化查询，支持函数和自动补全，是项目管理员必须掌握的技能。

JQL 和普通搜索引擎的区别在于：搜索引擎是模糊匹配全文，JQL 是结构化条件组合。project = "交易系统"和文本包含“交易系统”是两种完全不同的语义，写错的话返回结果差异巨大。

5.2 常用 JQL 语句拆解

以下三条是我在缺陷回归和迭代复盘中最常用的 JQL：

project = "核心交易系统" 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 用数据透视表按经办人分组统计数量，就能很快发现是否有人的任务量异常过高，趁早调配。

本文还有配套的精品资源，点击获取