La bonne visibilité demandeur

Dans les précédents épisodes, nous avons vu ensemble comment mettre en oeuvre un projet Jira et communiquer autour de son usage et adapter les types de demandes et champs afin que vos collègues utilisateurs de Jira puissent vous demander de l’aide.

Cet article va désormais s’intéresser au contrôle des permissions, au déclenchement de notifications et à la construction de tableaux Kanban pour que personne ne rate la moindre information !

A l’instar du Capitaine Picard, à vous de rester maître à bord de votre vaisseau, enfin, de votre instance Jira et de communiquer efficacement avec le reste de votre équipage !

Des permissions sur mesures

Jira permet un contrôle fin des permissions accordées à chaque utilisateur sur les demandes d’un projet. C’est à dire, quelles sont les actions qui lui sont permises, par rapport à son rôle sur le projet, ou l’appartenance à des groupes.

Nous avions commencé à aborder rapidement ces notions lors de l’initialisation de notre projet, en ajoutant tout utilisateur de la plateforme au rôle User, et les coéquipiers de cette équipe de support au rôle Developers.

Il est désormais temps de nous plonger dans ce que signifient réellement ces rôles pour ce qui est des actions qu’ils offrent.

Pour visualiser ce qui est en place sur notre projet SJ, accédons au menu d’administration projet en bas à gauche   (Project Administration) Permissions

Vous observez alors un tableau de permissions accordées, surplombé d’un cartouche qui vous indique combien de projets partagent ce même schéma. En fonction des configurations effectuées sur votre instance, les résultats peuvent varier d’une liberté totale (permissions accordées à toute personne connectée sur Jira) à quelque chose de beaucoup plus restrictif.

Pour nous permettre de définir des permissions sans risquer d’impacter d’autres projets, vous ne serez pas surpris de lire qu’il nous faudra définir un nouveau permission scheme, puis l’associer par la suite au projet.

C’est parti ! La modification des schemes se fait toujours au niveau de l’administration globale de l’instance :  (Jira Administration)> Issues > Permissions Schemes > Add Permission Scheme.

Après avoir donné un nom à ce schéma de permissions, puis l’avoir retrouvé dans la liste, nous démarrons donc sur un tableau blanc, un canvas libre de toute distraction pour construire ceci sur mesure.

Vous observez ainsi que les permissions sont regroupées par catégories, qui vont de l’administration sur le projet à l’imputation de temps sur les demandes.

En cliquant sur Grant Permission, vous pouvez ensuite ajouter une ou plusieurs permissions à des roles, des groupes, des utilisateurs spécifiques, ou encore des champs. Ces permissions s’ajoutent les unes aux autres pour chaque utilisateur en fonction des conditions qu’il remplit. Il n’y a donc pas de “permissions négatives” ou “restrictions” ou équivalent.

Je vous invite à vous souvenir de cette règle générale lors de l’attribution de permissions : 

  • Des Rôles projet plutôt que des Groupes
  • Des Groupes plutôt que des champs
  • Des Champs plutôt que des utilisateurs nominatifs.

Bien entendu, cette règle ne demande qu’à être confirmée par des exceptions, mais nous éviterons ceci pour cet exercice.

Distinguons donc plusieurs populations, pour chacune de ces populations, ajoutez les permissions comme indiqué dans le tableau suivant : 

Une fois les permissions ajoutées sur ce schéma de permissions, il ne nous reste plus qu’à l’activer sur notre projet SJ ! Cliquez donc sur  (Project Administration) Permissions > Actions > Use a different scheme  puis retrouvez le schéma fraîchement créé dans la liste.

Pour aller plus loin …

Certaines permissions ont été écartées pour simplifier cet exercice, comme toutes celles liées au vote, ou encore à l’imputation de temps.

La prise en charge fine de celles-ci est laissé en exercice au lecteur.

https://confluence.atlassian.com/adminjiraserver073/managing-project-permissions-861253293.html

Des notifications à qui de droit

D’une manière extrêmement analogue à la gestion des permissions, Jira permet l’association d’événements qui surviennent sur les demandes à des notifications à destination d’un public défini. Par exemple, la création d’une demande et sa modification peuvent correspondre à des publics différents.

Reprenons donc le même cheminement, commençons par constater la configuration actuellement en place sur le projet SJ. Cliquez sur   (Project Administration) Notifications.   Ne nous attardons toutefois pas sur ce qui est en place, et préparons donc le schéma de notifications idéal pour notre contexte. Cliquez sur  (Jira Administration)> Issues > Notifications Schemes > Add Notifications Scheme puis donnez  lui un petit nom, tel que Support Jira Notification Scheme

Vous observez alors la liste des événements qui peuvent déclencher une notification, mais par défaut, ceux-ci ne sont associés à aucun destinataire. Dit autrement, voila un moyen efficace de réduire au silence radio – enfin, email – un projet.

Passons donc à l’ajout de destinataires pour ces événements. Pour chacun d’eux, un lien Add est présent, mais gardez en tête que vous pourrez sélectionner plusieurs événements d’un coup.

Afin de conserver les choses simples, nous pourront émettre des notifications identiques aux trois populations qui nous intéressent : 

PopulationsEvenements
RoleDévelopperReporterChamps personnalisé “CC”Issue Created
Issue Updated
Issue Assigned
Issue Resolved
Issue Closed
Issue Commented
Issue Comment Edited
Issue Comment Deleted
Issue Reopened
Issue Deleted
Issue Moved

Pour aller plus loin

