Déroulement d'un sprint

Un sprint de développement dure entre 15 jours et 3 semaines. Le contenu d'un sprint est défini en fonction des retours territoires, des priorités techniques et de la roadmap et la faisabilité des fonctionnalités.

Retours et priorisation

Les territoire utilisant Histologe font régulièrement des retours d'usage à l'équipe déploiement. Ces retours sont rassemblés dans un tableau et discuté pendant les réunions de priorisation ayant lieu une fois tous les 15 jours.

Ces retours sont ensuite formalisés en tickets (issues) sur Github. L'équipe technique détermine quels tickets seront faits dans le sprint à venir, en fonction de la faisabilité et des autres priorités.

Création des issues

Pour plus de clarté, les issues doivent être le plus détaillées possibles. On distingue les tickets pour les nouvelles fonctionnalités / évolutions, et les tickets pour les bugs / améliorations. Dans tous les cas, certaines règles sont à respecter :

• Créer une issue par problème / fonctionnalité et ne pas faire de "fourre-tout" contenant plusieurs problèmes
• Ecrire un titre clair résumant la fonctionnalité ou le problème rencontré
• Indiquer dans le titre quelle partie du produit est concernée (exemple : commencer le ticket par [BO - Cartographie])
• Renseigner les labels qui s'appliquent à l'issue

Nouvelle fonctionnalité / évolution

• Ecrire l'objectif de la fonctionnalité
• Lister les prérequis pour accéder à la fonctionnalité (exemple : avoir un certain rôle sur le back-office)
• Décrire le user flow, étape par étape
• Décrire les conséquences une fois l'action complétée (exemple : envoi d'une notification)

Si l'action contient un formulaire : préciser la nature des champs et s'ils sont obligatoires ou non.

Bug / amélioration

• Donner l'objectif initial
• Décrire les étapes permettant de reproduire le problème
• Décrire le résultat obtenu
• Décrire le résultat attendu
• Ajouter des captures d'écran qui illustrent le problème
• Indiquer le nom et la version du navigateur utilisé
• Le cas échéant, indiquer de quel(s) partenaire(s) (territoire et rôle) vient le retour

Labels disponibles

Des labels sont disponibles pour mieux trier les issues :

• A tester : Cette issue est prête à être testée sur l'environnement de test
• Accessibilité : Concerne un problème d'accessibilité
• Amélioration : Pas une nouveauté ni un bug mais une amélioration de l'existant
• API / Intégrations : Concerne l'API Histologe et les intégrations de systèmes externes
• Automatisation : Concerne l'automatisation de la plateforme
• Bug : Quelque chose ne fonctionne pas
• Can't fix : L'issue ne peut pas être corrigée
• Contenu : Il y a une erreur de contenu (typo, texte manquant, etc.)
• Critique : Cette issue est critique et empêche l'utilisation du produit. Elle doit être corrigée au plus vite.
• dependencies : Pull requests that update a dependency file
• Doublon : Cette issue existe déjà
• Emails / notifs : Concerne les emails ou les notifications
• En attente : Il manque des infos ou des explications
• Feedback : Il s'agit d'un retour des partenaires
• Manquant : Il manque quelque chose
• MVE : Cette issue fait partie du minimum viable experience
• Nouveau : Nouvelle fonctionnalité
• Stats / Carto : Concerne les stats ou la cartographie
• UI : Concerne les éléments d'interface
• UX : Concerne l'expérience utilisateur

Milestone

Les issues sont ensuite regroupées dans une Milestone dédiée pour le sprint. Il peut arriver que d'autres issues soient ajoutées en cours de sprint, quand il s'agit de bugs bloquants ou gênants.

Test & debugging

Une fois les issues faites, elles sont poussées sur la plateforme de test. Elles sont testées par l'équipe produit qui réouvre celles n'étant pas corrigées ou en créent de nouvelles pour les éventuels bugs. Une fois que tout est corrigé et testé, on planifie la mise en prod.

Mise en prod

La mise en prod est planifiée par l'équipe de développement. Elle n'a jamais lieu le vendredi. Elle a idéalement lieu en dehors des horaires de travail des administrations : en soirée ou le midi. Si la mise en prod nécessite une interruption du service, les responsables de territoire sont prévenus par email minimum 48h à l'avance. Une fois la mise en prod faite, un mailing est envoyé aux responsables de territoire pour leur présenter les nouveautés de la mise à jour.