Introduction :

Le but de cet article est de décrire un nouveau mode de réalisation de projet, à savoir le mode « dynamique », que j’ai eu l’occasion d’expérimenter dans le cadre d’une mission chez un client de NEOXIA.
 
L’article est structuré comme suit:

  • Contexte
  • Mise en pratique des fondements du mode agile et adaptation au contexte du projet
  • Retour d’expérience
  •  
    Dans le but de respecter la confidentialité des projets clients, nous appellerons l’application « Vega » et l’équipe de développement « Equipe Swift ».

    Clé de lecture :
    En général ce qui est écrit en orange désigne un point de vigilance à observer pour que le projet ne soit pas impacté par le changement d’organisation.
    Dans le chapitre « Mise en pratique des fondements du mode Agile et adaptation au contexte du projet », chaque sous-titre correspond à un principe général ou fondement, de la méthodologie agile. Les points de vigilance mis en exergue à la fin de chaque paragraphe, correspondent aux dérogations en vue de l’adaptation au contexte du projet.

    Contexte :

    C’est dans le cadre d’un projet de refonte de l’application web « Vega », que se pose la question du changement de méthodologie.

    La refonte doit se faire à plusieurs niveaux :

    • Refonte technologique : de Flex vers HTML 5
    • Refonte ergonomique : proposer aux utilisateurs une IHM plus moderne et intuitive
    • Refonte fonctionnelle : revue des règles de gestion et ajout de nouvelles fonctionnalités

    Pourquoi le mode agile ?

    1. Impliquer l’utilisateur dès le début du projet :

    L’un des objectifs principaux de cette refonte est de créer de l’adhésion autour de « Vega » en se rapprochant le plus possible des pratiques et des besoins du terrain. En effet, les pratiques des utilisateurs sont tellement différentes et le processus métier mal défini, que l’utilisation de l’application est loin d’être fluide pour la grande majorité des utilisateurs.

    La première étape est, avant tout, d’identifier, de façon précise, le processus métier en échangeant avec les utilisateurs ; de repenser « Vega » en conséquence ; et, enfin, d’impliquer un panel représentatif d’utilisateurs, de façon régulière, dans le but de valider chaque fonctionnalité implémentée.

    1. Etre réactif au changement :

    Le projet a un caractère politique. Les enjeux sont tels que l’évolution du périmètre est probable et les demandes urgentes assez fréquentes. L’équipe doit faire preuve de réactivité.

    1. Motiver l’équipe de développement :

    Depuis la mise à disposition de la première version de « Vega », l’application est tombée dans l’oubli. Avec l’arrivée de la nouvelle maitrise d’ouvrage du projet et sa volonté de créer un changement significatif au niveau de « Vega », il faut remotiver les troupes, créer une cohésion de groupe et permettre aux membres de l’équipe de travailler de façon plus interactive et dynamique.

    L’équipe de développement ne demande que ça : expérimenter un nouveau mode de fonctionnement qui lui permette d’avancer plus rapidement, sans s’encombrer des éléments de l’environnement projet.

    Quelles sont les autres contraintes ?

    • La mise en production de la nouvelle version de l’application est soumise à une contrainte majeure : une date de mise à disposition incontournable pour le bon déroulement d’une campagne biannuelle.
    • L’application fait partie d’un dispositif complexe avec des applications interdépendantes gérées par d’autres équipes. Un planning de versions est généralement établi en début d’année pour permettre aux applications de maintenir/faire évoluer leurs échanges.

    Si les fonctionnalités demandées par l’utilisateur représentent des impacts potentiels sur d’autres applications du domaine, une étude d’impacts doit être menée en amont.

    Si cette étude révèle la nécessité d’effectuer des développements sur d’autres applications, le choix de la version concernée en sera impacté.

    => Le mode de fonctionnement de l’équipe « Swift » ne doit pas perturber le planning de version.

    • Les responsabilités de développement, intégration, qualification et diffusion sont confiées à 4 équipes distinctes voire distantes. Ces équipes appartiennent à des structures différentes et ne relèvent pas des mêmes responsables hiérarchiques.
    • Par ailleurs, elles ont d’autres projets dans leurs périmètres respectifs. Par conséquent, le plan de charge de chaque équipe doit être établi en début d’année en accord avec leurs hiérarchies respectives.

    => Le mode de fonctionnement de l’équipe « Swift » ne doit pas impacter l’organisation et le fonctionnement des autres équipes (qualification/exploitation/ etc).

    => L’équipe de qualification fonctionnelle doit être impliquée le plus en amont possible afin d’être en capacité d’intervenir le moment venu.

    Mise en pratique des fondements du mode Agile et adaptation au contexte du projet :


    schema_mode_dynamique
    Légende :
    – L’abréviation « MOA Strat » désigne la maitrise d’ouvrage stratégique du programme ; « Qualif » désigne l’équipe de qualification fonctionnelle et/ou de bout en bout du dispositif ; « Diff » désigne l’équipe de diffusion du programme, elle assure la fonction d’assistance aux utilisateurs telles que l’élaboration et/ou la mise à disposition de toute documentation qui leur est utile ; « Intégr » désigne l’équipe d’intégration qui teste le déploiement de la solution, le documente et l’intègre dans un paquage prêt à être déployé.

    L’équipe « Les individus et leurs interactions, plus que les processus et les outils » :

    1. L’équipe « Swift » est très motivée. Ses membres ont déjà travaillé ensemble dans le passé, notamment sur la version précédente de l’application, mais en mode classique. Depuis le début du projet, l’équipe « Swift » effectue une mêlé quotidienne.
    2. Les sprints durent 4 semaines. Chaque sprint commence par une réunion de planification d’itération et se termine par une revue de sprint.
    3. Afin de pouvoir permettre au client de tester les fonctionnalités développées à la fin de chaque sprint, l’équipe « Swift » prend en charge l’intégration des versions intermédiaires de l’application. En mode classique, cette activité est assurée par une équipe dédiée après la phase de développement.
    4. Par ailleurs afin de permettre la qualification technique de chaque fonctionnalité développée, cette dernière est testée par l’équipe « Swift ». La version est ensuite installée en environnement de recette.

    Les points 3 et 4 permettent à l’équipe « Swift » d’être indépendante pendant la phase de réalisation.

    => Une fois la version finalisée, l’équipe d’intégration intervient pour packager l’application et rédiger une documentation technique.

    => Après l’intégration de l’application, l’équipe de qualification fonctionnelle procède à la qualification de l’application, puis à la qualification de bout en bout du dispositif global.

    L’application « Des logiciels opérationnels, plus qu’une documentation exhaustive » :

    Afin de respecter le principe d’agilité, la priorité est accordée à la réalisation effective du produit, plutôt qu’à la rédaction de la documentation. Ainsi, pour tous les sprints, à l’exception du dernier sprint, c’est à l’issue du développement de chaque évolution et de sa validation par le client, que l’équipe « Swift » livre un document de spécifications.

    => Néanmoins, étant donné que c’est une autre équipe qui doit réaliser non seulement la qualification fonctionnelle de l’application mais également la qualification de bout en bout de l’ensemble du dispositif, il a été demandé à l’équipe « Swift » d’élaborer des spécifications fonctionnelles détaillées selon le modèle et avec le niveau de détails habituels (cycle classique).

    => Afin de permettre à l’équipe de qualification de préparer ces scénarios de tests en respectant les délais impartis, une documentation détaillée lui est fournie à l’issue de chaque sprint. Pour le dernier sprint, la documentation est livrée avant la réalisation (en début de sprint).

    => Si les équipes de qualification et de diffusion ne sont pas invitées à la réunion de planification de sprint, elles sont invitées à la revue de sprint pour être informées des fonctionnalités mises à disposition au niveau de l’environnement de recette.

    La collaboration « La collaboration avec les clients, plus que la négociation contractuelle » :

    Le chef de projet de la maîtrise d’ouvrage représente le client dans cette organisation. Il est impliqué et disponible. Il intervient régulièrement pendant la phase de réalisation, notamment pour répondre aux interrogations de l’équipe en temps réel via un fichier de question/réponse mis en ligne sur une application web libre (Redmine).

    De façon globale, une revue de sprint est prévue à la fin de chaque sprint.

    Par ailleurs, afin de s’assurer de l’adéquation entre ce qui est développé, et les attentes des utilisateurs finaux, ces derniers participent à quelques revues de sprint (environ tous les deux sprints).

    => Toujours dans l’optique d’impliquer l’équipe de qualification fonctionnelle le plus tôt possible, cette dernière a accès à Redmine, et peut donc suivre l’avancement de la réalisation.

    L’acceptation du changement « L’adaptation au changement, plus que le suivi d’un plan » :

    La maitrise d’ouvrage collabore par ailleurs avec un expert en ergonomie dont le travail se poursuit pendant la phase de réalisation. Cela permet de proposer à l’équipe « Swift », au début de chaque sprint, une maquette plus aboutie de ce qui est demandé.

    Les développements doivent donc s’adapter aux changements survenus sur la maquette.

    => Néanmoins, afin de s’assurer de la capacité de l’infrastructure à tenir la charge et à maintenir le niveau de performance exigé, surtout dans le cadre d’une refonte complète, certaines étapes sont incontournables : Tests de montée en charge. Etant donné les contraintes de planning, ces tests sont prévus avant la fin de la qualification.

    Les scénarios des tests de montée en charge se basent sur les fonctionnalités élémentaires ou phares de la version. Ces fonctionnalités doivent être qualifiées avant le début des TMC. Par conséquent, l’équipe « Swift » doit développer ces fonctionnalités en priorité. Pour ce faire, le client attribue un ordre de priorité à chaque évolution : « 1 » faisant référence à la priorité la plus élevée et « 5 » à la moins élevée.

    Retour d’expérience :

    Sur ce projet, j’ai fait office de directrice de projet sur la partie du dispositif sous la responsabilité de l’entité d’appartenance :

    • Pilotage
    • Coordination
    • Gestion des équipes

    Coordonnatrice de la campagne biannuelle :

    • Pilotage des tests
    • Coordination des actions des différentes parties prenantes du dispositif

    Mon rôle avant la phase de réalisation :

    Ma responsabilité avant la phase de réalisation était de :

    • Proposer une organisation compatible avec la volonté de devenir « plus agile » tout en respectant les contraintes du projet.
    • Partager la nouvelle organisation avec toutes les parties prenantes du projet.
    • Proposer un planning complet pour la refonte de l’application, qui soit cohérent avec les plannings des autres applications du dispositif.

    Mon rôle pendant la phase de réalisation :

    Ma responsabilité pendant la phase de réalisation est de :

    • Veiller au respect des principes validés en amont
    • Assurer le suivi du planning
    • Gérer les risques

    Le rôle du directeur de projet en titre après la réalisation :

    Ma responsabilité après la phase de réalisation sera de :

    • Piloter l’intégration, la qualification fonctionnelle et ce qui en résultera de versions correctives et la diffusion

    Avancement du projet :

    Le projet n’est pas encore arrivé à son terme. Les sprints sont terminés. La qualification fonctionnelle est en cours.

    L’équipe de développement a respecté, autant que faire se peut, le fonctionnement en mode agile. L’implication des autres équipes, de façon ponctuelle, ne l’a pas compromis.

    L’appellation « mode dynamique » vient du fait que le principal apport en terme d’agilité dans le mode de fonctionnement habituel pour ce dispositif, a consisté à dynamiser le processus.

    Il s’agit, selon moi, d’un mode de fonctionnement transitoire permettant de garder les avantages du mode classique pour sécuriser le projet, tout en le dynamisant, en attendant d’atteindre un niveau de maturité suffisant pour passer au mode agile.

    Source des icônes du schéma :
    Freepik