Scrum(mania)

Pas de doutes, je suis un convaincu des méthodes agiles qui se veulent modernes pour résoudre un problème de taille dans un projet : sa réussite. Réussite ne signifie pas qu’une fois en ligne, le projet a été une réussite, réussite signifie aussi et surtout : qu’il répond aux besoins des utilisateurs, qu’il soit utilisé, et que d’un point de vue ingénierie qu’il soit maintenable pour répondre simple et rapide à des évolutions. On parle souvent de 25 % des projets seulement réussis, pour toutes ces raisons. Dernièrement, j’ai eu à mener un projet en équipe, dans un contexte qui se voulait être un véritable challenge, que cela soit technologique mais surtout organisationnel, parmi quelques points que je peux citer :

• délais courts : un forfait pour livrer mi-novembre un site e-commerce de billetterie de vente de places pour des événements des 24H du Mans, 4 mois 1/2 pour un frontal construit from scratch (le backoffice étant existant mais à faire évoluer du point de vue modèle et de sa gestion, par une autre équipe),
• pas de connaissances des modèles (en base) que gère le backoffice ainsi que de l’infrastructure des sites,
• peu de spécifications, nous avions principalement  en notre possession des maquettes du site, maquette fournie par un prestataire externe, ce dernier étant plus un graphiste qu’un véritablement web designer pour un site Web, même si un cahier des charges existait,
• une partie de l’équipe en near shore, à Rennes, l’équipe de base composée de 5 personnes (dont moi en tant que CP technique) mais également des intégrateurs (externes) ou des développeurs (internes répartis entre Paris et Rennes), en tout, 10 personnes ont travaillé sur le projet,
• beaucoup d’acteurs / intermédiaires, à part le CP fonctionnel, un intermédiaire, une AMOA, également des prestataires tierces pour la gestion des comptes (“SSO”), pour le paiement (Paybox) et en bout de chaîne le client (l’ACO),
• une réorganisation en cours suite au rachat de PME, donc un contexte social délicat,
• un PO débutant dans sa fonction mais qui s’est avéré (heureusement) très efficace,
• des frontaux déjà en place mais dont la technologie utilisée était perfectible et que nous ne contrôlions pas (en gros un “framework” Javascript maison et des services Web en WCF REST), on a pris le parti de s’appuyer sur ASPNET MVC, quelques WebAPI et du Javascript natif, technologies déjà connues par une partie des équipes,

La 1ère étape fût d’estimer les fonctionnalités demandées, au niveau macro, à peine commencé, nous arrivions déjà à +200 jours (estimation du projet : ~500 jours /h) par rapport à la 1ère deadline (mi-novembre), date que nous ne pouvions reculer compte tenu de la communication faite sur les 1ères mises en vente.

En agilité, l’un des piliers est la priorisation. L’une des manières de maîtriser un projet et sa réussite, en agile, est de réduire le périmètre fonctionnel, seule manière raisonnable de fournir à temps un produit, même non complet. Ce produit aura bien souvent une qualité supérieure à ceux où le périmètre fonctionnel n’aura pas été réduit (pressé par le temps, l’équipe de développement devra “pisser” du code ou des raccourcis douteux, projet qui sera bien souvent peu maintenable dans le long terme).

La priorisation s’effectue en collaboration avec le PO, après un chiffrage “macro” (si possible en équipe par un ou des plannings poker) de chaque fonctionnalité souhaitée (elles peuvent au stade EPIC, cela reste du macro, quitte à ré-estimation les Stories ensuite avec la décomposition en tâches). Tout le long du projet, des sprints de 2 semaines ont été mis en place, avec chaque jour daily scrums (pour faciliter la communication entre interne, externe et le suivi général du reste à faire) avec les équipes (celle de Paris et celle de Rennes, grâce à skype installée dans une salle), et 1 fois par semaine, un point entre les chefs de projets et le PO sur l’avancement et les alertes à faire remontées si besoin et les moyens à mettre en oeuvre. Le MVP pour la 1ère version était bien évidemment le tunnel de vente : pouvoir vendre a minima des billets.

A l’issue des sprints, un planning poker pour estimer des fonctionnalités restant à développer, chaque fonctionnalité étant découpé en tâches, si possible, de façon à ce qu’une tâche ne dépasse pas 1 jour. Les estimations étant de plus en plus précise au fur et à mesure que l’équipe apprend sur l’environnement, le domaine et le projet en cours de développement.

Durant les 1ers sprints, nous avons eu du mal à faire des démos, mais au fil du temps, elles sont arrivées, rassurant le PO et le management, sur l’avancement du projet. Rassurer entraîne une meilleure confiance et donc moins de pression négative, et au bout du compte, une présence du management en cas de coup dur ou une démarche axée sur comment trouver une solution au lieu de blâmer. Le client final est également rassuré, voyant que cela avance, tout en comprenant qu’il va devoir lâcher, en tout cas pour la 1ère version, certaines fonctionnalités qui viendront plus tard.

Développer un projet reste un parcours du combattant, où résident bon nombre d’obstacles qu’il faut lever. L’agilité permet de les lever au plus tôt et non à la fin du projet, permet aussi une meilleure communication dans les équipes et donc une entraide bien souvent, pour débloquer le plus tôt possible tout blocage.

Voilà, nous y sommes arrivés : http://ticket.lemans.org