Retour d’expérience d’un projet Agile SNCF

Ce retour d'expérience concerne l'un des plus grands projets de mobilité d'Europe mené en 2008 qui consistait à réaliser une application mobile d'aide à la conduite pour les agents de conduite de la SNCF (une sorte de TomTom ferroviaire pour faire simple). Les délais accordés à la réalisation de la solution étaient extrêmement ambitieux en plus des enjeux techniques et fonctionnels.

Contexte du projet

Objectifs client

• Equiper 16 000 utilisateurs d’une application mobile d’aide à la conduite.
• Développer l’image de modernité.
• Etre plus efficace, plus souple, plus réactif.

Enjeux projet

• Equipe MOE : 15 personnes.
• Taille du projet : 10 années homme.
• Durée : 8 mois (délais très agressifs).
• Méthodes Agiles utilisées : Scrum & XP.
• Durée des itérations : 3 semaines.
• Type de contrat : Forfait.
• Intégration de 5 Systèmes d’Informations.
• Utilisateurs finaux particulièrement exigeants.
• Exigences de fiabilité élevée (vies humaines en jeu).

Outils agiles et non agiles utilisés

• Outils Scrum (Tableau des tâches, burndown chart).
• Intégration continue avec alarme sonore (Cruise Control).
• Planning Poker (estimations de charge).
• Outillage Atlassian : revue de code, Wiki, Bug Tracker, Tableau des tâches virtuel.
• Selenium.

Résultats de ce premier projet agile

• Relation de confiance établie très tôt avec le client (cf. transparence et visibilité).
• Conception lissée sur toute la durée du projet avec implication des utilisateurs finaux.
• Délais et budgets respectés.
• Rythme de travail soutenable.
• L'application en soi est conforme aux attentes fonctionnelles.

Degré d'agilité : Nokia Test

Avons nous une approche itérative ?

• Les itérations doivent être timeboxée à moins de 4 semaines : ok itérations fixées à 3 semaines.
• Les fonctionnalités doivent être testées et fonctionner à la fin de chaque itération : ok.
• L'itération doit démarrer avant que les spécifications soient exhaustives : ok.

Appliquons nous Scrum ?

• Vous savez qui est le Product Owner : Au démarrage, le product owner n'a pas pu être clairement identifié. Le Scrum Master a donc joué plus ou moins le rôle de Product Owner Proxy. Au bout de plusieurs mois, a force de sensibilisation et de patience, le rôle de Product Owner a fini par naître côté MOA.
• Il y a un Product Backlog priorisé en fonction de la valeur métier : Dès le démarrage, nous avions bien un Product Backlog mais la priorisation par valeur métier s'est révélée compliquée. Il a fallu attendre plusieurs mois avant que l'ordonnancement en fonction de la valeur ajoutée se mette en place.
• Le product backlog contient les estimations établies par l'équipe : oui.
• L'équipe génère les Burndown Chart et connaît sa vélocité : oui.
• Il n'y a pas de directeur de projet (ou autre responsable) perturbant le travail de l'équipe : Le Scrum Master a du préserver l'équipe des interruptions et pressions externes (directeur de projet, client).

Retour d'expérience détaillé

Choix des méthodes agiles

La décision d'adopter une approche Agile, s'est faite assez timidement et sans la nommer de peur de bouleverser trop d'habitudes parmi les acteurs du projet (d'autant plus qu'il s'agissait d'un premier essai à la fois pour le client et pour notre équipe). C'est pour cette raison notamment qu'aucun Product Owner n'a été désigné clairement au début. Le choix s'est porté sur une telle approche en raison des délais hors normes du projet et de la complexité du métier. Il fallait commencer à développer tôt avec rigueur, donner un maximum de visibilité au client dès que possible et offrir de la souplesse d'ajustement sur le besoin. L'approche Agile répondait et a répondu parfaitement à ces besoins.

Contractualisation agile au forfait

Nous avons établi le Product Backlog (PB) en amont du projet en fonction de notre connaissance du besoin. Nous avions au préalable participé à la phase expérimentale du projet, cet exercice n'a donc pas été trop compliqué (2 jours environ). Dans d'autres circonstances, nous serions sans doute parti du cahier des charges ou d'interviews client. Par précaution, nous avons rempli une colonne "hypothèses/couverture" du tableau du PB pour chaque exigence (User Story) de façon à se protéger compte tenu du caractère forfaitaire du contrat. Exemple : "en tant que conducteur je peux consulter mon planning afin de..." donne "hypothèse/couverture : 2 écrans simples, 1 complexe, alimentation des informations de planning par le SI amont". A partir de cette base, le contenu du PB a bien entendu changé en cours de route, nous avons donc procédé au principe de troc : le client ajoute une exigence en échange du retrait d'une exigence de même coût moins importante qui n'a pas encore été réalisée. Cette approche a permis de gérer les changements sans douleur, sans modifier le budget ou délais du projet et sans avenant.

