七爪源码：如何让工程师喜欢您的 Jira 实例

有些人仍然会讨厌它

什么是吉拉？

Jira 是一个问题跟踪和项目管理平台，使团队能够跟踪他们的工作并深入了解他们的工作是如何完成的。重要的是它是一个平台。它促进了软件开发和业务流程。如果这些流程定义不明确，则可以将其配置为完美地实施这些定义不明确的流程。这对工具的影响会很差，因为那是流程的接口。

但是，有一些方法可以控制配置，以免对工程师产生不必要的开销，同时仍提供数据以做出业务决策并创建优质产品。

我应该注意，我指的是 Jira 的数据中心（自托管）版本，而不是云 (SaaS) 版本。虽然有相似之处，但两者遇到的问题可能大不相同。

关于 Jira 的常见投诉

太慢了

问题：

• 有些动作可以在几秒钟内完成。屏幕可能需要一些时间来加载。这可能会减慢 sprint 计划、关闭任务等。

解决方案：

• 评估实例的硬件和范围。这可能就像在问题上扔硬件一样简单。项目、问题、自定义字段等的数量可以对此做出贡献。
• 考虑按计划归档问题。即你真的需要能够看到一年多前完成的故事吗？
• 正确实施自定义字段上下文，以便不会为不会使用它们的项目索引字段。
• 评估工作流程转换和自动化。过度使用后期功能会减慢转换问题的速度。考虑将它们转移到项目自动化或其他方法。

用户界面很笨拙

问题：

• 诚然，整个工具的 UI 不一致，这可能会造成混淆。一些操作，如在项目/问题类型之间移动任务或批量更改可能需要几个屏幕才能完成。在工具的一个部分打开问题与在另一部分打开它看起来会有所不同。

解决方案：

• 标准化类似项目的配置。如果项目之间的配置不同，则在项目之间移动问题将触发映射过程。如果移动问题将成为一个常见过程，那么让项目共享相同的配置将加快此过程并消除映射练习的需要。然而，在我看来，过于花哨的 UI 会导致其他问题。

太混乱了

问题：

• 工作流程太复杂，配置方式差异太大。

解决方案：

• 这与 Jira 关系不大，很可能是由于工具配置不当和/或自上而下管理造成的。
• 保持配置尽可能简单，并意识到可能会增加工程师工作量的任何开销。

问题：

• 自定义字段过多

解决方案：

• 添加治理以控制添加哪些字段，并对为什么无法将 100 个自定义字段添加到单个项目设置预期。

太可定制了

问题：

• Jira 作为一个平台，可以完全从头开始配置。这既是它的优点之一，也是它最大的缺点之一。

解决方案：

• 实施适当的治理，使工具配置不会失控。 （请参阅下面的严格治理。）
• 专门针对其配置方式的狭窄培训。有 Jira 101 培训，然后是您的 Jira 实例的配置方式。 Jira 可能会让人不知所措，但如果有一些简单的操作手册可以完成常见任务，那么用户不需要成为如何使用该工具的专家，他们只需要知道如何将其用于他们的用例即可。
• 让管理员了解某些配置的含义。

它的可定制性不够

问题：

• 用户还会抱怨他们无法控制为自己的团队配置工具。

解决方案：

• 对每个项目无法控制的原因设定期望，也不应该有自己的配置。大型企业无法承担与管理 100 个自定义项目相关的开销。如果不加考虑地添加更改，工具的质量将会下降。有 SaaS 项目管理工具允许团队管理他们自己的配置，但当一些指标在全球范围内捕获或需要遵循标准时，这不是大型企业可以从中受益的模型。

严格治理

我见过很多 Jira 实例，它们有 1000 多个自定义字段，其中许多有重复的名称，或者是不适用于所有用户的高度具体的名称。这发生在缺乏治理的情况下。

用户要求提供新的自定义字段或状态，管理员在没有任何问题的情况下实施它。如果有一个可以利用的现有领域怎么办？这个字段将用于什么？

一个多学科的治理委员会应该对变更请求进行分类和批准，特别是对于共享配置。

对新请求进行分类时要考虑的一些问题：

• 此更改会影响使用该配置的所有团队吗？
• 它会增加不必要的开销吗？
• 它提供价值吗？如果未实施更改，投资回报率或影响是什么？

这将减慢进行更改的过程，但对于无法处理现场膨胀或配置不当项目的技术债务的企业级实例来说是必要的。

拥有流程所有者

同样，Jira 促进了流程。工程流程，例如缺陷管理，应该有一个所有者。该所有者负责应该与工具无关的过程。所有者将对流程的更改产生影响，Jira 管理员/所有者将负责实施流程并确保遵循工具的最佳流程。

这种模式的好处包括：

• 用于更改流程的集中位置。
• 减轻 Jira 团队的责任，他们可能不是流程专家，也不应该拥有其他团队拥有的流程。他们应该只负责适当地促进该过程的工具。
• 沟通渠道将很清晰，可以让流程所有者而不是 Jira 团队来回答问题。

何时使用插件

这类似于何时建造或何时购买难题。

如果一个解决方案不能通过配置优雅地解决，那么它不应该被实施。实施的经验和投资回报率将是负面的。

在大多数情况下，插件已经解决了这个问题。购买插件的成本可能低于开发和维护另一个解决方案的成本。

学会在不 100% 解决问题的情况下很难创建解决方案的情况下说“不”。

聘请优秀的团队来管理工具

一个成功的团队模型将具有以下特征：

• 系统管理员：系统管理员应负责升级和 KTLO。他们不应该负责设计业务流程和配置。
• Jira Admins：负责通过前端 UI 配置工具。工作流程配置、项目配置、现场配置等
• 业务系统管理员：负责将业务需求转化为如何在 Jira 中实施。
• 开发人员：用于脚本和插件开发。此角色仅对于可以与其他工具集成或需要大量自动化的大量使用的 Jira 实例是必需的。

BSA 和管理员或管理员和开发人员之间可能存在一些重叠，但一个单一的资源不应该对所有人负责。

我看到很多招聘信息都在寻找可以做到这一切的独角兽。这个模型有很多问题：

• 非常技术性的人可能能够毫无问题地配置该工具。这些资源通常是工程师或 IT 人员。他们可能不是这个过程的专家。不熟悉敏捷为整个工程组织实施 Scrum 工作流的人会遇到问题。
• 非常以流程为导向的人可能不具备技术来理解数据完整性或工具工作原理的细节。
• 基础架构工程师不应该，而且在大多数情况下，对与最终用户合作设计他们的业务流程没有兴趣。我确实看到了将所有这些职责混为一谈的工作要求，这是灾难的根源。

结论

并非所有这些解决方案都能解决所有 Jira 问题，但它们应该有助于提高对该工具的满意度。了解 Jira 是一个支持流程的平台将帮助用户了解需要关注的领域，以改善用户体验。

一些工程师可能厌倦了使用糟糕的实例，以至于他们不会被说服，但我认为仍然可以对其进行配置以满足他们的需求。与他们联系并直接获得他们的反馈。在大多数情况下，他们的问题在于可以轻松解决的配置。 UI 或性能问题可以在一定程度上缓解。

我仍然认为 Jira 在配置和管理得当的情况下是一个优于现有工具的工具。