📚 课程目录第2章 Jira核心对象建模

2. Jira核心对象建模

在Jira中，真正决定“系统能不能用、好不好用”的，不是界面上的按钮数量，而是六个核心对象之间的建模关系：项目（Project）承载业务边界，问题（Issue）承载可追踪的工作项，工作流（Workflow）定义状态流转，字段（Field）承载信息，屏幕（Screen）决定字段在哪个操作中出现，权限方案（Permission Scheme）决定谁能做什么。理解它们的关系，才能用最小配置搭出可运行的敏捷研发流程。

一、六个对象的分工与依赖关系

可以把Jira建模理解为一条“配置链”：项目是容器，问题类型是容器内的分类，工作流是问题的生命周期，字段是问题的属性，屏幕是字段的呈现位置，权限方案是操作的门禁。它们不是并列关系，而是层层引用：

项目引用问题类型方案、工作流方案、字段配置方案、屏幕方案和权限方案；
问题类型决定该问题走哪条工作流、用哪套字段配置和屏幕；
工作流的每个转换（Transition）可以绑定屏幕，屏幕里放字段；
字段必须先加入字段配置，再放入屏幕，才会在创建或编辑时出现；
权限方案独立于上述对象，按“项目角色”授予“浏览项目、创建问题、编辑问题、转换问题”等权限。

这里最容易踩的坑是：字段建好了、屏幕也配了，但字段配置里没放，结果字段在问题上根本不显示；或者屏幕放了字段，但权限方案没给“编辑问题”，用户看得到却改不了。因此建模顺序建议是：先定问题类型与工作流，再定字段与屏幕，最后配权限方案，并统一挂到项目上。

二、最小可用配置的落地顺序

“最小可用”不是功能最少，而是刚好支撑一条完整研发闭环：需求能录入、能排期、能流转、能验收、能追溯。以“PAY 支付平台”为例，推荐按以下顺序配置，避免反复返工。

第一步：建项目并选模板。在 Jira 中创建项目时选择“Scrum 软件开发”模板，系统会自动生成故事、任务、缺陷、子任务等问题类型，以及一套默认工作流和屏幕方案。这一步的价值是拿到一套可运行的基线，而不是从零搭建。

第二步：确认问题类型。敏捷研发最小集合是：故事（Story）承载用户需求，任务（Task）承载技术工作，缺陷（Bug）承载质量问题，子任务（Sub-task）拆分执行。若团队有“技术债”诉求，可增加“技术债”类型，但不要一开始就建十几个类型，否则工作流和屏幕会成倍复杂。

第三步：设计工作流。最小可用工作流建议为：待办（To Do）→ 进行中（In Progress）→ 待评审（In Review）→ 完成（Done），并增加一条从“进行中”到“阻塞（Blocked）”再回到“进行中”的分支。每个转换可配置条件，例如“只有经办人才能从进行中转到待评审”，以及后置动作“转到待评审时自动填写评审人字段”。

第四步：定义字段与字段配置。敏捷场景最小字段集：故事点（Story Points）、优先级（Priority）、迭代（Sprint）、缺陷严重度（Severity）。自定义字段创建后，必须加入对应的字段配置（Field Configuration），否则不会出现在问题上。字段配置还决定字段是否必填、是否只读。

第五步：配置屏幕。屏幕分三类：创建屏只放必填字段（如摘要、描述、优先级、故事点），减少录入负担；编辑屏放可修改字段；查看屏放全部展示字段。工作流的每个转换可以绑定“转换屏”，例如“完成”转换时弹出“验收结论”字段，强制填写。

第六步：配置权限方案。最小权限模型按项目角色划分：管理员拥有管理项目权限；开发人员拥有浏览、创建、编辑、转换、分配问题权限；测试人员拥有浏览、创建缺陷、转换缺陷权限；干系人只有浏览和评论权限。权限方案通过“项目角色”授权，而不是直接给个人，这样人员变动时只需调整角色成员。

配置顺序口诀：项目定边界 → 类型定分类 → 工作流定流转 → 字段定信息 → 屏幕定呈现 → 权限定操作。顺序颠倒会导致字段不显示、转换不可用、权限冲突等返工。

三、常见配置冲突与判断依据

配置完成后，如何判断“最小可用”是否达标？可以用三个检查点：

检查点	判断依据	常见问题
字段可见性	创建问题时能看到故事点、优先级、迭代字段	字段未加入字段配置或未放入创建屏
工作流可流转	经办人能把问题从“进行中”转到“待评审”	转换条件限制过严或权限方案缺少“转换问题”
权限可操作	开发人员能编辑问题，干系人只能浏览和评论	权限直接授予个人而非项目角色，人员变动后失效

还有一个高频冲突：字段配置与屏幕不一致。例如“故事点”字段已加入字段配置并设为必填，但创建屏里没有放它，用户创建问题时不会看到该字段，保存时却因必填校验失败而报错。解决方法是：字段配置负责“字段是否存在、是否必填”，屏幕负责“字段在哪个界面出现”，两者必须同时配置。

另一个冲突是工作流方案与问题类型不匹配。如果“缺陷”和“故事”共用一条工作流，缺陷可能需要“复现→修复→验证→关闭”的独立状态，而故事需要“待办→进行中→完成”。此时应使用工作流方案按问题类型分配不同工作流，而不是强行合并。

注意：不要直接修改 Jira 默认方案（Default Workflow Scheme、Default Screen Scheme 等），因为默认方案被多个项目共享，修改会影响其他项目。正确做法是复制默认方案，重命名为“PAY-工作流方案”“PAY-屏幕方案”，再挂到目标项目上。

四、最小可用配置示例清单

以下清单可直接作为新项目建模的检查表，字段和状态可按团队实际调整：

项目：PAY（支付平台）
问题类型：故事 / 任务 / 缺陷 / 子任务
工作流：待办 → 进行中 → 待评审 → 完成
        进行中 ⇄ 阻塞
字段：故事点（数值）、优先级（下拉）、迭代（Sprint）、缺陷严重度（下拉）
字段配置：故事点必填、优先级必填、迭代非必填
屏幕：创建屏（摘要/描述/优先级/故事点）
      编辑屏（全部字段）
      查看屏（全部字段 + 评论）
权限方案：
  管理员   → 管理项目、浏览、创建、编辑、转换、分配
  开发人员 → 浏览、创建、编辑、转换、分配
  测试人员 → 浏览、创建缺陷、转换缺陷、评论
  干系人   → 浏览、评论

这套配置的核心思想是：用最少的对象覆盖最完整的闭环。项目提供边界，问题承载工作，工作流驱动流转，字段承载信息，屏幕控制呈现，权限控制操作。六者关系清晰后，后续无论是增加“技术债”问题类型、增加“验收”状态，还是接入看板与报表，都只是在既有骨架上扩展，而不是推倒重来。