我们仍然以这张图作为开头,之前已经讲了,Project创建、问题相关、字段相关、界面相关、工作流相关的内容。大部分的内容已经完成,剩余就是权限相关与问题链接相关,其他一些相对比较不重要的配置。

权限配置

权限控制的是数据的查询和操作权限,我们来看一下概览
权限配置

这里分为如下几块(主要讲关键点):

  • 项目权限:
    • 管理权限:就是点击项目左侧边栏的设置,一般收到管理员手中。
    • 浏览权限:目的用来隔离Jira数据。我的做法是建立不同的用户组,在浏览权限使用用户组隔离。
  • 问题权限:
    • 可分配用户:经办人等用户相关组件可以选择的人员范围,仍然建议以用户组设置。
    • 删除问题:删除权限建议是回收到管理员,正常场景下是不允许用户删除任何数据。例如 Bug之类的,如果放开删除权限有可能造成研发和测试之间的争议。
    • 编辑问题:这里限制编辑的权限主要是防止随意篡改,特别是类似子任务这种排期随意变更可能会造成计划混乱。
    • 移动问题:变更问题归属项目,可以放给Leader。
    • 转换问题:例如Bug改为Story,这里还是防止随意篡改的问题,所以建议还是放给Leader。
  • 决策人和关注人权限:无需变更
  • 评论权限:删除权限控制,其他全员
  • 附件权限:自己的数据自己可以控制,管理员可以操作其他人数据
  • 时间跟踪权限:自己的数据自己可以控制,管理员可以操作其他人数据

问题链接配置

问题链接可以建立不同问题直接的关联关系
问题链接

系统自带Blocks,Cloners,Defect,Duplicate,Relates这几种关联,有些插件也会建立一些链接。
我们建立的关联目的,一般是用于在工作流或者管理流程中的规范制定。

解决方式配置

解决方式

解决方式我建议不要太多,防止引起执行人员选择过多会混淆。

其他

通知方案我们使用的是默认,一般主要还是用于邮件通知,不用过多设置。
优先级也是默认五级,也不用过多设置。
我们之前的配置中,大量使用到了用户组,我也讲一下用户组的划分原则。

用户组

用户组可以分为几种类型,使用前缀区分:

  • 产品线(BU)
    • 例:OA产品线(BU-OA)
  • 角色(RO)多层结构,层级清楚
    • 例:研发(RO-DEV),后端研发(RO-DEV-BACKEND),前端研发(RO-DEV-FRONTEND),H5前端研发(RO-DEV-FRONTEND-H5),APP前端研发(RO-DEV-FRONTEND-NATIVE)
  • 组织架构(ORG)
    • 例:组长(ORG-LEADER),组员(ORG-MEMBER)

网络钩子

网络钩子是一个很好用的功能,可以用于与现有系统的结合,比如OA或者说工作管理,直接看设置就好。
网络钩子

总结

这里基本上就是单个Project的配置的全部内容,写的目的主要是为了记录下一个空白项目应该如何设置Jira当中最核心的“问题(Issue)”这个概念。

在之前的一个系列中,主要是介绍了整体Jira配合研发管理的思想进行完整的规划和设计。
本次的三篇系列,主要是介绍了核心概念问题的相关配置方法。朋友建议再写一篇关于Jira的安装配置相关的操作手册,这个正在计划中。

但是Jira始终还是一个工具,应当是我们实际组织架构和管理需求的体现。文章中的配置只是根据当前所在团队制定的,不同的团队管理方法不同,应当是根据文章中提供的方法进行实际的调整。

永远都应该是工具适应制度,而不是根据工具来制定制度。

版权声明:本文为pluto4596原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/pluto4596/p/12455932.html