«... Pouvons-nous uniquement rendre les stories visibles pour les développeurs ? ... » ou «... les collègues du service spécialisé ne devraient pouvoir créer que des tâches... » sont des questions ou des tâches qui nous sont souvent posées dans le cadre de notre travail quotidien de supervision de Jira.

Bien que Jira dispose désormais d'un système d'autorisation sophistiqué doté d'une grande profondeur structurelle, les administrateurs Jira expérimentés atteignent souvent les limites des options de configuration lorsqu'il s'agit de telles demandes. Mais Jira propose une fonctionnalité assez rarement utilisée que nous voulons examiner aujourd'hui : la « sécurité des problèmes » ou la « sécurité des processus ».

La sécurité des processus n'est souvent pas configurée lors de la mise en place de nouveaux projets. Cela est probablement dû à deux choses :

La configuration de la sécurité des processus n'est pas incluse dans les modèles de projets et doit être configurée manuellement, au moins dans un premier temps.

Grâce à la sécurité des processus, vous obtenez effectivement un niveau supplémentaire dans le système d'autorisation Jira, ce qui entraîne souvent des ambiguïtés chez les utilisateurs, même lors de la configuration de base.

Cependant, cette fonctionnalité est très puissante et (donc correctement configurée) peut couvrir certains cas d'utilisation complexes qui ne seraient pas possibles autrement. C'est pourquoi nous avons compilé 5 de ces exemples pour les présenter ici :

1. Archivez le contenu obsolète sans falsifier les statistiques

Les processus d'archivage sont une fonctionnalité de Jira on Data Center. En configurant la sécurité des processus, les administrateurs de projet (ou tout autre rôle, groupe ou utilisateur souhaité) peuvent simplement déterminer au cours du processus s'il doit être « archivé » et imiter ainsi l'archivage de processus individuels, même sur des serveurs ou des instances cloud.

Le processus est masqué aux utilisateurs normaux. Les administrateurs peuvent toujours voir les processus. Cela ne fausse pas non plus les évaluations des utilisateurs administrateurs, tandis que les utilisateurs normaux voient moins de contenu qui n'est déjà pas pertinent.

La fonction d'archivage « authentique » des processus individuels n'a jusqu'à présent été réservée qu'aux installations des centres de données. Cependant, d'autres effets indésirables doivent être pris en compte :

Meilleures pratiques pour l'archivage des problèmes avec Jira

2. Masquer le contenu aux utilisateurs externes

Il est certainement possible de publier ou de masquer des projets entiers pour un groupe d'utilisateurs. Cependant, il est également fréquent que l'on souhaite masquer uniquement le contenu individuel d'un projet pour un groupe d'utilisateurs.

Par exemple, dans un projet, les nouvelles histoires ne pouvaient être visibles que par les employés internes, tandis que les employés externes pouvaient toujours voir les bogues et les tâches.

3. Travaillez sur des sujets liés à la sécurité informatique sans les rendre publics

Si l'ensemble du département informatique travaille dans Jira et y documente ses tâches, pourquoi pas également l'équipe de sécurité informatique ? Le problème, c'est que l'équipe a besoin du soutien des autres équipes, mais en même temps, les problèmes de sécurité informatique ne devraient pas être faciles à comprendre pour tous les employés de l'organisation.

Dans ce cas, la sécurité des processus peut être configurée de telle sorte que seuls les utilisateurs puissent voir les processus correspondants qui ont été explicitement saisis dans un champ par un administrateur.

4. Évaluations pour les développeurs sans tâches commerciales

Les équipes interfonctionnelles prennent de plus en plus d'importance, en particulier dans les configurations agiles. Cependant, les évaluations peuvent souvent prêter à confusion lorsque, par exemple, toutes les tâches de développement ont été achevées à temps, mais que certaines tâches commerciales sont encore en suspens. Dans ces cas, les objectifs ou les KPI ne peuvent pas être atteints.

En configurant la sécurité des processus, les tâches métier pourraient être rendues invisibles pour les développeurs. Cela signifierait également que ces tâches ne seraient plus visibles dans les évaluations ou les listes.

5. Visibilité des commandes uniquement pour des sites spécifiques

Comme dans notre blog précédent (Optimisation des processus dans la planification), les bons de livraison peuvent également être gérés de manière centralisée dans un projet sans que les commandes individuelles ne soient visibles au-delà des frontières du site concerné.

Optimisation des processus dans la planification

Ainsi, une équipe centrale peut voir et traiter toutes les commandes d'un projet, tandis que les utilisateurs des sites dédiés ne peuvent voir que les commandes qui leur sont également attribuées ou qui leur sont attribuées.

Il existe certainement de nombreux autres cas d'utilisation similaires pour la sécurité des processus. Espérons que les exemples donnés ci-dessus montrent les opportunités qui existent pour tirer parti d'un projet Jira conjoint sans submerger l'utilisateur individuel par un éventuel flot de contenu.

Afin d'obtenir les meilleurs résultats possibles et de répondre aux besoins des équipes dans Jira, la sécurité des processus ne doit pas être négligée, mais doit être disponible en tant qu'outil supplémentaire dans la boîte à outils de l'administrateur Jira.

En fonction de la complexité de la sécurité des processus, un concept de rôle bien pensé peut être utile ou du moins être utile. Cependant, en raison de la flexibilité de la configuration (en fonction des rôles, des groupes ou des utilisateurs), cela n'est pas absolument nécessaire.

Chez Swarmit, nous avons déjà utilisé ces configurations et d'autres configurations similaires à plusieurs reprises par différents clients et nous sommes heureux de vous aider à concevoir et à mettre en œuvre la sécurité des processus pour les projets Jira.

‍