Conception agile

La conception fonctionnelle a été lissée sur toute la phase de réalisation du projet. Moyennant tout de même un sprint 0 (un peu plus long que les autres) consacré à la mise en place de l'environnement de développement et d'intégration, des outils, des socles de développement et des bases de l'architecture. La conception fonctionnelle, bien que lissée a toutefois fait l'objet d'un mini "cycle en V" au sein de chaque itération. La première semaine était globalement ainsi découpée : 2 premiers jours d'ateliers de conception avec les utilisateurs finaux et AMOA, 2 jours de rédaction des spécifications/maquettage, 1 jour de relecture/validation des spécifications. Pendant cette première semaine, les développeurs non impliqués dans le travail de conception fonctionnelle et de rédaction réalisaient des développements (anticipés donc) sur des User Stories relativement mûres en termes de besoin. Evidemment, cette approche n'était pas idéale, mais avait le mérite de "rassurer" les décideurs. L'objectif du lissage de la conception était cependant atteint et a donc rendu possible un démarrage des développements très tôt. Ce qui a fortement contribué à affiner le besoin tout en tenant des délais particulièrement ambitieux. Plusieurs mois plus tard, nous avons pu renoncer à ce mini cycle en V pour réaliser les fonctionnalités de bout en bout au fil de l'eau de chaque sprint avec une livraison de la documentation mise à jour à la fin de chaque sprint.

L'effet démo à la première revue de sprint

Chaque itération s'est terminée par une démonstration faite au client sur un simple PDA de développeur pour la partie mobile et sur un PC pointant sur l'URL de notre serveur d'intégration pour la partie web de l'application. Nous n'avions pas grand chose à montrer sur les premières démonstrations mais ce fut une belle expérience. Un simple écran d'accueil peut avoir beaucoup de valeur en démonstration, il structure la suite. Les feedbacks ont donc été précieux. Le client a pu se rassurer en voyant que les choses avançaient dans le bon sens et nous aussi. Parfois il faut courir après les pré-requis, les décisions, les choix du client, etc. la démonstration a un effet très positif là dessus, en voyant que les choses avancent, le client s'implique, il se projette dans l'usage de l'application, il affine son besoin, etc. Rares ont été les feedbacks coûteux en termes de prise en charge, c'est l'avantage quand on découpe le temps en itérations courtes, on a peu de chance de mal interpréter un besoin creusé 2 à 3 semaines avant. Cette visibilité offerte au client à travers ces démonstrations a permis d'établir très tôt une relation de confiance précieuse mettant ainsi de l'huile dans les engrenages du projet.

Equipe agile

En termes de management, nous avons fait le choix d'appliquer à la lettre les principes Agile. Fini le "chef de projet" qui décide, dirige et contrôle. Nous avons donc supprimé toute hiérarchie au sein de l'équipe et appelé "coach" les profils expérimentés. Très peu d'ordres ont été donnés à l'équipe de développement, le Scrum Master avait pour principal objectif d'aider cette dernière à atteindre ses objectifs en la protégeant des évènements extérieurs perturbants et en levant les obstacles au plus tôt. Chacun a peu a peu trouvé sa place, s'est responsabilisé, participé aux décisions du projet pour finalement aboutir à une équipe auto organisée. J'ai plusieurs fois été agréablement surpris par les choix pertinents faits par l'équipe, par les actions d'amélioration proposées en rétrospectives (dont certaines ne me seraient jamais venu à l'esprit). Il est clair que l'équipe est souvent la mieux placée pour faire certain choix tant fonctionnels que techniques de part sa connaissance et maitrise des contraintes. L'autre surprise a été de voir naître si vite un esprit d'équipe à toutes épreuves que je n'avais jamais connu sur mes projets précédents, il est indéniable que les mêlées quotidiennes, le travail en binôme, les rétrospectives, favorisent et cultivent cet esprit si précieux pour la réussite du projet.