Les premiers événements sont qualifiés de system; c’est à dire standard, définis par Atlassian. Il est possible de définir ses propres événements qui peuvent être déclenchés lors de certains transitions de workflow, vous permettant de représenter les actions précises sur les demandes.

Ceux-ci ne seront pas adressés dans cet article, mais vous pouvez en savoir plus avec le lien ci-dessous :

https://confluence.atlassian.com/adminjiraserver/adding-a-custom-event-938847495.html

Par la suite, quand vous aurez pris l’habitude de surveiller régulièrement ce qui se passe dans le projet SJ directement dans Jira, vous pourrez réduire les événements qui déclenchent des notifications à destination de vous, les Developper du projet SJ, les gourous de Jira.

Il ne nous reste plus qu’une action, associer ce nouveau schéma de notification au projet SJ. Cliquez donc sur  (Project Administration) Notifications > Actions > Use a different scheme  puis retrouvez le schéma fraîchement créé dans la liste.

Des tableaux pour simplifier le suivi

Les listes de demandes, c’est bien, les tableaux agiles, c’est mieux !

Nous en avons déjà discuté lors de la création du projet, et notre choix d’un projet basé sur le modèle Kanban. A la création, un tableau a été créé automatiquement, mais ca ne veut pas dire que celui-ci est immuable, et qu’il sera à jamais le seul tableau pour ce projet !

En effet, dans cette section, nous allons établir deux boards pour notre projet de support :

  • L’un, adapté du tableau existant pour le projet SJ, adressera toutes les demandes ouvertes par vos collègues utilisateurs, comme la création d’un projet ou le changement d’un workflow.
  • L’autre, créé pour l’occasion, présentera les demandes ouvertes par votre équipe de support, comme la planification de la montée de version du socle technique ou l’approvisionnement en croissants pour l’équipe !

Modifier le tableau existant

Comme je vous l’indiquais, nous allons commencer par adapter le tableau existant afin qu’il n’affiche que les demandes de vos collègues qui appellent à l’aide. Pour ce faire, il faudra commencer par se rendre sur le tableau en question, accessible depuis le menu à gauche quand on consulte le projet, puis cliquer sur Configure board du menu Board.

Comme vous le savez surement, un tableau, qu’il soit Scrum ou Kanban, n’est rien d’autre qu’une façon plus intuitive de consulter les demandes qui correspondent à un filtre. Afin de restreindre les demandes, nous allons justement adapter le filtre sous-jacent. Sous l’onglet General de la configuration du tableau, cliquez sur Edit filter query et en édition avancée, saisir la requête JQL suivante

project = SJ and reporter not in membersOf(“jira-administrators”) ORDER BY Rank ASC

De puis, nous allons permettre aux utilisateurs qui consultent ce board d’identifier rapidement les demandes qu’ils ont ouvertes, ou celles pour lesquelles ils sont en CC. Ceci peut être fait très simplement en ajoutant ce que l’on appelle des Quick Filters dans la configuration du tableau.

  • Reported by me : reporter = currentUser()
  • I’m CCed : CC = currentUser()

Si vous aviez déjà ouvert des demandes dans ce projet, ne vous inquiétez pas de ne plus les voir sur ce tableau. Nous allons pouvoir enchaîner sur la création du second tableau; celui-ci rassemblera les demandes de tous les administrateurs eux-mêmes !

Créer un second tableau

Nous l’avons vu tout à l’heure, qui dit tableau dit filtre. Allons dans la navigateur de demandes, puis en JQL, retrouvons toutes les demandes du projet SJ qui ne seraient pas dans le premier filtre, c’est à dire celles-qui vérifient la condition suivante : 

project = SJ and reporter in membersOf(“jira-administrators”) ORDER BY Rank ASC

Après avoir vérifié que vos demandes sont bien là, sauvegardez ce filtre avec un nom parlant, tel que SJ Internal Board Filter, puis créez un tableau à partir de ce filtre depuis le menu Boards > View all Boards > Create Board. Encore une fois, un tableau Kanban semble tout indiqué, mais qui sait, peut être souhaitez vous faire dans l’originalité ! Pensez à baser ce tableau sur le filtre fraîchement créé.

Surement aurez vous besoin d’adapter les colones de ce tableau et ajouter des Quick Filters, je n’ai aucun doute sur le fait que vous saurez le faire désormais. Ce qui nous intéresse dans l’immédiat, c’est que ce tableau soit accessible à vos co-équipiers administrateurs ! Sur l’onglet General de l’administration de ce tableau, cliquez sur Edit filter Shares. Pour les règles de partage, je vous invite à préférer le partage à un role projet plutôt qu’un groupe, ce qui revient à suivre la même règle que pour les permissions. Dans le cas présent, il s’agit donc de le partager au Developpers du projet SJ.

Pour aller plus loin …

Les tableaux offrent bien plus d’options que ceci pour contrôler l’affichage des demandes sous forme de cartes, leur couleur, etc. Pour en savoir plus, n’hésitez pas à regarder la documentation suivante :

https://confluence.atlassian.com/jirasoftwareserver/configuring-a-board-938845252.html

Il est désormais temps de réunir vos coéquipiers pour une démonstration de votre nouvel outil !

Faites du bruit, parlez en autour de vous et à vos utilisateurs. Les outils sont une choses, mais la conduite du changement ne peut se faire que si vous êtes porteurs de la transformation. 

A très vite pour la suite de la mise en oeuvre, qui sera centrée autour des flux de travaux, ou Workflows dans la langue de Shakespeare et la construction de tableaux de boards pour suivre la performance de votre équipe !


Gael Motte
Gael Motte

Consultant Avant Vente Solutions Atlassian

Recommandations