Étapes de résolution d'un ticket

Cette liste permet aux développeurs de suivre la même méthode lors de la résolution des tickets Jira. Elle permet de maximiser l'efficacité et la coordination de l'équipe. Elle est complémentaire avec le Definition Of Done

Je prends un ticket

• J'essaye de garder une logique dans les thèmes des tickets.
• Je détermine en amont avec qui je vais travailler (binôme)

Pré-conception

C'est la partie dans laquelle on prend le temps de comprendre le ticket. Tous ces éléments peuvent être ajoutés au ticket.

• Aspect fonctionnel
  • Quelles règles métiers dois-je implémenter
  • Quels tests vais-je devoir développer (juste une liste de phrases)
  • Je pose les questions nécessaires à la compréhension du ticket aux personnes concernées.
• Coté back
  • De quel endpoints j'ai besoin, comment s'appellent-ils ?
  • De quels services j'ai besoin, que font-ils ? Sur quelles requêtes s'appuient-ils ?
  • Quelle partie du code ressemble à ce que j'implémente et peut m'inspirer ?
• Côté front
  • Quel modèle je peux utiliser
  • Quels éléments partagés je peux utiliser + est-ce que je sais comment les utiliser
• Organisation :
  • J'essaie d'estimer le temps consacré à chacun des éléments, en découpant si nécessaire (contrôleur, service, front, tests ...)

Je propose une solution

• Je provoque une réunion pour exposer mon approche à mon binôme. Le cas échéant, on sollicite une expertise (front, back, Liquibase...)
• J'ajuste et je re-propose selon les remarques : on essaiera néanmoins de résoudre les problèmes soulevés en direct pour pouvoir avancer

Je code la base

• Je développe les éléments prévus en pré-conception
• Une fois codé les éléments, je provoque une réunion avec mon binôme pour présenter le code produit. Cet exercice ne doit pas excéder 30 minutes.
• J'ajuste le code selon les remarques

Je teste

• Implémenter d'abord un test de bout en bout pour s'assurer que la chaîne fonctionne et que les droits d'accès sont effectifs
• Lister tous les tests unitaires avant de les coder : je définis juste le nom de la méthode dans mon fichier. Ainsi, je risque moins d'oublier des tests, et aussi, je risque moins de me perdre dans des tests inutiles.
• Ensuite les autres tests : réserver les tests intégrations aux cas passants et aux cas en erreur les plus "exotiques" (l'utilité des tests d'intégration doit être justifié dans la Javadoc). La règle est : j'utilise un test d'intégration uniquement si je ne peux pas tester avec le test du service.

Je soumets

• Je demande la revue de mon code. Normalement, il y a peu d'éléments à corriger à ce stade.
• J'ajoute les annotations OpenAPI
• La MR doit être approuvée par le reviewer dans GitLab avant de merger vers dev