L'équipe était constituée de 70% de membres novices en .NET et développement mobile avant leur arrivée sur le projet. 40% des membres de l'équipe étaient des développeurs juniors.

La mêlée quotidienne Scrum

La mêlée est vraiment capitale, c'est un moment de communication intense, d'écoute, de décisions, de révélation des obstacles, de coordination, de renforcement de l'esprit d'équipe,...

Ce sujet mérite un paragraphe à part entière voire plus. Les 2 premiers mois, nous étions aux alentours de 7 personnes, les conditions étaient idéales. L'équipe a cependant mis du temps à vraiment tirer parti de la mêlée, à se l'approprier. Les débuts étaient très scolaires, chacun répondant mécaniquement aux 3 questions à tour de rôle en s'adressant au Scrum Master plutôt qu'à l'équipe. Peu à peu les choses ont commencé à se fluidifier, à se personnaliser. Jusqu'à l'heure de la mêlée.

Lorsque l'équipe a atteint sa taille maximale (15 personnes) nous avons poursuivi de la même façon sans trop déborder niveau timing. Etant donné que le tour prenait pas mal de temps tout de même, nous avons tenté de faire 2 équipes (donc 2 mêlées) mais on ne peut pas dire que ce fut concluant. Pour 2 raisons à mon sens. D'une part parce que l'équipe était plutôt sur dimensionnée par rapport au périmètre à couvrir (difficulté que nous aurions pu surmonter cf. "axes d'améliorations"), du coup il était difficile de faire 2 équipes suffisamment indépendantes. D'autre part, parce que j'ai séparé l'équipe juste avant de partir 3 semaines en congés (soit une itération) en me disant que c'était l'occasion de tester l'autonomie de l'équipe mais je pense que ça faisait trop d'un coup. Nous sommes donc revenu au mono scrum, puis l'équipe s'est réduite.

Travail en binôme / Pair Programming

