Retour d'expérience sur Scrum

XYZ et SCRUM : Duo de choc

Le projet XYZ est un des projets pionnier dans l'application des méthodologies agiles au sein du pôle édition de logiciel de la DSI de mon client actuel et pour cette raison un retour d'expérience était nécessaire, d'où la création de cet article issu d'une page similaire présente sur le wiki.

Notre vision de SCRUM

Mais qu'est ce que SCRUM ?

Scrum propose une façon d'appréhender la gestion de projet qui change radicalement par rapport à certaines formes de gestion de projet dites classiques (ex: cycle de développement en cascade sans itérations).

• Ce qu'il faut retenir:
  • On favorisera les personnes et la communication plutôt que les outils et les processus.
  • On mettra en avant un produit opérationnel plutôt qu'avoir une documentation "trop" complète.
  • On préférera la négociation avec le client que de graver dans le marbre une expression du besoin qui évolue avec le temps.
  • On choisira d'être flexible plutôt que rigide et se tenir uniquement au plan initial.

Ce que l'on garde, ce que l'on ne garde pas

Ce que l'on garde :

• Les principaux généraux (vu ci-dessus : Itérations, Livraisons, Agilité)
• Un Scrum Master
• Une équipe auto-gérée
• Des intervenants ponctuels (audit de code, audit fonctionnelle, consultation, etc.)
• Le Product Backlog (liste des fonctionnalités du produit et Sprint Backlog (liste des fonctionnalités d'un sprint)
• Le Sprint Review (rétrospective du sprint)
• Le Sprint Planning (plannification du prochain sprint)

Ce que l'on ne garde pas :

• Scrum meeting ou Daily Scrum : L'équipe projet se composant de 3 personnes et étant dans le même bureau, il n'y a pas de réunion spécifique organisée. Nous travaillons au quotidien ensemble et nous connaissons donc parfaitement les taches de chacun.
• Sprint Review => présentation du produit : La présentation du produit à l'équipe et aux utilisateurs n'est pas réalisée à chaque sprint. Nous avons préféré la mise à disposition du logiciel sur une plateforme via l'envoi d'un mail pour les informer. L'équipe maitrisant l'ensemble des fonctionnalités de l'application.
• Burndown Chart

Notre application de SCRUM

Le produit est découpé en fonctionnalités (Backlog Produit).

On regroupe ces fonctionnalités au sein de Release prédéfinie.

Afin de réaliser les release, on effectue des sprints de 15 jours (modulable si besoin).

Chaque sprint contient des fonctionnalités à réaliser puisés au sein du Backlog Produit de la Release courante.

Entre chaque sprint a lieu le Sprint Review ainsi que le Sprint Planning
Le Sprint Review :

• le bon fonctionnement des fonctionnalités du sprint est vérifié.
• l'équipe liste les évènements marquants du sprint précédent et décide de mener des actions si besoin (le but étant de s'améliorer à chaque sprint)

Le Sprint Planning :

• l'équipe décide de la communication à effectuer pour ce sprint (envoi de mail aux équipes utilisatrices avec les fonctionnalités et faits marquants retenus)
• l'équipe découpe les fonctionnalités sélectionnés dans le backlog en taches à réaliser de 0 à 1,5 jours pour le prochain sprint. Il existe une notion de priorisation sur les taches :
  • hautes : à faire en priorité
  • normales
  • faibles.

Remarques : Le Sprint Planning est à préparer : une analyse générale des fonctionnalités du prochain sprint doit être effectuée au préalable.

Les outils de gestion de projet utilisé

L'outil principal est un fichier Excel :

• une feuille pour la Backlog Produit
• une feuille pour le suivi des taches à réaliser
• une feuille pour les faits marquants de chaque sprint.

SCRUM, le bilan

Le bilan est très positif : on a une vision des fonctionnalités très rapidement (a chaque fin de sprint).

L'effet tunnel est incompatible avec cette méthodologie.

Cela nous permet de toujours vérifier l'utilisabilité de chaque fonctionnalité.

SCRUM ne diminue pas la charge du projet mais améliore la qualité du produit développé.

Des charges de recette et de correction du bugs sont à prendre en compte lors de chaque sprint.

Le client final a plus de chance d'être satisfait du produit développé par rapport à une méthode classique ou on lui livre une version au bout de X mois.

Ce qui nous a manqué

• Le calcul de la vélocité de chaque sprint

cela permet de voir l'amélioration de l'efficacité de l'équipe.

• Le Release Burndown Chart

Il s'agit d'un graphique qui représente l'état d'avancement du projet ainsi que le reste à faire. Il donne une bonne idée sur le respect de la date prévue de livraison.

• Un tableau afin de pouvoir échanger autour de celui ci.

Ce qui ne nous a pas manqué

• L'utilisation de post it pour gérer l'état des taches à réaliser. Avec seulement 3 membres au sein de l'équipe, le manque de cet outil ne s'est pas fait ressentir, peut être à tort.

Les perspectives

Maintenant que SCRUM a été éprouvé sur un petit projet avec une petite équipe et que les résultats sont très positifs, il serait opportun de profiter de cet élan pour appliquer cette méthodologie sur d'autres projets avec d'autres équipes et ainsi répandre la culture agile au plus grand nombre.

Par exemple, un projet pilote de taille moyen avec une équipe de 4 ou 5 personnes serait un candidat idéal pour continuer dans ce sens.

En parallèle, gérer des projets SCRUM d'envergure (>10 personnes et >1 équipe) n'étant pas chose aisée, il serait bon de s'armer comme il se doit avant de se lancer dans une telle entreprise. Des formations ou des interventions réalisées par des experts de la méthodologies (Scrum Master) favoriseraient la réussite de projets plus conséquents.

Nos points de vues de SCRUM

Le point du vue du "chef de projet":

SCRUM associe l'ensemble de l'équipe autour du projet, chaque sprint est compris par l'équipe et l'ensemble du baklog produit est connu de tout le monde.

Ce qui n'est pas le cas dans des méthodes classiques ou le développeur ne connait pas toujours ce que ces petits copains réalisent.

SCRUM permet d'avoir une meilleure vision du reste à faire, on connait ce qui a été développé et on connait le backlog produit non réalisé.

SCRUM permet une souplesse dans le sens ou la modification de fonctionnalités (en dehors du sprint courant) est possible avec très peu d'impact.

Le point de vue du "développeur":

Cette méthodologie est déroutante car elle remet en cause nombre de pratiques généralement constatées avec des méthodologies classiques, elle place l'équipe plus au centre du projet ce qui valorise le travail de chacun.

Les membres de l'équipe ont leur mot à dire et on attend d'eux qu'ils soient critiques et constructifs. Les choix qu'ils font engage leur responsabilité et le bon déroulant du sprint en cours, ceci entraine un engagement de chacun et améliore donc l'investissement de l'équipe.

SCRUM ne permet pas de réduire les charges mais améliore la qualité du produit livré au plus tôt grâce à la souplesse de la mise en œuvre et aux retours rapides des utilisateurs.