Méthode Agile multi-équipes ou « l’histoire vécue d’une adaptation au monde industriel »

Posté par

Médiane Système

Propos recueillis auprès de Sébastien BUSCHINI – Responsable d’Affaires à Médiane Système

Un projet complexe 

Missionnée par ICE pour le compte d’un acteur du transport d’énergie, Médiane Système a contribué au développement d’un système de contrôle commande de poste électrique et a procédé à l’évolution d’équipements de protection de réseau existants dans les postes haute tension. Les fonctionnalités d’un système de contrôle commande sont gérées par un ensemble de composants matériels et logiciels complexes, le système pouvant surveiller plusieurs niveaux de tensions simultanément. Le projet a consisté à étendre les fonctionnalités et les types de postes adressés par le système.

Le rôle de Médiane Système a été de spécifier, développer et tester une grande partie du logiciel de contrôle commande. Les spécifications des nouvelles fonctionnalités n’étant pas complètement finalisées au lancement du projet, les équipes de Médiane Système ont dû s’adapter en cours de projet, en fonction des besoins, des campagnes d’intégration et des interactions avec le client.

Une première phase en mode 100 % Agile

Selon les bonnes pratiques, la méthode Agile est conçue pour des équipes projet de 5 à 10 personnes. Or, le volume de travail sur ce projet nécessitait une trentaine de personnes.
Pour répondre à cette problématique, nous avons organisé le projet en 4 équipes de 7 à 8 personnes. Chaque équipe s’est vue attribuer son propre périmètre et son Product Owner chargé de faire une synthèse, de vérifier si le livrable s’intégrait bien au système et d’assurer la cohérence de l’ensemble.
Les Product Owners ont donc segmenté le travail dans des Users Story (ou fiches de travaux) pour les présenter aux équipes de manière ordonnée. Les équipes ont ensuite réalisé des Sprint d’un mois pendant lesquels elles consultaient les Users Story prioritaires et définissaient celles pour lesquelles elles s’engageaient à les finaliser dans le délai imparti. À la fin de cette période mensuelle, chaque équipe livrait le logiciel avec les fonctionnalités qu’elle s’était engagée à réaliser.
Une fois le logiciel reçu, le Product Owner testait ce qui lui avait été livré et en parallèle il définissait le contenu du Sprint suivant. Le but de cette organisation était de gérer un processus itératif. Ainsi, les équipes ont convergé progressivement sur les fonctionnalités globales et élaboré le logiciel brique après brique pour arriver à la version finale. Le 240_f_289329250_2epz6zi5ajsvfupazxcaxhfqdbabcoruProduct Owner pouvait également ajuster les priorités de livraison en fonction des besoins du client sans désordonner les travaux réalisés par de trop fréquents changements de cap.
Chaque matin les équipes se réunissaient en « Daily Meeting » de 15 minutes durant lesquelles chacun présentait au reste de l’équipe ce qu’il avait réalisé la veille, ce qu’il avait prévu de réaliser durant la journée et les éventuelles difficultés auxquelles il faisait face. Le Daily Meeting favorisait la production en aidant quelqu’un de bloqué et en choisissant de prioriser certaines tâches. Le Product Owner pouvait également participer à cette revue pour suivre l’avancement du projet et le cas échéant apporter son aide sur la définition des besoins.

Pourquoi avoir choisi la méthode SCRUM (une méthode Agile) ?

Le périmètre fonctionnel du projet était réputé complètement exprimé dès le début du projet. Le projet aurait donc théoriquement pu être réalisé dans un cycle en V classique. Cependant, de nombreux détails restaient en discussion ou nécessitaient d’être testés ou clarifiés avant leur implémentation définitive.