Sans appliquer les principes XP de Pair Programming à la lettre (Programmeur + co pilote et échange du clavier,...) nous avons eu recours au travail en binôme. Dans 2 cas de figure principaux : la montée en compétence des nouveaux entrants (d'autant plus que beaucoup d'entre eux n'avaient jamais développé en .NET) et pour les développements pointus. Concernant les revues de code, nous avons préféré utiliser l'outil Crucible de la suite Atlassian qui permet de faire des revues de code à distance sans déranger le travail de l'autre (que l'on soit relecteur ou relu). Le travail en binôme a clairement contribué à faire rapidement monter en compétences des profils novices en .NET. Nous avons utilisé tardivement la technique du dojo de développement qui s'est révélé être un excellent moyen créer un esprit d'équipe, de capitaliser les astuces de développeurs (raccourcis de l'IDE par exemple), d'uniformiser le code, de faire monter en compétence les juniors.

Difficultés rencontrées

L'essentiel des difficultés concerne celles liées à l'adoption d'une approche Agile par un client, une équipe, un management non initiés. Etant le seul en début de projet formé et convaincu par la pertinence de cette approche dans le contexte du projet, j'ai du faire face à mes propres peurs et celles des autres. J'ai rapidement compris pour quelle raison, l'une des valeurs Agile est le "courage".

L'équipe par exemple a du pas mal bouleverser sa façon de travailler en développant par exemple verticalement plutôt que par couche, en se réunissant tous les jours pour parler de ses activités, en déplaçant les post-it au quotidien, en se confrontant au graphique d'avancement (burndown chart) et aux réactions du client en démonstration, en adoptant des nouveaux outils (comme l'intégration continue), etc. J'ai observé le phénomène connu d'une période d'enthousiasme ou de doute (selon les individus) suivie d'une période de perte de repères plutôt chaotique (un mal nécessaire) suivie de la période de stabilisation (les nouveaux repères sont en place). Aujourd'hui je pense pouvoir dire que plus personne ne souhaite retravailler à l'ancienne.

Mon management (au sens "mes responsables") a lui aussi du s'adapter à cette nouvelle façon de travailler. Plutôt sceptique au début, puis peu à peu convaincu. Le plus dur a été de faire un peu oublier les aspects contractuels et les excès de planification/anticipation à trop longs termes. J'ai du également servir de bouclier pour préserver l'équipe des pressions du management en réponse aux retards parfois constatés en cours de route (cf. burndown chart de chaque itération). L'ambiance a souvent été électrique mais la fin est globalement heureuse.

En tant que Scrum Master ayant poussé cette approche, je dois dire que ça n'a pas été facile tous les jours au début. Les enjeux du projet, le fait d’entraîner avec soi une équipe, son management et le client dans une aventure dont on ne connait pas le chemin exact à l'avance génère peurs et solitude. C'est une lourde responsabilité. J'avais beau avoir potassé et expérimenté les méthodes Agile auparavant, la pratique au quotidien avec de gros enjeux est une autre histoire. Mais je ne regrette rien (ni même mes quelques nuits d'insomnie), le jeu en vaut clairement la chandelle. Quoi de plus gratifiant qu'une équipe qui prend plaisir à travailler, qui donne le meilleur d'elle même, qu'un client satisfait qui veut continuer à travailler avec vous ?

Certains projet "pilotes Agile" échouent en raisons des difficultés que j'ai évoquées plus haut (et d'autres). On recommande donc souvent de faire appel à un Agiliste ayant déjà fait ses armes. Je suis assez d'accord avec ce point de vue, même si je trouve qu'apprendre de ses propres essais et erreurs est plus formateur. Lorsque les enjeux sont importants, il faut sans doute faire preuve d'humilité et s'en remettre à des personnes expérimentées (sans perdre la main pour autant bien sûr, il s'agit juste d'être à l'écoute des conseils donnés et de les appliquer soi même). Surtout si on rechigne à lire les nombreux ouvrages ou blogs sur le sujet bourrés de cas d'utilisation "vraie vie" des méthodes Agile.

Sur un plan technique, l'une de nos difficultés a également été de monter une Intégration Continue (IC) pour les développements Mobile. En effet nous ne sommes pas parvenus à aller au delà de la simple compilation du code. L'exécution des TU ne peut pas se faire ailleurs que sur un PDA, or les outils d'IC du marché ne couvrent actuellement pas ce besoin (en tout cas avec Windows Mobile). Nous avons bien sûr essayé de développer une IC maison mais le résultat ne fut pas probant. C'est vraiment regrettable car la majorité du périmètre du projet se situe sur le PDA.

Pour conclure ce paragraphe, je dirais qu'il est primordial d'y aller doucement (petit à petit) dans l'adoption des pratiques Agile afin d'éviter l'indigestion voir le rejet. Tant vis à vis de l'équipe que du management ou du client. De la même façon, mieux vaut expérimenter une approche Agile sur une équipe avant de s'attaquer à l'ensemble des troupes.

Outils utilisés

En fonction de notre budget, nous avons opté pour la suite "Atlassian" en termes d'outillage logiciel :

• Wiki confluence : dans ce wiki nous avons centralisé un ensemble d'informations à partager au sein de l'équipe (procédures d'installation d'un poste de dev, de récupération du code source à partir du SVN, bonnes pratiques de développement, tutoriaux rapides d'utilisation des outils maison,...). Nous avons ensuite utilisé le wiki pour communiquer avec le reste du monde (AMOA, client,...) en maintenant par exemple une page résumant le contenu de chaque version livrée, le planning global,...
• Outil de suivi des défauts JIRA : nous avons également utilisé JIRA pour le suivi des défauts détectés en interne et utilisé l'outil du client pour les défauts détectés par les testeurs AMOA/MOA. JIRA nous a également servi pour le suivi de l'avancement des tâches de développement. Chaque développeur ajustait chaque soir son "reste à faire".
• Outil Agile GreenHopper : GreenHopper nous a permis d'intégrer dans JIRA un tableau virtuel des tâches (en plus du tableau physique) et de générer automatiquement en temps réel le burndown chart.
• Outil de revue de code Crucible : voilà un bien bel outil (sous forme de plugin JIRA) connecté au gestionnaire de version qui permet de faire des revues de code à distance sans déranger le travail de l'autre (que l'on soit relecteur ou relu)
• Selenium pour les tests d'IHM web

Par la suite nous avons fini par nous passer de Green Hopper pour revenir exclusivement au tableau des tâches physique et un tracé "artisanal" des graphiques d'avancement. Avec Green Hopper, les interactions humaines étaient réduites et les "reste à faire" des tâches pas toujours renseignées malgré les relances et sensibilisations.

Envie d'aller plus loin ?

Voici quelques liens pour développer vos compétences agiles :

• Introduction aux méthodes agiles et Scrum
• Cours gratuit de gestion de projet agile
• Ebook gratuit sur les 8 leviers de réussite de la gestion de projet agile
• Formations aux Méthodes Agiles
• Article associé : La récompense du ScrumMaster