Gestion des tickets¶
Pourquoi les tickets ?¶
L'un des intérêts de la création des tickets est d'orchestrer la gestion des incidents informatiques (les défaillances d'un service, une panne d'un matériel, anomalie dans une application...). Les tickets peuvent assurer une priorisation, une gestion des incidents, un suivi de l'avancement des solutions et un indicateurs de qualité de service.
Pour Lease4, il y a un autre intérêt à la mise en place d'un suivi de tickets. A savoir, lorsqu'une personne a une idée ou a un besoin, il est possible de l'écrire dans un ticket. L'équipe en charge de la gestion des tickets (développeurs, DevOps, ou autres) est alors averti. Le ticket offre également une trace écrite, et envoie par mail une notification.
Une chose non négligeable est, que créer un ticket, permet d'éluder l'envoi de plusieurs mails pour un problème/une idée... aux personnes concernées. Ce qui évite les boucles mails, les spams sur un sujet déjà connu...
Les tickets fournissent plusieurs informations : la date d'ouverture, le demandeur, l'attribution (qui doit résoudre), la catégorie, l'urgence, une description, un titre... De plus, une fois créé, un espace de rédaction de commentaire apparaît et est directement utilisable. Ce qui permet de mettre à jour l'évolution du ticket (rédaction de nouveaux problèmes, de tests effectués...).
En bref, les tickets sont un excellent moyen de réaliser le suivi des tâches, des améliorations et des problèmes techniques.
Pour Lease4, les tickets sont gérés dans GitLab. Ils ont pour nom issues. Le issue bord, permet de suivre de près les tâches en cours et les issues. Il est conçu de manière à ce que les informations soient pertinentes. Chaque membre de l'équipe (qui prend en charge le projet) est en mesure d'apporter des modifications, les autres membres, quant à eux, sont au courant des remaniements apportés.
La barre de recherche de GitLab permet de retrouver un ticket, en entrant un titre, un auteur, un label...
Capture d'écran du Issues Board DevOps
Les tickets sont listés par catégorie, ont un titre, des labels, une ID et peuvent avoir un attributeur.
Comment créer un ticket ?¶
Tous les tickets doivent être créés ici. Dans le menu à gauche, option Issues puis Boards, il faut cliquer sur le + du tableau, puis Open pour créer un ticket.
Pour que le système soit efficace, il faut rédiger une seule demande par ticket.
Si possible, il faut écrire un titre clair qui expose le sujet. Puis, toutes les informations qui peuvent aider à le résoudre, à apporter des éléments de compréhension... Ne pas hésiter à mettre des copies d'écran, et également, à développer des idées, des solutions...
Lors de la création d'un ticket, l'utilisateur peut lui attribuer des labels. S'il ne le fait pas, les développeurs le feront. Ils ont pour objectifs d'apporter des éléments de compréhension au ticket sans avoir besoin de l'ouvrir.
Ils sont organisés par couleur (couleur par défaut dans Gitlab).
Il y a plusieurs labels pour les thèmes généraux :
- API Bailleur
- Apporteur
- CRM
- Cession
- Contrat
- Facturation
Un label pour la documentation :
- Documentation
Un label pour l'ergonomie et l'infrastructure :
- Ergonomie
- Infrastructure
Parmi ces derniers, il y a en deux qui sont spéciaux :
Le premier correspond à la Businesss Value :
- Business Value 1
- Business Value 2
- Business Value 3
- Business Value 4
Le deuxième qui est lié au classement des tickets :
- ILC : Doing
- ILC : PCC
- ILC : Refinement
- ILC : PokerPlanning
- ILC : Ready
Cycle de vie des tickets¶
Le cycle de vie des tickets est géré par des labels. La plupart de ces labels sont préfixés par ILC:: l'abbréviation de Issue Life Cycle. Ces labels ont un comportement exclusif, c'est a dire que lorsqu'un de ces labels préfixé est associé à un ticket, un autre label avec le même préfixe ne peut être associé en même temps.
Open¶
Une fois le ticket créé et enregitré, il est automatiquement envoyé dans la liste Open. Cette liste par défaut permet de récupérer tous les tickets. Dans le cadre de Lease4, on utilise cette liste pour identifier les tickets en statut "brouillon", c'est à dire lorsqu'on crée un ticket en vue d'en reprendre le contenu ou d'en changer le statut par la suite.
Refinement¶
Le label Refinement permet au PO (Product Owner) de relire les demandes. Seuls les tickets disposant de ce label seront pris en compte. A l'issue de chaque relecture, le ticket passe en Poker Planning pour en évaluer la difficulté de réalisation avec l'équipe technique ou retourne en statut PCC pour un complément d'information de la part de son auteur.
PCC¶
Les tickets avec le statut PCC, pour Point Contact Client, sont des tickets qui ont été saisis par un client pour lesquels l'équipe technique a besoin de précisions. Si c'est une anomalie, la précision attendue peut porter sur le contexte dans lequel s'est produite cette anomalie. S'il s'agit d'une demande d'évolution, il peut s'agire d'un besoin d'informations complémentaires pour préciser le besoin du client
PokerPlanning¶
Les tickets en statut PokerPlanning sont suffisamemnt clairs pour être évalués et réalisés. Lors d'une session de Poker planning l'équipe technique et le PO vont évaluer la difficulté de chaque ticket en lui donnant un poids (1, 2, 3, 5, 8, 13, 20). Ce poids fait partie des critères pour plannifier les sprints de développement de 2 à 4 semaines.
Ready¶
Lorsqu'ils disposent du label Ready, les tickets sont prêts à être réalisés, ils sont à la fois suffisament précis et évalués par l'équipe pour être planifiés et réalisés au cours d'un sprint.
Doing¶
Ce label permet de connaître les tickets qui sont en cours de réalisation.
Closed¶
Une fois résolu, le ticket est passé à l'état closed. Il est donc terminé. Néanmoins, il est toujours possible de réouvrir un ticket, s'il n'avait par été traité dans son intégralité.
Modification du ticket¶
Lorsque qu'on traite un ticket, on essaye le plus souvent possible, d'écrire un commentaire dedans. L'objectif est de montrer comment le ticket "avance". Ce dernier, va permettre d'expliquer ce qui a été fait ou penser à faire pour résoudre le ticket, apporter des nouvelles informations, idées... De plus, le commentaire est accesible à l'ensemble de l'équipe, et un mail de notification est envoyé. Toute l'équipe reçoit donc les mises à jour du ticket.
Pour ce faire, il suffit d'aller sur le ticket (dans le Issues Boards), puis en bas, dans la partie Write, rédiger ce que l'on souhaite et cliquer sur Comment.
Astuce ticket¶
Il est possible de mettre des liens vers d'autres tickets, avec l'ajout d'un # et de l'id du ticket.
Par exemple vers les tickets 41 et 43:
Du fait des difficultés posées par l'usage de nft (dépendance ordre de démarrage cf #41, règles du firewall #43)
il est préférable d'envisager un retour vers IpTables, mieux supporté par Docker et Kubernetes notamment.
**Cette migration est sensible et est à prévoir soit un jour où les coupures ne sont pas un problème, soit lors d'un changement de serveur**
Capture d'écran d'un ticket