Scrum et XP : Retours d’expérience

Jeudi dernier, le groupe des praticiens Agiles de Nantes proposaient deux retours d'expérience autour des méthodes Scrum et de la mise en place de l'eXtreme Programming (XP).
Nous avons aussi pu bénéficier d'un retour sur la formation ScrumMaster dispensée par Pyxis.
Petit résumé de la soirée...

Scrum est une méthode agile utilisée pour la gestion de projet. Son objectif est de proposer au client une structure réactive pour mieux répondre à ses besoins et à ses demandes d'évolution tout au long du projet. Cette réactivité passe par une amélioration de la productivité des équipes.
Pour y parvenir, Scrum propose un certain nombre de préconisations en terme d'organisation et de communication.

Au niveau organisationnel, Scrum identifie trois rôles différents :

  • le Directeur de Produit ("Product Owner") : il s'agit du client ou du représentant du client. C'est lui qui a la connaissance métier et qui détermine l'ordre des fonctionnalités à implémenter.
  • le ScrumMaster : il s'agit d'un membre de l'équipe projet. Il a en charge d'animer les daily meetings (points journaliers) et de motiver l'équipe. Un point essentiel : ce rôle n'est pas forcément assuré par le chef de projet !
  • et le dernier acteur, sans qui rien ne serait possible, l' Equipe : c'est elle qui réalise l'application. Il n'y a pas de notion de hiérarchie dans l'équipe. Les décisions sont prises ensemble, notamment lors des daily meetings. On parle d'une équipe en auto-gestion : chacun sait ce qui est à faire et pour quand. L'équipe partage donc cet objectif commun et c'est à elle de tout mettre en œuvre pour y arriver.

Le principe clé de Scrum est la communication. C'est en communiquant le plus possible qu'on va être capable de résoudre les problèmes ou de détecter des incompatibilités entre fonctionnalités le plus tôt possible.
Pour mettre en place une communication efficace, Scrum propose les daily meetings. Tous les acteurs du projet doivent y participer (y compris le client). L'objectif est de faire le point en toute transparence. Chaque membre de l'équipe indique :

  • ce qu'il a fait hier
  • les problèmes qu'il a résolu
  • ses éventuels points de blocage
  • ce qu'il va faire aujourd'hui

La présence du client est importante lors de ces points car cela lui permet de suivre l'état d'avancement de l'application et d'avoir connaissance des problèmes que rencontre l'équipe sur telle fonctionnalité. Une ré estimation ou un retard de livraison pour une fonctionnalité sera alors mieux compris.
Impliquer le client au quotidien et pas seulement lors des livraisons est un vrai challenge. C'est indéniablement l'élément le plus difficile à mettre en œuvre de la méthode Scrum. Sur le retour d'expérience présenté, c'est d'ailleurs l'implication du client qui a été mise de côté...

Même si Scrum est un vaste sujet, passons au deuxième thème de la soirée : l'eXtreme Programming.

L'eXtreme Programming (XP) est une autre méthode agile de conduite de projet. Comparée à Scrum, XP propose des préconisations qui sont plus orientées côté technique.
On va alors retrouver, comme principes :

  • une conception simple et qui évolue tout au long du projet (on ne garde que les diagrammes qui sont indispensables)
  • la mise en place d'une intégration continue
  • la mise en place de l'automatisation des tests (qui permet d'assurer les opérations de refactoring)
  • la généralisation du pair-programming (un développeur doit être capable d'intervenir sur l'ensemble du code de l'application)
  • l'application de normes de développement (ces normes doivent être connues de tous les développeurs : il est donc essentiel que les développeurs prennent part à leur définition au début du projet)

Parmi tous ces principes, le plus dur à faire accepter (notamment à la direction) est le pair-programming, qui est souvent perçu comme une perte de temps.

Scrum et XP ont une ligne directrice commune : mettre définitivement de côté les méthodes de développement dites traditionnelles qui consistaient à suivre un cahier des charges et à livrer l'application en fin de projet. Le projet doit être découpé en plusieurs cycles et une livraison doit être faite à la fin de chaque cycle : on parle de développement itératif. Les livraisons régulières (en moyenne tous les 30 jours) sont là pour obtenir des validations intermédiaires du client et pour être sûr d'être en adéquation avec le besoin.

En résumé, "pragmatisme", "souplesse" et "simplicité" doivent être les valeurs de référence tout au long du projet : les méthodes Scrum et XP sont là pour nous aider !!

Et comme promis, le retour sur la formation de ScrumMaster dispensée par Pyxis qu'a suivie Pierrick Thibault, Directeur technique chez Carra Consulting. Il s'agit d'un retour positif, aussi bien sur le contenu que sur la qualité du formateur : François Beauregard. Selon Pierrick, les présentations et les exercices pratiques permettent de prendre conscience de la nécessité d'apporter de l'agilité dans la gestion de projets.
Mais c'est à chacun de réfléchir à ce qu'il est possible d'appliquer sur un projet en fonction du client et de ses équipes : il n'y a pas de recette miracle mais une liste d'ingrédients que chacun doit combiner !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.