Au Pied Levé - À Main Levée

APL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.

■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

• RAD la première méthode Incrémentale Itérative Adaptative (Agile)
• Site historique de la méthode RAD

Jean-Pierre Vickoff présenté comme un expert par Jean-Marc Berlioux alors Rédacteur en chef à Bouhot Legendre (Gartner Group) éditeur de « Informatique Professionnelle » lors d'une interview vidéo sur la méthode RAD.

Dans cette vidéo de 1997, il est montré que la méthode RAD (1991) proposait l’ensemble des pratiques dont ont découlé les méthodes suivantes (ASD, FDD, XP et Scrum) qui se référencent du qualificatif d’Agile depuis 2001, à savoir :

• un cycle itératif incrémental adaptatif,
• des variables d’ajustement (périmètre),
• la dynamique applicative par l’utilisateur (priorisation),
• l’adaptation permanente et la validation de l’utilisateur,
• la présence d’un animateur,
• une équipe de profil unique (concepteur-développeur),
• une organisation consensuelle du développement,
• l’affichage mural des informations du projet,
• une phase de construction proche de l’eXtrême Programming,
• une salle dédiée, réunions quotidiennes matinales, Focus (Show), rétrospectives,
• etc.

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Jean-Marc Berlioux

Les projets informatiques sont le plus souvent soumis à deux types de contrainte :

• Les besoins dune part ne sont pas totalement identifiés
• Et les temps de développement doivent être réduits

La méthode dénommée « Développement Rapide d’Application » ou « RAD », permet en principe de répondre à ces deux types de contrainte.

Pour en parler, nous avons invité Jean-Pierre Vickoff.

Jean-Pierre Vickoff est expert en développement rapide d’application. Il a exercé ses activités en Amérique du Nord, et en France. Il est l’auteur d’un livre qui s’appelle « RAD », publié aux Éditions Macmillan.

Alors, Jean-Pierre, est-ce que vous pourriez nous dire ce qu’est le RAD, en résumé ?

Jean-Pierre Vickoff

Pour définir le RAD, il est préférable de définir d’abord ce que n’est pas le RAD, à savoir une absence totale de méthode. Le RAD est l’aboutissement des méthodes à partir des besoins d’évolution qui ont conduit ces méthodes à être remises en question ; pour des raisons très simples, le nombre d’échecs que les méthodes classiques ont engendrés.

Jean-Marc Berlioux

Oui, c’est ça, on a vu un certain nombre de projets qui ont eu des problèmes, disons…

Jean-Pierre Vickoff

Oui, il semblerait que statistiquement l’on ait 16% de projets qui ne soient pas des échecs. Pour le reste, ça varie entre l’abandon total du projet ou l’absence de conformité ou la dérive pure et simple. Donc, le RAD, c’est un moyen de contrôler cela par différentes techniques.

Jean-Marc Berlioux

Alors, en deux mots, quelles sont les originalités du RAD par rapport aux méthodes classiques ?

Jean-Pierre Vickoff

Je pense que vous avez raison de poser cette question, il est préférable de s’axer sur ce qui est spécifique dans le RAD. La première chose vraiment spécifique au RAD, c’est la communication et l’animation.

On a en effet recours à un spécialiste, un animateur, un spécialiste en entretien de groupe, appelé aussi facilitateur, qui va dans un premier temps s’immerger dans le domaine fonctionnel pour ensuite engager l’ensemble des intervenants. Plus particulièrement d’ailleurs, des membres de l’équipe de la maitrise d’œuvre, donc de réalisation, qu’il formera à être rapporteur :

• soit rapporteur « synthétisateur », pour arriver à avoir une synthèse du discours utilisateur en direct,
• soit rapporteur modélisateur pour effectivement réaliser une modélisation du discours utilisateur en direct.

C’est le premier point sur lequel le RAD diffère des autres méthodes. Et c’est à travers cet engagement de l’utilisateur que l’on aura la maitrise de la qualité.

Le deuxième point, peut-être tout aussi important, est l’équipe, le swat-team. Il nous faut des informaticiens un peu spécialisés, avec des profils bien particuliers… Mais je pense que l’on aura peut-être l’occasion de détailler ça un peu plus tard.

Et puis, pour que le RAD soit une méthode, c’est aussi le cycle de vie. Et c’est ce cycle de vie, très phasé, très structuré, 30 jours, 60 jours, 90 jours, 120 jours, qui permet d’avoir une dimension dans le RAD, temporelle. C’est la maitrise, d’une certaine manière, des délais. Je préciserais quand même que la notion d’équipe, de matériel, de compétence, représente la maitrise du coût.

