Dans ce fil de billets, nous avons eu l’occasion de discuter de la mise en place d’un projet Jira, puis de la définition fine de types de demandespour enfin aborder les permissions et les tableaux agiles.

Pour résumer ce que l’on va aborder aujourd’hui, tout l’objectif va être de fluidifier votre travail en tant qu’administrateur de la plateforme et de mesurer votre performance pour identifier comment vous améliorer. Rassurez vous de même, il est hors de question que Jira devienne aussi aliénant que les conditions de travail de Chaplin !

Chose promise, chose due ! Les workflows, leurs schémas et la mise en place de tableaux de bords n’auront plus aucun secret pour vous après cette lecture.

Des Flux de Travaux adaptés

La création du projet de Support SJ remonte un peu, donc un petit rappel s’impose. Nous avions basé le projet sur le modèle de base des projets Kanban, et coté workflow, on est plus proche du monde du développement logiciel que du support !

Commencez par constater ce qui est en place. Cliquez sur (Project Administration) > Workflows, ce qui donne le listing des workflows associé à chaque types de demandes permis pour le projet. Par défaut, un unique flux de travail simplifié est appliqué.

Que sont donc les simplified Workflows ? Ce sont des flux de travaux qui ont la particularité de permettre d’aller de tout état à tout autre état et ne sont utilisé que par un unique projet. En conjonction avec un tableau agile, les administrateurs projets peuvent créer des status dans ce workflow.

Pour aller plus loin …

Les flux de travaux simplifiés sont un moyen de donner de l’autonomie à vos équipes. En contre partie, il devient plus difficile de construire une communauté de pratique cohérente et fournir un reporting simple et efficace au management.

Si ce compromis ne vous fait pas peur, n’hésitez pas à en lire un peu plus dans la documentation suivante.

Dans notre cas, nous allons créé un nouveau flux de travaux et le construire pour un usage centré sur l’usage support.

Rendez vous dans l’administration des flux de traveaux en cliquant sur  (Jira Administration)> Issues > Workflows  puis Add Workflow.

Depuis l’éditeur dans sa vue Diagram, vous pouvez dessiner ceci à volonté. Voici un exemple qui s’adapte plutot bien aux projets orientés supports :

Sur les transitions, il vous est possible de configurer les éléments suivants : 

• Name : Le nom affiché pour les transitions. Ceux-ci peuvent correspondre à un verbe, ou au statut auquel elle amène.
• Screen : Un écran, tel que nous avons déjà construits précédemment, qui sera affiche lors de la transition
• Properties : Clefs et valeurs vous permettant d’enrichir le comportement de vos transitions. Ceci va de leur traduction à la position du bouton représentant cette transition ou les valeurs possibles de certains champs
• Conditions : Conditions à respecter pour que l’action soit permise à l’utilisateur et donc affichée à l’écran
• Validators : Vérification à effectuer sur les valeurs de la demande pour mettre la réalisation de la transition. Notez que des plugins sont requis pour utiliser des validateurs.
• Post Function : Actions qui seront réalisées automatiquement sur la demande lors de la transition.

J’attire votre attention en particulier sur les post-functions, et une d’entre elle : « Update Issue Field », qui vous permettra lors de la transition « Resolved » d’affecter une valeur au champs Résolution. Sans valeur pour ce champs, Jira considère que le demande reste ouverte, même à l’état Close !

De la même manière, il vous faudra retirer la résolution si le demandeur active la transition « Re-Open ». Ceci se matérialise dans la configuration de la transitions par la même post-function.

Pour compléter l’exercice de définition du flux de travaux, à vous d’ajouter un écran ne contenant que le champs commentaire lors de la transition vers l’état « Waiting For Customer ».

Enfin, il ne reste plus qu’à activer ce flux de travaux sur le projet SJ. Il ne vous aura pas échappé que de manière analogue aux types de demandes, ou au écrans, il existe des schémas régissant la correspondance entre les flux de travaux et le projets.

Cliquer sur  (Jira Administration)> Issues > Workflow schemes puis retrouvez dans la liste celui qui est affecté au projet SJ et éditez le. Il vous est alors possible d’ajouter de nouveaux Flux de traveaux à ce shéma, en choisissant quel type de demande est impacté. C’est ainsi que vous pourrez introduire des traitements différents en fonction des types de demandes.

La publication du Workflow Scheme permet aux changements que vous avez effectué de prendre effet. Jira vous propose alors de mettre en relation les différents états qui existaient auparavant, et ceux qui sont désormais en vigueur.

Un tableau de board pour prendre du recul

Maintenant que vos utilisateurs savent à qui s’adresser, tout l’art est de ne pas se laisser submerger. Afin de piloter efficacement l’activité de votre équipe support, il est important de se doter de rapports et de prendre de sortir la tête du guidon.

Nous allons mettre de coté notre casquette d’administrateur de Jira quelques minutes et mettre en oeuvre un Tableau de Board !

Pour aller plus loin …

La capacité de créer des tableaux de bords est en standard offerte à tout utilisateur possédant une licence Jira.

Si vous souhaitez conserver la main sur les objets partagés, une permissions globale vous permet de restreindre ces droits à un public identifié.

Un tableau de bord, ou Dashboard en anglais, vous permet de présenter de manière synthétique un ensemble de rapports ou résultats graphiques.

Pour créer un tableau de bord, cliquer sur le menu  Dashboard > Manage Dashboards > Create new Dashboard. Pour l’exercice, nous le partagerons en consultation (Viewers) et en modification (Editors) aux utilisateurs présents dans le rôle Developper du projet SJ.

Ceci nous assurera qu’ils aient la visibilité sur l’ensemble des demandes. En effet, ces rapports prennent en compte les permissions de l’utilisateur qui les consultent !

Une fois le tableau de bord créé, vous êtes invités à ajouter des gadgets qui vous permettrons de présenter des résultats.

Laissez moi vous présenter mon petit chouchou; j’ai nommé le rapport « Recently Created Chart ».

Il a l’avantage de donner un un coup d’œil une idée de l’évolution de la charge de votre équipe de support en nombre de ticket, tout en donnant une indication sur l’âge des demandes. En rouge, celles qui ne sont pas encore résolues, en vertes, celles qui l’ont été !

Il existe de nombreux autres rapports et tableaux qui peuvent être mis en place au sein de ce tableau de board. Je ne peux vous encourager qu’à une chose, les essayer, et identifier ceux qui sont les plus pertinents pour votre équipe.

Une fois votre Tableau de board agrémenté, n’hésitez pas à le rendre visible sur un écran géant dans votre bureau avec la fonctionnalité « View as Wallboard ». Les utilisateurs qui vous rendent visites aiment savoir ce que vous faites !

Conclusion

Ce scenario nous aura permis ensemble de passer en revue la majorité des écrans de configurations de Jira qui vous permettent d’adapter les projets à leurs utilisateurs.

Bien sûr, de nombreux points ont été survolés rapidement, voir complètement éludés. N’hésitez pas à prendre contact avec nous pour tout besoin de formation ou d’accompagnement ; nos consultants sont à votre service.

Enfin, si ces éléments n’ont aucun mystère pour vous, ou si vous aimez le challenge d’apprendre et appliquer de nouvelles compétences, rejoignez nous !