Pourquoi cette séance maintenant?

• Vous entrez dans la phase MVP (Sprint 2) la semaine prochaine.
• Vous travaillez en équipe : il faut rendre le travail visible.
• GitLab devient l'outil de coordination central : tickets + Kanban + MR + jalons + releases.
• Ce que vous structurez aujourd'hui va vous faire gagner du temps pendant les phases de développement.

Objectifs d'apprentissage

À la fin de la séance, votre équipe peut :

• créer des tickets exploitables (assigné, éléments liés, jalon, labels)
• organiser les tickets avec des labels cohérents
• suivre l'avancement dans un tableau Kanban GitLab
• collaborer via les merge requests
• lier jalons et releases aux remises du cours.

Kanban

• À faire : prêt, clair, priorisé.
• En cours : travail actif, avec responsable.
• En revue : merge request ouverte, feedback en cours.
• Terminé : fusionné, validé, démontrable.

Règle simple : limitez le nombre de tickets « En cours » (1 par personne)

Un ticket de qualité

Chaque ticket doit inclure :

• un titre concret orienté action;
• une description (contexte, valeur, résultat attendu);
• 2 à 5 critères d'acceptation testables;
• une assignation explicite;
• un jalon (milestone) et des labels pertinents.

Parent et sous-tickets

• Un ticket parent représente un récit utilisateur.
• Les éléments liés découpent le travail en tâches livrables.
• On assigne les sous-tickets, pas le parent global.
• Les éléments liés évitent les oublis et facilite le suivi.

Labels : votre langage commun

Taxonomie recommandée (simple et stable) :

• workflow:En cours, workflow:En revue
• type::fonctionnalité, type::bug, type::doc
• priorité::haute, priorité::moyenne, priorité::basse

Évitez les labels redondants et gardez des noms cohérents.

Jalons (milestones) et plan de cours

Dans votre projet GitLab, créez minimalement :

• Sprint 2 - MVP (semaines 5 à 7)
• Sprint 3 - Itération V2 (semaines 8 à 10)
• Sprint 4 - Stabilisation et livraison (semaines 11 à 14)

Chaque ticket MVP doit être rattaché au bon jalon.

Merge requests (MR)

Une MR n'est pas une formalité : c'est un outil de qualité.

• référencez le ticket (Ferme #id);
• expliquez ce qui change et pourquoi;
• demandez une revue par un pair;
• corrigez avant de fusionner;
• fusionnez seulement quand c'est conforme à votre définition de terminé.

Releases

Une release sert à marquer une version livrée.

• tag clair (ex. v0.2.1);
• note de release : fonctionnalités, correctifs, limites connues;
• lien avec le jalon complété;
• utile pour les démonstrations, le suivi et la traçabilité.

Versionnage (majeur, mineur, patch)

Format recommandé : MAJEUR.MINEUR.PATCH (ex. v1.4.2)

• MAJEUR : changement important ou rupture de compatibilité.
• MINEUR : nouvelle fonctionnalité compatible.
• PATCH : correction de bogue sans nouvelle fonctionnalité.

Exemples pour le cours :

• v0.1.0 : Premier MVP fonctionnel
• v0.1.1 : correctif après la démo.
• v1.0.0 : version finale stable de livraison.

Livrables de fin de séance

Votre équipe doit avoir :

• un backlog des récits utilisateurs visible dans GitLab;
• Les tickets pour le MVP liés à un ou plusieurs récits utilisateurs
• des labels opérationnels et cohérents;
• les jalons de sprint créés;
• un board Kanban actif;
• Les tickets priorisés pour le MVP

Grille d'auto-vérification rapide

• Tous les tickets du premier sprint ont-ils un assigné?
• Tous les tickets ont-ils un jalon?
• Tous les tickets sont-ils associés à un récit utilisateur?
• Les labels sont-ils utiles et non redondants?

Erreurs fréquentes à éviter

• Tickets trop vagues (« faire l'interface »).
• Aucun élément lié.
• Aucune priorisation explicite.
• Board non mis à jour entre deux séances.
• MR trop grosses ouvertes à la dernière minute.

À retenir

• GitLab n'est pas juste un dépôt : c'est votre outil de gestion de projet.
• Je vais me servir de votre board kaban lors de nos rencontres hebdomadaires.
• La clarté des tickets réduit les frictions d'équipe.
• Ajustez en tout temps les tickets et votre tableau, c'est le reflet de votre progression.