Jean-Marc Berlioux

D’accord, donc on a à la fois la maitrise des délais et des coûts, des charges.

Jean-Pierre Vickoff

Et de la qualité par le biais de l’animation et de l’engagement utilisateur.
 
Jean-Marc Berlioux

Et de la qualité.

Jean-Pierre Vickoff

Ce sont les trois axes fondamentaux du RAD.

Jean-Marc Berlioux

Outre le RAD, on a parlé de beaucoup de méthodes. On a parlé de BPR (Business Process Reegineering), on a parlé de Gestion de Projet, on a parlé d’Analyse de la Valeur. Comment se situe le RAD par rapport à toutes ces méthodes ?

Jean-Pierre Vickoff

Toutes ces méthodes ou techniques sont complémentaires, elles découlent d’ailleurs du même courant de pensée. C’est l’approche de palo alto vers la qualité totale.

Et il est effectif que l’on peut imaginer qu’avant de développer très rapidement et avec énormément de qualités, ce que le RAD recherche, une application, on ait d’abord fait en sorte que l’organisation soit elle-même performante, de façon à ne pas automatiser des choses qui soient en état de dysfonctionnement. Donc, le Business Process Reegineering, sur ce plan là, est complémentaire du RAD. La qualité totale, cela va de soi et les techniques d’entretien de groupe sont au cœur du RAD. Donc l’ensemble de ces techniques et méthodes sont complémentaires du RAD.

Jean-Marc Berlioux

Bon, très bien. Alors, certains ont pensé, ont dit, que le RAD était quelque chose qui s’apparentait à une absence de méthode, qu’on travaillait un peu par essais-échecs. Qu’est-ce que vous en pensez ? Est-ce qu’il y a une méthode RAD, vraiment, par derrière ?

Jean-Pierre Vickoff

« Méthode » est un grand mot. Le RAD est surtout une approche qui va combiner d’autres types d’approche.
Certaines approches étaient dites « top-down », descendantes, très structurantes ; c’étaient les cycles en cascade des méthodes classiques de type Merisienne, parfaites pour les grands systèmes mais excessivement lourdes et collant souvent très mal aux besoins des utilisateurs. Le nombre d’échecs issus de ces méthodes est évident.

Il y a aussi des approches dites de prototypage, dites « bottom-up », c’est-à-dire par les besoins. Mais ces approches là, si elles collaient momentanément aux besoins des utilisateurs pouvaient se retrouver dans les grandes organisations à mettre le système général d’information en état d’incohérence parce qu’on multipliait les traitements, les données. Il manquait le plan d’ensemble.

Jean-Marc Berlioux

On avait de la peine à recoller les morceaux, ensuite…

Jean-Pierre Vickoff

C’est parfaitement ça.

Le RAD utilise dans un premier temps une approche structurante, systémique. Ce sont les phases de cadrage et de design où on va exprimer les besoins et modéliser une partie du système et vers le milieu de la modélisation du système et ensuite totalement pendant la phase de construction où on va réaliser le système, alors on s’accordera à faire intervenir l’utilisateur et on sera dans l’approche par les besoins et là on cadrera parfaitement le besoin de l’utilisateur. Donc on sera dans le meilleur des deux mondes, à la fois la cohérence systémique (par 1ère partie de l’approche) et la perfection, tout au moins la perfection recherchée, en tout cas la qualité, par l’expression de l’utilisateur et sa validation permanente.

Jean-Marc Berlioux

La logique du Rad suppose que l’on ait des réunions avec les utilisateurs, avec les gens qui savent. Cet aspect est-il traité, avez-vous une organisation particulière de ces réunions, des relations entre les swat-teams (Skill With Advanced Team - Groupe très expérimentés doté des meilleurs outils pour travailler) et ces utilisateurs.

Jean-Pierre Vickoff

Oui, c’est évident. Le RAD et surtout les réunions et comment elles devront s’orchestrer, il faut comprendre que le RAD, c’est trois étapes, trois phases plus exactement, trois phases complémentaires :

• Une phase d’expression des besoins, le cadrage,
• Une phase de modélisation, le design
• Une phase de construction, la réalisation

Au cours de ces phases, ce ne sont pas les mêmes utilisateurs qui vont intervenir.

En phase de cadrage, nous allons avoir besoin de prendre des décisions de haut niveau, nous aurons donc plutôt des dirigeants, des responsables de haut niveau.

En phase de modélisation, il faudra avoir une vue du métier et de son évolution, donc de la maitrise intermédiaire, sans néanmoins exclure l’utilisateur de base.

