Prise en charge d'un ticket d'anomalie

Plusieurs actions les plus communs ("de bon sens") sont à suivre lors de la prise en charge d'un ticket d'anomalie. Ces actions permettent de terminer au plus vite les corrections.

1. Les prérequis

1. Avoir un environnement de développement complet (Eclipse, PostgreSQL, Notepad ++ (optionel), WinMerge (optionel), Apache, Git Bash, EclEmma) et le même que les testeurs finaux.
2. Avoir les accès au code sur un gestionnaire de version
3. Avoir configuré son environnement et son projet
4. Respecter tout au long du développement les règles de "Bonnes pratiques de développement d'un ticket"

 
2. Les actions à exécuter

1. Comprendre la description du ticket d'anomalie
2. S'assurer de la complétude des informations afin de pouvoir le prendre en charge. Exemples :
   1. Étapes à suivre afin d'arriver sur l'écran souhaité contenant l'anomalie
   2. Données à obtenir afin de reproduire l'anomalie (BDD, arguments de lancement du serveur etc)
   3. Données pré-remplies / ajoutées afin de pouvoir tester la solution finale
   4. Prise en compte de la documentation existante
   5. Au besoin, réaliser un atelier avec le client / personnes ayant déjà travaillé sur les parties potentiellement impactées / personnes ayant connaissance du projet
   6. Combien de temps ai-je pour réaliser la tâche ? / Quelle est la date maximale de réalisation de la tâche / Quel est le degré d'importance du ticket
   7. Comment livrer / déployer et qui est le responsable de ces tâches.
3. Modifier l'état du ticket
4. Créer une branche GIT et une Merge Request associée (en suivant les nomenclatures déjà définies) avec pour base le code contenant l'anomalie (develop ou tag existant)
5. Reproduire l'anomalie
6. Vérification que l'anomalie en est bien une (peut-être une évolution)
7. Rechercher et lister les fichiers à modifier
8. Réaliser la correction de l'anomalie et s'assurer de ne pas ajouter de régression (bien tester son développement ainsi que les autres parties potentiellement impactées)
9. Création des tests unitaires / tests d'intégration en parallèle de la correction
10. Mettre au propre le code modifié et le re-tester
11. Déposer sa correction sous GIT. Un ou plusieurs commits pourront être crées. De préférence un par anomalie ou un seul commit pour toute la correction
12. Demander une revue de code. Pour ce faire, réaliser les étapes suivantes :
    1. Affecter le ticket à un relecteur
    2. Mettre le ticket dans l'état "IN REVIEW"
    3. Affecter la Merge Request du ticket au relecteur et supprimer le mot "Draft:" devant la MR
13. Mettre à jour la documentation existante ou la créer
14. Une fois la relecture de code effectuée (et potentiellement les corrections apportées), réaliser la livraison / déploiement
15. S'assurer que la livraison / déploiement a bien été effectuée et si possible vérifier que cette mise à disposition soit fonctionnelle
16. Mettre la correction à disposition des autres collaborateurs (merge dans la branche "develop") et les avertir (surtout dans le cas d'actions de leurs parts à effectuer)
17. Modifier l'état du ticket

Remarques :

• Mettre son code sous GIT tous les soirs. Cela évitera des potentiels pertes et permettra aux autre collaborateurs de reprendre le ticket si besoin
• Avertir tout au long de la prise en charge du ticket si les délais imposés dans le ticket peuvent ne pas être respectés, lister les causes et les potentiels actions à mener pour palier ce problème
• Suivre les bonnes pratiques de développement