La méthode Agile nous a donc parue plus adaptée par la souplesse qu’elle apporte à ce type de projet :

  • La méthode agile permet de traiter les travaux au fur et à mesure avec une grande capacité d’adaptation en cas d’imprévu, tout en gardant une bonne maîtrise des principaux enjeux projet (tenue des jalons, qualité technique, etc…). Comme elle repose sur une collaboration avec le client, elle permet d’instaurer une confiance et une compréhension réciproque qui évite « l’effet tunnel » qu’on peut constater sur certains développements suivant le cycle en V.
  • La méthode introduit également les notions de planification et de démonstration / rétrospective, qui permettent aux équipes d’adhérer pleinement aux objectifs du projet, de montrer la qualité du travail produit, et d’inscrire l’action de chacun dans une démarche d’amélioration continue. Tous ces éléments amènent les participants à se sentir impliqués et moteurs dans un souci constant de productivité et de service.
  • Enfin, l’un des éléments très important d’un projet en mode Agile est qu’il facilite l’intégration des collaborateurs dans les équipes. Dans un projet vaste et complexe, la montée en compétence est généralement longue et pénalisante. La méthode Scrum, et son approche par équipe permet d’intégrer les nouvelles ressources avec bienveillance et efficacité : chaque personne de l’équipe étant responsable des engagements collectifs, un nouveau membre est accompagné pour qu’il puisse participer pleinement au projet. Il est d’ailleurs très intéressant de voir comment chaque équipe a développé ses propres pratiques. L’un des enjeux du projet étant de coordonner tous ces efforts pour que la production reste homogène et cadrée malgré cette diversité.
  • Au final, et pour la comparer à une méthode plus classique, la méthode Agile a permis de gagner un temps de contractualisation conséquent estimé à plusieurs mois grâce à la segmentation des éléments à réaliser dès le démarrage du projet.

sans-nom-13

Une seconde phase en mode Agile adapté

Quelles ont été les limites de cette méthode ?

Malgré l’organisation justifiée de la première phase, différents dysfonctionnements sont apparus et ont nécessité de repenser l’organisation projet. Un bilan à mi-parcours a permis d’analyser les causes et de mettre en place les solutions adaptées.

Quels problèmes avez-vous constaté par rapport à l’organisation et comment avez-vous fait pour les résoudre ?

Le premier problème a été relatif à la charge de travail des Product Owners. En effet, entre la spécification de ce qu’il y avait à réaliser, la réception des logiciels et leur validation, la synchronisation de ces logiciels entre eux, les qualifications avec le client, les traitements des anomalies et les traitements des différents besoins, le Product Owner n’avait pas la capacité de traiter tout ce qu’il y avait à faire pour alimenter correctement les équipes de développement. La solution a consisté à créer une équipe système intermédiaire au sein du projet en y réaffectant une partie des développeurs. Cette équipe système s’est substituée aux Product Owners et a pris en charge le pilotage des équipes.

Le second problème est lié à la complexité et la quantité de modules logiciels, la gestion des multiples versions et la difficulté à garantir leur cohérence.
La solution à cette problématique a été la mise en place d’une équipe dédiée à l’intégration avec pour objectif d’assurer et d’adapter chaque livraison en fonction des besoins du client.

Enfin, le dernier problème est lié au décalage des Sprint livrés par les différentes équipes et à leur périodicité trop longue (1 mois au départ). Les équipes projet ont donc instauré une livraison commune toutes les deux semaines, centralisée par l’équipe d’intégration.

Cette réorganisation nous a conduits à réduire l’utilisation du mode Agile en conservant toutefois un mode itératif et réactif avec une boucle de contrôle pour l’ensemble du projet. Cette nouvelle organisation s’est révélée particulièrement efficace et a permis d’améliorer notablement le rythme et la qualité des livraisons.

« Au final, ce projet est assez emblématique du savoir-faire de Médiane Système et nous pouvons être fiers de notre réactivité, de notre adaptabilité et de notre capacité à mettre en place des solutions efficaces. À ce titre, je tiens à remercier les équipes techniques, les coordinateurs et les ingénieurs qualité, pour leur apport et leur implication tout au long du projet. »