Exemple concret de sauvetage

Voici l’étude d’un cas réel que nous nommerons le projet X de l’entreprise X. Il permet de comprendre le danger réel que fait courir une conception inadaptée aux développements modernes et de prendre conscience de l’efficacité de la méthode RAD.

L’entreprise X disposait d’une grande expérience des développements classiques et bénéficiait des services d’une cellule spécialisée en méthode (Merise, SDM/S). Le projet X se composait d’une application nomade de saisie d’informations, d’un sous-ensemble communication et de deux applications centralisées de gestion et d’exploitation des données.

L’équipe prévue pour ce projet stratégique se composait d’un directeur de projet (grande école) et de 4 chefs de projet. Un des chefs de projet avait la responsabilité de l’architecture technique et des communications. Les trois autres chefs de projet " fonctionnels " étaient chargés de réaliser la conception générale et la conception détaillée.

Durant la programmation, chaque chef de projet " fonctionnel " devait voir son équipe s’étoffer de trois ou quatre développeurs. A son point d’orgue ce projet allait donc compter plus de quinze personnes.

L’entreprise X engagea des chefs de projet et débuta la phase d’expression des besoins. Le but était de respecter le cycle merisien de la " courbe du soleil ". La conduite du projet suivait la méthode SDM/S. Les premières étapes consistaient en une modélisation organisationnelle de l’existant. Elles devaient aboutir à une modélisation conceptuelle de l’existant, puis orienter la modélisation conceptuelle du nouveau système. Ensuite, étaient prévues les étapes de modélisation organisationnelle et finalement de modélisation logique qui devaient aboutir à la description des programmes et de leurs fonctionnalités. C’est à partir de ces dossiers que les développeurs pourraient programmer.

Le raisonnement était sans faille, c’était intellectuellement aussi beau qu’une symphonie. La cellule méthode comptait observer l’esthétisme des passages de relais.

La date butoir était fixée à fin décembre de l’année suivante (18 mois). Chacune des cinq premières étapes devait prendre environ deux mois, quatre mois étaient prévus pour la réalisation, deux mois pour les tests et trois mois pour le site pilote. Avec un petit effort, cela devait entrer.

Dans la réalité, l’outil de base disponible pour produire les livrables de ces étapes, n’était pas un AGL, mais ABC Flow charter (c’est mieux que PaintBrush). Les difficultés qui résultèrent de ce choix aboutirent à l’utilisation d’Oracle Designer sous une émulation Unix. Les postes de travail étaient sous-dimensionnés, à base d’écrans de 14 pouces. Il était impossible de visualiser plus de quatre entités simultanément. Il est possible de résumer ces conditions par un seul mot : l’Enfer. Afin d’avoir une vue d’ensemble, les flux étaient dessinés sur les murs. Cette initiative, haute en couleur, me valut, de la part de la secrétaire, le surnom de " Picasso ". Il me resta jusqu'à la fin du projet.

La conception commença, les utilisateurs étaient disponibles et participèrent. Les premiers retards de formalisation furent mis sur le compte des vacances. Après cinq mois, on gribouillait toujours de " l’organisationnel existant ". Le sixième mois fut une période d’abattement psychologique. Le découragement suintait des modèles, la révolte grondait. Elle s’exprima au bout du neuvième mois.

Le directeur de projet n’était pas engagé concrètement et techniquement dans la production des livrables inutiles qu’il imposait.

A ce point, la moitié du temps de développement avait été gaspillé. En coulisse (radio café), la charge était estimée au double de ce qui était officiellement prévu. Sur le plan modélisation, c’était le néant. Seules des informations générales existaient sur papier. Très intéressantes pour produire un rapport, elles s’avéraient inutilisables dans le cadre de la précision requise pour l’indispensable modélisation des données et des traitements.

Il devenait évident que les chefs de projet étaient individuellement incapables de produire des dossiers pour quatre programmeurs. Alors que la méthode aurait (déraisonnablement) impliqué de doubler leur nombre. Il était tout aussi clair que le nombre d’analystes et les contraintes de l’interface graphique rendaient impossible un tel exercice de formalisation sur papier.

La compagnie changea alors de statut, le budget développement fut réduit de moitié et l’ensemble des intervenants fut prié de donner dans la productivité. Les propriétaires de places confortables furent promus locataires de sièges éjectables et s’intéressèrent donc de plus près à l’avancement du projet. Le " super " directeur du projet et le chef de projet technique furent écartés.

A ce point, un marché fut proposé aux trois chefs de projet survivants. Il leur fallait terminer eux-mêmes, dans le délai initial et avec le budget restant, ou se démettre. Heureusement l’un d’eux avait l’expérience d’une méthode de développement rapide. La cellule méthode, consternée, se retira, considérant que le projet courrait désormais à sa perte.

Deux des chefs de projet savaient développer et acceptèrent la réalisation. Le troisième reprit la direction du projet et s’occupa plus particulièrement de l’administration des données. Une secrétaire fut allouée pour faciliter le minimum de formalisation à maintenir. Une ressource additionnelle, excellent développeur, vint compléter l’équipe de conception-réalisation. Elle se lança alors dans la modélisation des données suivie d’un prototypage actif.

Pour garantir un déploiement complet, sécurisé par une exploitation en site pilote d’au moins trois mois, il fut décidé de donner des priorités aux fonctionnalités et de livrer en trois lots successifs. Les utilisateurs étaient sollicités plusieurs fois par semaine pour participer à la création des prototypes. Les participants se rendirent alors compte de l’inutilité des documents initialement et chèrement produits, qui furent totalement abandonnés.

Deux mois plus tard, des présentations de l’application en cours de développement étaient réalisées (toutes les deux ou trois semaines). Ces Focus mobilisaient environ une vingtaine de personnes qui critiquaient et enrichissaient l’application, fonctionnalité par fonctionnalité.

Une spécialiste en documentation réalisa alors la documentation utilisateur.

Une première version de l’application comprenant environ 60 % des fonctionnalités initiales fut stabilisée en six mois. Le mois suivant fut consacré au test d’intégration et de communication. L’exploitation du site pilote démarra sans trop de difficultés. Le déploiement s’effectua normalement trois mois plus tard. La cellule méthode ne comprit pas comment nous avions pu réussir et mit cela sur le compte du hasard (qui fait bien les choses). Les utilisateurs et les informaticiens furent récompensés par deux jours de fiesta. Happy ending !

Il faut tirer plusieurs leçons de ce projet :

  • Premièrement, il fait apparaître qu’une méthode hautement sécurisante et structurée conduit à l’échec ;
  • Deuxièmement, il démontre qu’un petit nombre de ressources performantes et motivées (bien payées, entre autres) peut sauver une situation où une équipe nombreuse aurait échoué par enlisement.
  • Pour une cellule méthode, l’information principale à tirer d’une telle expérience se situe dans les techniques de modélisation à employer.

    On ne peut concevoir, modéliser, gérer, une application sous Windows en architecture client-serveur comme une application classique. Si l’application couvre plusieurs domaines ou mélange de l’opérationnel et du décisionnel, ces spécificités doivent être prises en compte. Elles nécessitent d’utiliser des techniques de modélisation adaptées à chaque cas :

  • Dans une partie de l’application, la difficulté vient de la modélisation des données ;
  • Dans une autre partie, ce sont les flux qui sont difficiles à cerner ;
  • Ailleurs, la complexité des traitements s’avère le problème majeur. Dans tous les cas, les formes de modélisation doivent être adaptées ainsi que les techniques de conduite de projet.


  • www.RAD.fr ® © Jean-Pierre Vickoff