Gérer un projet agile avec Gitlab

Quand il s’agit de la mise en oeuvre opérationnelle d’un outil de gestion de projet agile, l’utilisateur se retrouve souvent perdu devant l’offre d’outils.

J’explique dans cette article mon expérience pour planifier un projet agile avec Gitlab.com qui est une solution gratuite et simple à mettre en oeuvre.

Mon approche est loin d’être parfaite et correspond au contexte de mes missions. Toute remarque par rapport à votre propre expérience ou suggestion d’amélioration est la bienvenue.

Note : Je n’ai aucun lien commercial avec la société qui édite Gitlab.

Pourquoi et quand utiliser Gitlab ?

Gitlab.com est la version en ligne et gratuite de Gitlab, le gestionnaire de dépôts Git open source avec des fonctionnalités de wiki et de gestion des incidents. J’ai été amené à l’adapter pour faire de la gestion de projet agile dans le contexte suivant qui n’est pas forcément le vôtre :

• Equipe à distance : L’outil est pratique pour travailler avec des équipes éparpillées et à distance. Dans le cas où l’équipe et le PO sont au même endroit, il est sûrement simple d‘utiliser des posts-it pour gérer les tâches.
• Gratuit et sans restriction : Il n’y aucun coût ou restriction lié à l‘utilisation de Gitlab.com. C’est un avantage non négligeable par rapport à des solutions propriétaires.
• Projets publics : En contrepartie, il faut accepter que les projets soient “visibles” par tous. Dans la pratique, il est possible de fermer l’accès public au dépôt de code s’il existe, et au suivi des tâches. Si l’organisation souhaite plus de sécurité, il est nécessaire de basculer à une solution locale payante.
• Service cloud : Il n’y a pas de logiciel à installer en revanche, il faut être connecté à Internet en permanence car toutes les informations sont stockées sur les serveurs de Gitlab.com, ce qui n’est pas acceptable pour certaines organisations.
• Gestion de projet simple : Gitlab n’est pas aussi complet que Jira, mais selon moi il répond à la majorité des cas d’utilisation et est certainement plus riche qu’un Trello. L’interface est également conviviale et la prise en main rapide.
• Dépôt de code et intégration continue en option : Gitlab est à la base une forge logicielle couplée à une gestion des incidents. Cela permet à terme d’évoluer vers un outil de développement de bout en bout pour les développeurs.

Nous allons décrire le paramétrage dans Gitlab.com pour un projet public sachant que l’essentiel du fonctionnement sont transposables dans Jira.

La traduction française de Gitlab est incomplète au moment de la rédaction de cet article. Les termes anglais sont utilisés par la suite.

Définir les types de spécification fonctionnelle

L’interface de Gitlab

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.

Editer une Story

• 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 transitiom 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.

Opérations sur les backlogs produit et développement

Depuis plus de 15 ans, NOVENCIA est le partenaire des plus grands noms de la finance sur des problématiques IT et Métiers. Avec pour seul objectif de faire jaillir de la valeur, nous accompagnons également le monde de la banque et de l’assurance, des medias et du numérique dans l’implémentation d’outils Big Data grâce à notre offre de DataFactory.