Définir les types de spécification fonctionnelle
L’ Issue est la notion centrale pour définir une spécification. J’ai choisi de les catégoriser en plusieurs types avec des Labels :
Epic: C’est une macro-fonctionnalité discutée et qualifiée avec les parties prenantes. L’Epic a un format libre et peut être accompagné de wireframe. On affecte un label Ready lorsqu’elle est entièrement validée par le client.
Story : C’est une fonctionnalité discutée et partagée avec l’équipe. Elle est liée à une Epic et suit les critères INVEST. peut avoir du contenu riche comme des liens vers d’autres Issues ou des sous-tâches ou conditions à cocher.
Task : C’est une tâche technique proposée par l’équipe nécessaire à la réalisation d’une Story. Elle suit les critères SMART.
Bug : C’est un problème relevé par l’équipe découvert en cours de développement et qui ne peut être résolu rapidement. Elle nécessite une repriorisation dans le backlog avec le PO.
Organiser le backlog
Gitlab permet de définir des Boards. Le principe est d’afficher un tableau de colonnes appelées Lists qui correspondent chacune à un Label. Nous pouvons faire des glisser-déposer pour modifier le statut d’une Issue. Nous définissons deux Boards, un pour le backlog produit, l’autre pour le backlog de développement.
Le backlog produit s’organise autour des Epics. Il est priorisé avec les labels de statut de la manière suivante :
High,Medium et Low : J’ai défini trois niveaux de priorisation mais cela peut être différent pour votre contexte. Il convient également de limiter le nombre d’EPICs importants et urgents.
- Backlog : Une Epic en High passe en Backlog lorsque son périmètre est délimité avec un label Ready et le développement est confirmé avec le client. Ce n’est qu’à ce moment que l’Epic est discuté avec l’équipe et décomposé en Stories.
Rejected : Il est important de garder une trace des idées formulées mais non retenues. L’Epic est généralement clôturé lorsqu’il est rejeté.
Le backlog de développement s’organise autour des Stories. Il est organisé avec des labels de statut sur l’état de développement :
Backlog : Cette liste est partagée avec les Epics ce qui permet de faire la transition entre les deux backlogs. On met un label Draft lorsque la Story est encore en cours de rédaction.
To Do : La Story ou la Task ou le Bug est au préalable discuté, estimée et assignée. Il convient de la prioriser en fonction des dépendances de développement.
Doing : La Story ou la Task ou le Bug est en cours de réalisation par l‘Equipe. Test : La Story ou la Task ou le Bug est développé par l’Equipe, il doit être vérifié par un autre membre de l’Equipe puis par le PO.
Une fois la Story validée par le PO, l’Issue est fermée.
Top comments (1)
Totally agree.