七爪源码：在 Jira 中建立有效的层次结构

配置 Jira 以支持问题类型的层次结构

概述

Jira 在 Scrum 团队级别的最低配置下工作得很好，但技术项目经理和产品经理更需要将团队合作整合到更大的工作中。以下是一些成功配置层次结构的方法。

Jira 中的层次结构是什么？

Jira 层次结构只是问题之间的父子关系。 Epics 通常是故事组，但 Epics 可能会被分组为更大的计划。在不增加管理问题的用户的开销的情况下，定义提供价值的层次结构的深度很重要。

在 Epic 及以下的所有情况下，不应更改层次结构。只有当 Epics 有较大的工作需要跟踪时，才应在 Epic 之上引入层次结构中的级别。

这些高层的主要受众是项目经理、工程经理、主管和高管。因此，它不应影响工程团队的工作方式。个别工程师和 Scrum 团队需要花时间开发软件，不应该为了让管理层对世界有一个清晰的认识而增加工作。这些应该以对工程师透明的方式实施。在配置不佳的环境中工作的工程师的一个常见抱怨是，自上而下的任务增加了他们在工具上花费的时间。

示例问题类型层次结构：

最终，业务需求将推动实际的层次结构，但概念是通用的。

结构与高级路线图（组合）

开箱即用，Jira 不能很好地呈现层次结构。有几个插件具有这些功能，我想到了两个：结构和高级路线图（组合）

结构

优点：高度可配置和灵活。支持所有 Jira 链接类型。具有更好依赖管理的额外甘特图插件。支持大量问题。能够直接在结构中编辑所有字段。可以根据层次结构从任何项目中动态提取问题。

缺点：因为它是高度可配置的，所以学习曲线可能很高。这可以通过创建用户不需要单独配置自己的结构的模板来缓解。

高级路线图

优点：适合小型团队。固定的、易于理解的层次结构。

缺点：限制可以在单个计划中的问题和项目。固定的层次结构限制了灵活性。内置字段与标准 Jira 字段的操作方式不同，有些与其他插件不兼容。难以配置跨项目的动态问题。

自动化

自动化对于管理层次结构至关重要。随着级别数量的增加，需要更新多个问题或汇总对父问题的更改。如果人们认为管理层次结构中的所有这些级别会产生更多开销，那么采用率就会很低。

层次结构将从中受益的自动化类型：

状态汇总

设计工作流程以根据其子级自动更新父级问题的状态。例如，当所有史诗都关闭时，关闭父倡议。这减少了手动更新父问题状态的开销。

估计汇总

与汇总状态类似，记录的估计和工作量可以汇总以查看程序是如何从其原始范围烧毁的。

层次报告

实施层次结构的主要原因之一是分别报告不同的级别。要手动报告属于多个层次的层次结构的所有问题，将需要很少有人理解的复杂 JQL。

示例：有一个层次结构，其级别为 Portfolio、Program、Initiative 和 Epic。要查看特定程序的所有问题，需要编写一个查询，查看该程序下的所有问题，这不是微不足道的。一些插件，如 Scriptrunner，甚至 Structure 和 Advanced Roadmap 的内置查询功能都可以提供帮助，但用户仍需要成为 Jira 专家才能编译这些查询。

但是，如果构建自动化以将上层问题摘要放入其后代的单个、不可变字段中，则报告可能变得轻而易举。

示例：对于与上面示例相同的层次结构，在其后代中有一个“程序”字段，我们在链接到该层次结构时自动填充问题。要查看程序的所有 Epic，查询只需变为 type = Epic 和 Program = “Program A”

结论

使用层次结构可能会很棘手，但通过正确的架构和自动化，它对于企业规模的公司或遵循规模化敏捷框架 (SAFe) 的公司来说可能非常有价值。无论层次结构是用于跨组织对问题进行分组还是用于跟踪大型产品/程序，重要的是要注意它为使用该工具的团队带来的任何开销。

最终结果对各个工程团队是透明的，但现在项目经理拥有了了解其项目健康状况所需的结构。