5 cas d'utilisation où la sécurité des issues peut améliorer votre projet Jira

"... Pouvons-nous rendre les stories visibles uniquement pour les développeurs ? ... " ou " ... les collègues du département spécialisé ne doivent pouvoir créer que des tâches ..." sont des questions ou des tâches qui nous sont souvent posées dans notre travail quotidien d'accompagnement des Jira.

Maintenant, Jira a certes un système d'autorisation sophistiqué avec une grande profondeur structurelle, mais avec de telles demandes, même les administrateurs Jira expérimentés arrivent souvent aux limites des possibilités de configuration. Pourtant, Jira offre une fonctionnalité plutôt rarement utilisée, sur laquelle nous voulons nous pencher aujourd'hui : "Issue Security" ou "sécurité des processus".

Il arrive souvent que la sécurité des opérations ne soit pas configurée lors de la mise en place de nouveaux projets. Cela est probablement dû à deux choses

  1. Le setup de la sécurité des processus n'est pas inclus dans les projets de modèles et doit au moins être mis en place initialement à la main.

  2. Avec la sécurité des processus, on obtient effectivement un niveau supplémentaire dans le système d'autorisation de Jira, qui est souvent source de confusion pour les utilisateurs dès la configuration de base.

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

1. archiver les contenus obsolètes sans fausser les statistiques

L'archivage des demandes est une fonctionnalité de Jira à Data Center. Avec la mise en place d'une Sécurité des opérations les administrateurs de projet (ou tout autre rôle, groupe ou utilisateur souhaité) peuvent simplement indiquer dans la tâche si celle-ci doit être "archivée", imitant ainsi l'archivage de tâches individuelles, même sur Server ou des instances dans le nuage.

La procédure est alors cachée aux utilisateurs normaux. Les utilisateurs admin peuvent continuer à voir les opérations. Ainsi, les évaluations pour les utilisateurs admin ne sont pas non plus faussées, tandis que les utilisateurs normaux voient moins de contenus qui ne sont déjà pas pertinents.

La fonction d'archivage "réel" de processus individuels est jusqu'à présent réservée aux installations Data Center. Il faut toutefois tenir compte d'autres effets secondaires :

2. cacher le contenu aux utilisateurs externes

Il est certes possible de partager des projets entiers avec un groupe d'utilisateurs ou de les cacher. Cependant, il arrive souvent que l'on souhaite cacher certains contenus d'un projet à un groupe d'utilisateurs.

Par exemple, dans un projet, les nouvelles stories pourraient être réservées aux collaborateurs internes. être visible, tandis que les collaborateurs externes peuvent continuer à voir les bugs et les tâches.

3. travailler sur des sujets de sécurité informatique sans les rendre publics

Si toute l'équipe informatique travaille dans Jira et y documente ses tâches, pourquoi pas l'équipe de la sécurité informatique ? Le problème est que l'équipe a besoin du soutien d'autres équipes, mais en même temps, les thèmes de la sécurité informatique ne doivent pas être simplement lisibles par tous les collaborateurs de l'organisation.

Dans ce cas, la sécurité des processus pourrait être configurée de manière à ce que seuls les utilisateurs qui ont été explicitement saisis par un admin dans un champ puissent voir les processus correspondants.

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

Les équipes interfonctionnelles sont de plus en plus importantes, en particulier dans les configurations agiles. Souvent, les évaluations peuvent prêter à confusion, par exemple lorsque toutes les tâches de développement ont été réalisées à temps, mais qu'il reste des tâches commerciales à accomplir. Dans ce cas, les objectifs ou les KPI ne peuvent pas être atteints.

La configuration de la sécurité des processus permettrait de rendre les tâches professionnelles invisibles pour les développeurs. De telles tâches ne seraient alors plus visibles dans les évaluations ou les listes.

5. visibilité des commandes uniquement pour certains lieux

Comme nous l'avons déjà dit dans notre blog précédent (Optimisation des processus dans la planification) les commandes de livraison peuvent également être gérées de manière centralisée dans un projet, sans que les commandes individuelles soient visibles au-delà des frontières de chaque site.

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

______

Il existe certainement une multitude d'autres cas d'application ou d'applications similaires pour la sécurité des processus. Les exemples cités montrent, nous l'espérons, les possibilités de pouvoir profiter des avantages d'un projet Jira commun sans surcharger l'utilisateur individuel avec un éventuel déluge de contenus.

Afin de 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 un outil supplémentaire disponible dans la boîte à outils de l'administrateur Jira.

Selon la complexité de la sécurité des processus, un concept de rôles bien pensé peut s'avérer utile ou du moins avoir un effet de soutien. En raison de la flexibilité de la configuration (par rôle, groupe ou utilisateur), il n'est toutefois pas indispensable.

_____

Chez Swarmit, nous avons déjà mis en place ces configurations, ainsi que d'autres similaires, à plusieurs reprises chez différents clients et pouvons volontiers aider à la conception et à la mise en œuvre de la sécurité des processus dans les projets Jira.

Erik Neudert, Swarmit AG

Partager cette publication