Il est bien évident que pendant la construction, ce sont les utilisateurs de base, les utilisateurs réels qui interviendront pour exprimer leurs besoins et des choses aussi simples que l’ergonomie de l’application.
On a donc trois niveaux d’équipes différents.

Jean-Marc Berlioux

C’est important ce que vous dites, effectivement, assez souvent, les informaticiens parlent de l’utilisateur alors qu’il y a différentes classes d’utilisateurs et chacun donne un certain niveau de spécifications et on n’a pas un utilisateur absolu.

Ça, c’est un point important. Autre point, l’équipe. On parle quelque fois de la swat-team. Est-ce qu’elle a des caractéristiques, est-ce qu’elle fonctionne de façon particulière ?

Jean-Pierre Vickoff

L’équipe RAD est composée d’un profil unique, des concepteurs-développeurs avec chacun une expertise particulière. Pour certains, ce sera une expertise en Base de Données, pour d’autres en gestion de projet, et pour d’autres encore en développement. C’est la fin du couple programmeur et analyste, avec la fin de la passation des documents, la fin de la propagation des erreurs liée à cette structure dans la chaine de conception-développement. Et c’est peut-être aussi la fin de l’homme orchestre, pour arriver plutôt vers l’orchestre tout court. Nous allons avoir des gens travaillant en synergie avec un profil commun et qui par groupe, doivent valider une partie de l’application.

À noter que nous parlions des réunions, tout-à-l’heure, je n’ai pas précisé la notion de focus. La notion de « focus » qui est une autre forme de réunion. Dès que ce groupe a réalisé une partie significative de l’ouvrage qui a été planifiée, on réunit tout le monde et on la présente. Cette grand-messe, le focus, est une démonstration de l’avancement du projet et aussi une forme de validation qui va permettre de maitriser le projet en délai.

C’est une garantie de réussite.
 
Jean-Marc Berlioux

Cela veut dire que le projet doit être en situation d’être livré à différents moment dans le cours du projet.

Jean-Pierre Vickoff

C’est ce que l’on appelle les jalons zéro défaut ou l’état des livraisons permanentes. L’équipe va réaliser une application dès le départ en fonctionnalités réduites et qui sera pratiquement utilisable à partir d’un prototype utilisable et va incrémenter en termes de fonctionnalités.

Cela implique ente-autre du matériel adéquat, des ordinateurs puissants, de la haute définition, des AGL conviviaux, légers mais très, très efficaces. Le RAD, c’est avant tout de l’efficacité.

Jean-Marc Berlioux

Que signifie l’acronyme « SWAT » ?

Jean-Pierre Vickoff

SWAT : Skill With Advanced Tools

Ce sont des gens très expérimentés, dotés des meilleurs outils pour travailler. Bons ouvriers, bons outils.
Ce n’est pas aussi évident que ça dans les entreprises. Un combat que je mène régulièrement, c’est l’obtention de matériel puissant et surtout de grands écrans et de haute définition. Les gens ne comprennent pas, ceux qui ne développent pas, pourquoi nous avons besoin de ça et pensent souvent que ce sont des gadgets alors qu’il est évident que la productivité de l’équipe en dépend et que ça se rentabilise sur deux ou trois mois en général.

Jean-Marc Berlioux

Si l’on souhaite lancer un projet RAD, je suppose qu’il faut préparer l’équipe, préparer le matériel. Comment doit-on procéder pour se préparer à lancer un projet RAD ?

Jean-Pierre Vickoff

Dans un premier temps, il va falloir obtenir l’accord à la fois de la maitrise d’œuvre et de la maitrise d’ouvrage en leur présentant les contraintes et les avantages du RAD. Si l’on obtient cet accord qui doit être appuyé par la direction générale, on pourra se lancer dans la préparation du projet RAD, c’est-à-dire une planification de l’engagement des utilisateurs comme celui des informaticiens. Déjà là, on s’apercevra que la charge à produire des utilisateurs, bien qu’elle soit moins importante en pointe au départ que dans un projet classique, et bien souvent dans sa linéarité, un problème pour les utilisateurs, donc accorder des ressources supplémentaires aux utilisateurs pour qu’ils dégagent les personnes les plus compétentes, celles qui pourront faire évoluer le projet dans la bonne direction. C’est fondamental.

Deuxièmement, il faut créer l’espace du Swat-team, c’est-à-dire un espace de travail dans tous les sens du terme avec le matériel adéquat comme nous en avons parlé et leur donner aussi une certaine liberté. Il faut que les gens travaillent en toute autonomie, en complémentarité, et il faut que ce soit une synergie entre les membres de l’équipe qui créent la performance que le RAD présente comme étant son aboutissement.

