Référents : Création d’un BUG sur AzureDEV
Suite appel du client, le N1 crée le ticket et l’escalade en N2 avec toutes les infos nécessaires
La création d’un BUG est effectuée par un référent, généralement à la suite d’un appel N2 si un BUG a été constaté
Il est nécessaire dans un premier temps de consulter cette documentation mise en place par les développeurs afin de qualifier la sévérité d’un BUG : Gestion des BUG web
Si un BUG est critique (panne créant beaucoup d’appels, problèmes bloquants, etc..) il faut directement poster dans les canaux Teams afin d’en informer les développeurs pour une correction rapide (en quelques heures)
Pour les BUG non critiques, ceux-ci sont classifiés en trois catégories et nécessitent la création d’un BUG sur AzureDEV :
- HIGH (bug assez bloquant, mais qui génère peu d’appels ou pour lequel on a une solution de contournement) : il sera corrigé en 2-3 semaines lors du prochain sprint
délai de correction par le dev : 2-3 semaines
--> il est possible sur AzureDEV de basculer un HIGH en CRITICAL si la situation devient urgente
- MEDIUM (bug non bloquant ou non impactant)
Délai de résolution : plusieurs semaines, variable selon la charge de travail du dev
- LOW (bug mineur) : Délai de résolution (plusieurs mois)
Création d’une tâche sur le ticket avec les infos du BUG
Ticket :
Utilisateur :
Cabinet :
Version Albus/Topaze Air :
Vu par
HIGH/MEDIUM/LOW – AA/TA – Titre du BUG
Explications du BUG
Il faut s’assigner la tâche à son nom et la mettre « En attente » avec comme date d’échéance le jour même
Création du BUG sur AzureDEV
Une fois la tâche créée sur le ticket, il suffit de se rendre sur le site AzurDEV et identifier la Feature « A développer support technique infirmiers et kinés » puis cliquer sur le bouton (+) à sa gauche pour choisir l’option BUG
Il ne reste plus qu’à utiliser un titre avec la forme : (JJ/MM/AA) – Titre du BUG
Par la suite, il suffit de faire un copié-collé de la tâche du ticket avec l’explication du BUG
Enfin, à droite, on peut choisir la criticité du BUG et vers le bas, indiquez le Produit (logiciel concerné), le Projet (Support technique) et l’Origine du besoin (Hotline)
Vérifier également sur Teams : Remontée d'un bug sur Azure DevOps | AIR qu'il n'y ai pas eu de modifications entre temps sur la procédure.
Exemple ci-dessous :
Une fois le BUG enregistré, il sera créé mais il faudra le remonter en haut de liste afin qu’il soit pris en compte au prochain SPRINT
Si vous avez fait votre demande initiale sur un canal TEAMS, je vous invite à copier/coller toute la conversation sur votre demande.
Pour ce faire il faut aller sur la conversation correspondante, ensuite sur les 3 petits points en haut à droite, puis sur partager dans Outlook.
Sur Outlook il faut faire CTRL A pour tout sélectionner puis Coper/Coller sur votre demande de BUG. Vous aurez l’historique de toute la conversation et ça évitera au DEV de devoir se rendre sur TEAMS.
3. Suivi du BUG
Le BUG crée, celui-ci reçoit un numéro. Ce numéro est a indiqué sur la tâche qui a été créé dans le ticket SalesForce pour avoir une traçabilité dessus aussi
Une fois le bug résolu, le DEV identifie le N2 qui a créé le BUG sur Teams – canal Bugs résolus
Le N2 retourne sur le ticket pour clôturer la tâche et soit remettre le ticket en nouveau au N1 qui a créé le ticket ou recontacte le client (tel ou sms selon le cas) si le client a demandé à être averti de la résolution du problème.
Il ne restera plus qu’à joindre l’infirmier pour l’informer de la résolution du BUG et ainsi terminée la tâche sur le ticket et faire la clôture de ce dernier