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

Florent Lothon

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.

Méthodes agiles en action

Voici la vidéo tournée sur le projet.

Envie d'aller plus loin ?

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

A propos de l'auteur

Florent Lothon

Expert de terrain en gestion de projet et management d'équipe. Florent fait partie des pionniers dans l'usage des méthodes agiles sur des projets à forts enjeux en France dès 2007. Co-auteur du livre "Devenir une Entreprise Agile".

  • Tres bon retour d’expérience.
    Merci pour ce partage

  • Bonjour et merci pour ce retour. Etant en début de projet sur de l’innovation, ces obstacles de début de projet me parlent énoooormément. Ca fait du bien de voir qu’il n’y a pas de fatalité, meme si l’ambiance est électrique. En espérant faire aussi bien.

  • Bonjour,

    J’ai une question pratique sur la réalisation des développements. Je vois que vous aviez affiché des maquettes d’écrans et spécifications détaillées et que les stories étaient donc assez précises.
    Pour le mini cycle en V c’est clair vous les réalisiez au début de sprint.

    Mais quand vous avez quitté cette méthode, a quel moment été réalisé ces maquettes?
    Est ce que les développeurs les faisaient au début de leurs stories et c’était validé par le PO proxy? Validé par le client? Pas validé avant la revue démo en fin de sprint. Dans ce cas comment gérez vous les demandes de modification lors de la démo (qui peuvent aller d’un simple changement de couleur a l’utilisation d’un composant complètement différent).

    Ou est ce que c’était une tache annexe faite en avance de phase par un développeur?
    Ou est ce que c’était fait par le POproxy ou client lors de l’écriture de la story? La story ne pouvant entrer dans le backlog seulement une fois ces détails précisés?

    Merci

    • Bonjour Val,

      Navré de vous répondre si tardivement. J’avais quelque peu délaissé mon site et les commentaires ces deniers temps.

      En fait, même dans la « règle de l’art » agile, le degré de détail de la conception au sein du sprint ou en amont (du moment que c’est au fil de l’eau et non pas une conception d’ensemble à l’avance) peut varier selon le degré d’exigence du contexte.

      Dans notre cas, certains écrans (maquettes) devaient être validés par une équipe chargée de la sécurité ferroviaire accompagnée d’une ergonome, avec parfois des tests en cabine de simulation à réaliser. Autant dire que le degré d’exigence sur l’interface utilisateur (en plus de la technique sous le capot) était élevée. D’où le degré de détail atteint parfois en amont du sprint. Pour d’autres écrans, moins sensibles, leur conception détaillée se faisait pendant le sprint avec validation à la fin du développement, pendant ou en fin de sprint, par le PO ou Proxy sans nécessairement une maquette préalable.

      Les écrans affichées sur les murs étaient aussi le plus souvent des écrans issues des sprints précédents (des captures d’écran du « vrai produit »). Avoir une vue d’ensemble des écrans construits au fur et à mesure facilite la « vision » produit d’ensemble, aide à conserver la cohérence d’ensemble et facilite la communication la plus efficace (le face à face) et les interactions humaines (bien meilleure que des échanges de mail).

      Chaque retour en revue était ajouté au Product Backlog avec recours au principe de troc en cas de changement (pour sécuriser autant que possible le délais et budget). L’agilité, ce n’est pas « changer d’avis tout le temps ». Le tout priorisé par le PO ou Proxy.

      Je n’ai pas compris les dernières questions mais j’espère que cette réponse vous éclaire un peu.

      Amicalement,
      Florent

  • Bonjour le témoignage de la mise en pratique dans une grande entreprise m’interresse au plus haut point, par rapport à la difficulté de mise en oeuvre de la méthodo dans grande structure, car si je suis convaincu sur des projets de périmètre restreint et mono-appli, je suis circonspect dans les grosses structures

    Ce qui me choque dans l’exemple, c’est l’absence de PO identifié et ce rôle supporté par le Scrum master…. Pas de PO légitime, donc pas d’arbitrages possible par rapport aux différents utilisateurs / demandeurs.

    Intégration de 5 systèmes d’information … comment sont intégrées les recettes et recettes transverses au sein de ces 5 SI ? Quid des adhérences éventuelles ?
    Agile/Scrum ne prévoit pas de recette explicite, seulement la « definition of done » ?

    Enfin « les interactions humaines [sont] bien meilleures que des échanges de mail ».
    Certes … sur l’instant. Mais les specs « de tradition orale » au bout de 6, 12, 18 mois, une fois que l’équipe est dissoute, on retrouve comment la règle de gestion en cas de problème ?

    • Bonjour Norbert !
      On parle ici d’un tout premier projet agile pour mon équipe de l’époque, mon client, ma hiérarchie et moi même. Projet démarré en 2008 à l’époque où je me sentais très seul dans la pratique de l’agilité sur des projets à forts enjeux. Les conditions idéales sont rarement réunies sur un premier projet agile.
      Est-ce qu’on renonce pour autant si on ne dispose pas d’un vrai PO ? Pas de mon point de vue (même si je déconseille l’agilité dans certains cas bien spécifiques). D’ailleurs, c’est en démontrant les bénéfices concrets de Scrum qu’on a pu aller plus loin par la suite, avec enfin un vrai et super PO.
      Pour ce qui est de la documentation, personne n’a dit qu’elle n’était pas écrite. Ce n’est pas parce qu’on privilégie la communication orale qu’on ne trace pas le fruit de ces discussions. Bien au contraire. La documentation est rédigée au fil de l’eau et intégrée à la définition de terminé.
      Pour les tests, l’intégration se fait au plus tôt et au fil de l’eau, tout comme les tests eux même. Quitte à commencer avec des « bouchons » quand le SI accosté (parfois réalisé par des équipes non agiles) n’est pas encore dispo de son côté.
      Est-ce plus clair Norbert ?

  • BOUGUERRA KHALED dit :

    Merci pour le partage et bon travail

  • Bonjour avez vous le nom de l’application qu’il on créé ?

  • Bonjour,

    je vous remercie pour votre retour d’expérience si enrichissant. En fait, je suis doctorante en sciences de gestion, je travaille sur la thématique de l’agilité du contrôle de gestion en temps de crise ». et je sollicite votre avis sur ce sujet, et j’espère que vous pourriez m’éclairer et guider vers des pistes de recherche pour stabiliser ma question de recherche.
    Bien entendu, mes principales questions sont les suivantes:
    – peut-on déjà tolérer parler de la notion « contrôle de gestion agile » ou « l’agilité du contrôle de gestion »?
    -dans quelle mesure peut on considérer que le contrôle de gestion est une variable indispensable pour développer l’agilité au sein de l’entreprise?
    -Comment les entreprises peuvent elles développer et mettre en œuvre des systèmes de contrôle de gestion agiles pour faire face aux périodes de crise?

    je vous remercie d’avance, et je suis toujours disponible pour toute proposition de votre part.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Vous voulez d'autres contenus de qualité ?

    Découvrez ces articles

    >