Jean-Marc Berlioux

Peut-être former les équipe à cette technique particulière, notamment les animateurs ?

Jean-Pierre Vickoff

Il est évident qu’il faut former à la fois les utilisateurs, un minimum, soit à un minimum de modélisation, ce qui n’est pas si complexe que l’on peut l’imaginer. Dans tous les projets auxquels j’ai participé, j’ai formé un ou deux utilisateurs, pas modéliser mais à comprendre la modélisation. Il faut aussi imaginer que la modélisation n’est pas forcément ce que l’on imagine forcément. En termes de modèle de données, c’est évident l’entité-relation ; ce n’est jamais que des carrés reliés par des petits traits. Mais en termes de traitements, on peut avoir des représentations de type merisiennes, mais aussi des flux ; on peut aussi avoir simplement une hiérarchie de fonctions, utiliser Word en mode plan pour la réaliser. Donc l’utilisateur peut comprendre, donc une formation utilisateurs, effectivement.

Il est évident que le plus gros n’est pas de former les utilisateurs, c’est de former les informaticiens. Si on tombe sur des informaticiens relativement jeunes et sortants d’une école avec à la fois conception et réalisation, pas de problème. Si l’on prend des équipes classiques avec des analystes et des programmeurs, il y a un sérieux travail pour que les analystes se remettent à programmer et que les programmeurs imaginent le prolongement de leur carrière à travers la fonction de conception. Mais c’est nécessaire, il n’est plus possible aujourd’hui de développer avec cette structure entre la conception et la réalisation.

Jean-Marc Berlioux

En conclusion, Jean-Pierre Vickoff, vous avez une grosse expérience en développement rapide d’application, à votre avis, est-ce que le RAD est vraiment efficace ?

Jean-Pierre Vickoff

On sait quel sont les échecs des méthodes classiques. En RAD, on ne le sait pas vraiment, parce que les gens, actuellement se méfient un peu du RAD et surtout lorsqu’ils ont lancé quelque chose qu’ils pensaient être du RAD et qui généralement n’en n’était pas et qu’ils sont arrivés à une forme d’échec ou de rejet, alors, on ne publie pas sur nos statistiques, actuellement. Pour ma part, j’ai travaillé en Amérique du Nord, à Bell Mobilité Cellulaire, pour Abbott, pour Hydro-Québec, en France à la SEITA, à la Société Générale, et maintenant je suis à TF1. Pour ce qui est de ces projets là, ça a marché au-delà de tout espoir. Un exemple à la SEITA, c’était évident que l’approche merisienne et SDMS était en train de nous mener à un échec de projet. Nous avons repris en RAD au bout du sixième mois et nous avons terminé notre application prévue pour cinq chefs de projet ayant chacun 2-3 analystes-programmeurs à sa disposition, nous avons terminé à quatre développeurs-concepteurs, dans les temps. C’est un exemple. Le dernier projet à la Société Générale, c’était en 90 jours livré. Dans une grande organisation, il est très difficile de livrer une application complète sous une surveillance permanente, en 90 jours. Le RAD est une méthode qui amène toujours le succès lorsque l’on respecte les conditions de sa mise en œuvre. D’ailleurs, dans mon livre, il y a une série de questions qui s’appelle « vos projets sont-ils RAD ? » Et bien souvent, des gens qui pensaient mener des projets en RAD, se sont rendu compte qu’ils ne répondaient pas « OUI » au quart des questions, donc ce n’était pas du RAD.

Jean-Marc Berlioux

Donc, le RAD, c’est une méthode, et pour réussir et réussir bien en RAD, il faut quand même suivre la méthode.

Jean-Pierre Vickoff

Parfaitement et je ne peux pas terminer sans dire quand même que le RAD, au départ c’est James Martin, et si l’on doit se référer à quelque chose en matière de méthodologie RAD, c’est à James Martin. Malheureusement, il ne l’a pas écrit en français, ça nous dérange quelque peu et son ouvrage de 91 qui contenait la totalité de ce que nous attendions en termes de méthode, n’a pas été réactualisé mais quand même, c’est la référence.

Jean-Marc Berlioux

Très bien, Jean-Pierre Vickoff. Merci !

IV. WEBOGRAPHIE

▲ IV-1. WEBOGRAPHIE - Logique de construction des programmes
► IV-2. WEBOGRAPHIE : RAD
▼ V-1. Commentaires