Travailler avec GitLab Issues
Retrouver ce qui est prévu, qui y contribue et ce qui a été vérifié.
| Pendant la préparation du Product Backlog | Pendant les sprints |
|---|---|
| Créer les issues, décrire les résultats attendus et définir les priorités. | Préciser le travail retenu, répartir les responsabilités, développer et vérifier les résultats. |
Les intitulés des menus peuvent varier selon la version de GitLab. La liste des issues se trouve généralement dans Plan > Issues, ou dans Plan > Work items avec le type Issue.
Dans ce guide, main désigne la branche principale
et la branche par défaut du projet.
1. Créer une issue¶
Une issue correspond à un résultat attendu.
Ouvrez la liste des issues et choisissez New issue.
Donnez un titre précis.
Décrivez le besoin et les critères d’acceptation.
Ajoutez les labels de type et de priorité.
Description à adapter
## Résultat attendu
Décrire ce que cette issue doit permettre d’obtenir.
## Critères d’acceptation
- [ ] Premier comportement ou résultat à vérifier.
- [ ] Deuxième comportement ou résultat à vérifier.
## Informations utiles
Références, ressources réutilisées, croquis ou liens vers
d’autres issues, si nécessaire.Les critères d’acceptation doivent permettre de vérifier le résultat. Leur nombre dépend du besoin.
Les éléments encore éloignés de leur réalisation peuvent rester plus généraux. Précisez-les avant de commencer leur développement.
Découper un besoin et indiquer les dépendances
Si un besoin devient trop large, créez des issues plus petites et référencez-les dans sa description avec leur numéro :
Travail détaillé dans :
- #42 Recommencer une partie après une défaite.
- #43 Afficher le résultat de la partie.Pour expliquer une dépendance, une phrase suffit :
Cette issue dépend de #42 : le redémarrage doit fonctionner
avant de pouvoir tester plusieurs parties successives.Une même issue peut recevoir plusieurs contributions. Il n’est pas nécessaire de créer une issue par personne ou par commit.
2. Utiliser quelques labels communs¶
Les labels indiquent la nature, la priorité et l’avancement du travail.
Créez les labels suivants dans les Labels du projet.
| Famille | Label | Signification |
|---|---|---|
| Type | type::feature | Fonctionnalité ou amélioration du jeu. |
| Type | type::bug | Défaut à reproduire et à corriger. |
| Type | type::task | Autre travail : documentation, tests, ressources, organisation ou maintenance technique. |
| Priorité | priority::high | Travail à traiter en priorité. |
| Priorité | priority::medium | Travail important pouvant attendre les premières priorités. |
| Priorité | priority::low | Travail moins prioritaire. |
| Avancement | status::in-progress | Travail commencé. |
| Avancement | status::in-review | Résultat proposé, en attente de vérification. |
| Blocage | blocked | Une difficulté empêche de poursuivre normalement. |
Chaque issue possède un type et une priorité. Elle possède au maximum un label d’avancement.
Une issue ouverte sans label d’avancement est en attente. Une issue terminée est fermée avec Close issue.
Garder des labels cohérents
Lors d’un changement de priorité ou d’avancement, vérifiez que l’ancien label a été retiré.
Le label blocked peut s’ajouter au label d’avancement :
une tâche peut être commencée et bloquée.
Une priorité basse ne signifie pas nécessairement que la fonctionnalité est optionnelle. Précisez les éléments optionnels dans leur description.
Les labels de domaine, comme area::audio, restent facultatifs.
3. Associer le travail à un sprint¶
Cette étape se fait lors de la préparation du Sprint Backlog.
Un milestone regroupe les issues retenues pour un sprint.
| Milestone | Début | Fin |
|---|---|---|
| Sprint 1 | 19/10/2026 | 30/11/2026 |
| Sprint 2 | 14/12/2026 | 01/02/2027 |
| Sprint 3 | 08/02/2027 | 15/03/2027 |
| Sprint 4 | 22/03/2027 | 24/05/2027 |
La fin correspond à la présentation du livrable. Les échéances des dépôts Moodle sont précisées dans le calendrier.
Préparer le milestone
Ouvrez Plan > Milestones.
Créez le milestone du sprint avec son nom et ses dates.
Écrivez l’objectif du sprint dans sa description.
Associez les issues sélectionnées à ce milestone.
Désignez un responsable du suivi de chaque issue dans Assignee.
Le responsable veille à l’avancement et à la mise à jour de l’issue. Il peut travailler avec d’autres membres, dont les contributions doivent également être identifiables.
Les issues non retenues restent disponibles pour une prochaine planification. Il est inutile de les dupliquer.
L’estimation du travail et la répartition des responsabilités seront approfondies lors de la préparation du Sprint Backlog.
Consulter les consignes de préparation et de remise du Sprint Backlog.
4. Suivre l’avancement sur un tableau¶
Un seul Issue Board suffit pour le projet.
| Colonne | Contenu |
|---|---|
| Open | Issues ouvertes sans label d’avancement. |
status::in-progress | Travail en cours. |
status::in-review | Travail à vérifier. |
| Closed | Issues fermées. |
Configurer et utiliser le tableau
Ouvrez Plan > Issue boards.
Utilisez le tableau existant ou créez-en un nommé Suivi du projet.
Conservez les colonnes Open et Closed.
Avec New list, ajoutez deux listes fondées sur les labels
status::in-progressetstatus::in-review.Filtrez par Milestone pour afficher le sprint en cours.
Le déplacement entre les deux colonnes de labels met à jour le label d’avancement.
Le filtre change seulement la vue affichée. Vérifiez le milestone d’une issue pour savoir à quel sprint elle appartient.
Signaler un blocage
Ajoutez le label blocked et un commentaire expliquant :
Ce qui empêche d’avancer.
Ce qui a déjà été essayé.
L’aide ou la décision nécessaire.
Prévenez également l’équipe. Retirez le label lorsque le blocage est résolu.
Avant de commencer un nouveau travail, regardez si vous pouvez aider à terminer ou à vérifier une issue déjà en cours.
5. Relier les issues au travail réalisé¶
Chaque issue doit permettre de retrouver les contributions et les vérifications associées.
À partir de la mise en place du backlog, chaque commit de travail référence l’issue concernée.
| Élément | Exemple pour l’issue nº 42 |
|---|---|
| Branche | 42-recommencer-partie |
| Commit | Ajouter le bouton Recommencer (#42) |
| Merge request | Permettre de recommencer une partie (#42) |
Les commandes et les étapes pratiques sont détaillées dans le guide Git et Godot.
Référencer et fermer sont deux actions différentes
#42 établit un lien avec l’issue nº 42 du projet courant.
Closes #42, dans la description d’une merge request, demande
sa fermeture automatique lors de l’intégration dans la branche
par défaut, si cette fonction est activée.
Utilisez cette référence de fermeture uniquement si la merge request termine effectivement l’issue.
Pour une contribution partielle, écrivez Contribue à #42.
Vérifiez également les références que GitLab aurait ajoutées
automatiquement à la description.
Dans les messages des commits, utilisez une simple référence
comme (#42).
Au Sprint 3, les bugs des autres jeux sont décrits dans votre rapport de tests. Chaque équipe crée ensuite ses propres issues de correction en référençant les fiches reçues.
Quand une issue est-elle terminée ?
Avant de fermer une issue correspondant à un travail réalisé, vérifiez :
Que les critères d’acceptation sont satisfaits.
Qu’un autre membre a laissé un retour concret sur sa vérification.
Que les corrections demandées ont été prises en compte.
Que les modifications du dépôt sont intégrées dans
main.
Si la fermeture automatique n’a pas lieu, fermez l’issue manuellement après ces vérifications.
Pour une tâche sans modification du dépôt, ajoutez dans l’issue le résultat ou le lien vers le travail réalisé, puis faites-le vérifier.
Les vérifications sont réparties entre les membres de l’équipe. Le Scrum Master n’en est pas le seul responsable.
6. Garder un suivi fidèle au travail réel¶
Mettez les issues à jour pendant le travail.
Notez les décisions qui modifient le résultat attendu.
Ajoutez les informations utiles aux autres membres.
Rendez visibles les contributions de développement, de documentation, de test et de relecture.
Intégrez régulièrement les modifications dans
main.
Chaque membre tient à jour les issues auxquelles il contribue. Le rédacteur d’une synthèse de backlog ne réalise pas ce suivi à la place des autres membres. Les contributions de coordination peuvent également être documentées par les décisions et les actions qu’elles ont permis.
À la fin du sprint, réutilisez ces éléments pour préparer votre bilan individuel, avec quelques liens directs vers votre travail.
Adapter le travail sans perdre sa trace
Si une issue n’est pas terminée à la fin du sprint, laissez-la ouverte et expliquez ce qui reste à faire.
Une décision de report doit apparaître dans le bilan du sprint avant de modifier son milestone.
Si un travail est abandonné, expliquez la décision avant de fermer l’issue. Une issue fermée pour abandon ne représente pas un résultat réalisé.
Si une issue a été fermée trop tôt, utilisez Reopen issue et précisez ce qui reste à vérifier ou à corriger.
Les modalités de remise du Product Backlog initial sont précisées dans les consignes du rendu.