标签：建立   计划   tor   也会   结合   工具   需求   分配   邮件通知   

我们仍然以这张图作为开头，之前已经讲了，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始终还是一个工具，应当是我们实际组织架构和管理需求的体现。文章中的配置只是根据当前所在团队制定的，不同的团队管理方法不同，应当是根据文章中提供的方法进行实际的调整。

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

Jira项目管理配置指南（三）—— 其他配置与总结

标签：建立   计划   tor   也会   结合   工具   需求   分配   邮件通知   

原文地址：https://www.cnblogs.com/pluto4596/p/12455932.html