RAD et agilité
Posté par Eric Le Merdy, le 30/08/2010.J’ai fait du RAD il y a quinze ans, était-ce déjà de l’agilité ?
Il arrive d’entendre cette question lorsque l’on fait découvrir l’agilité à ceux qui sont passés sur les plateaux de développement il y a quelques années. A tous ceux qui se posent la question, voici une mise au point sur le sujet. Dans cet article, on considère que l’acte de naissance de l’agilité est le manifeste agile en février 2001. La méthode RAD est quant à elle attribuée à l’américain James Martin qui la formalise dans son livre Rapid Application Development publié en 1991.
Le RAD formalisé
La méthode RAD s’est complétée au cours du temps avec les ajouts de 1994 versés notamment par le franco-canadien Jean-Pierre Vickoff. Si bien qu’il est difficile rétrospectivement de reconnaître les valeurs originelles de RAD… C’est précisément cette revendication agile tardive qui est parfois reprochée au RAD dans des débats passionnés avec les supporters de chaque camp. Mon objectif étant de ne pas rajouter de l’huile sur le feu de ce débat stérile (“ma méthode est plus grosse que la tienne” 
), je tenterai de rester factuel dans cet article.
Ce qui est sur, c’est que cette méthode apparaît en réaction au cycle de développement en cascade. On pense alors que c’est la durée qui est le paramètre clé qui fait échouer les projets: on veut améliorer l’adéquation aux besoins en rencontrant plus vite les utilisateurs: Limitation dans le temps du projet RAD de 90 jusqu’à 120 jours maximum
Et dans la réalité ?
Derrière toute théorie, il y a une mise en application, plus ou moins fidèle au modèle… Les coachs agile en savent quelque-chose !
Comment le RAD a-t-il été appliqué ?
La vitesse de développement sera accélérée par des outils !
On a fixé la technologie sur tous les plans: la base de donnée, la technologie de communication client/serveur et les outils de développement. C’est cette calcification de tous ces paramètres qui permet la capitalisation sur des outils de productivité.
Les éditeurs de l’époque ont bien compris d’ailleurs la position de force que cela pouvait leur procurer.
La focalisation est forte sur la donnée dans la base relationnelle. Ce sont les heures de gloire de Merise en France. Le développeur conçoit ensuite des écrans en glisser/déposer à partir des champs de la base. La dynamique client est codée par des scripts sur les composants d’interface graphique.
A long terme de la sur-complexité et de la duplication apparaît bien souvent dans les traitements côté client. Les procédures stockées peuvent subir aussi de nombreux ajouts qui peuvent en altérer la clarté.
Les personnes qui ont pratiqué le RAD se sont semble-t-il fortement préoccupés des outils qu’on a appelé CASE pour Computed Aided Software Engineering tels que PowerBuilder, OracleForms et autres L4G.
RAD et agilité
Voici des exemples de différences entre le RAD et l’agilité:
- [Edit]
les cycles itératifs en RAD sont plus longs (90~120 jours) et ressemblent a du “mini tunnel” (contre 2 semaines idéalement en SCRUM par exemple)L’itération en RAD s’inscrit seulement dans la phase de “réalisation”. Elle est bornée par un “focus” qui provoque une intégration et permet une démonstration à l’utilisateur.[/Edit] - il y a toujours des phases de planification, design et développement séparés (contre un design émergeant en eXtreme Programming par exemple)
- les découpages temporels impartis aux phases du RAD sont assez stricts (moins de souplesse)
- les rôles sont apparus tardivement dans RAD (comme cela existe en SCRUM ou en XP)
- pas de préconisations pour les estimations collaboratives de la charge, les notions de reste à faire et de suivi (présent en XP et en SCRUM)
- il n’y a pas vraiment de notions de rétrospective et d’amélioration continue
Et voici quelques points communs:
- logiciel fonctionnel prépondérant à une documentation exhaustive, pragmatisme
- “Time-boxing” (limitation du temps)
- mise en avant de l’équipe intégrée (SWAT)
Aujourd’hui
Les raisons du succès du RAD ne sont pas éteintes. On peut aussi ajouter que le RAD n’est pas mort, on trouve des éditeurs comme PCSoft en France par exemple qui revendiquent une base de clients pour qui le RAD fonctionne très bien. Un éditeur comme Microsoft par exemple permet encore aujourd’hui de mettre en pratique le développement RAD avec la programmation .Net basée uniquement sur les DataSets. A l’heure de l’open-source, ne serait-on pas capable de composer, autour d’une pile logicielle standardisée (telle JavaEE ou .Net) une suite d’outils pour faire du RAD ? La place du test devrait en tous cas y être prépondérante. Ruby On Rails qui a popularisé la technique de l’échafaudage (ou scafolding) qui permet de générer les vues web au dessus d’un schéma relationnel s’inscrit dans cet héritage qui mélange outillage productif, génération de code et framework de tests avancés.
En tous cas, si le RAD a montré une chose, c’est que tout framework, outil ou méthode aussi performant qu’il soit, ne saurait être efficace qu’avec une organisation pertinente où les individus sont respectés et la communication est assurée.
Conclusion
Le succès du RAD dans les années 90 a permis de se rendre compte qu’il existait une façon plus souple de produire du logiciel que le cycle en cascade (l’évolution des langages de programmation n’y est pas étrangère non plus). La focalisation client et les prémices du développement itératif ont permis aux outils RAD de se déployer massivement.
Aujourd’hui, on a pris de la maturité. Par exemple, on attend d’un développeur agile plus de responsabilité en développant du code “durable” (testé). Il a aussi une exigence de compréhension de la dynamique d’équipe dans laquelle chacun doit trouver sa place. S’il le faut, l’équipier ira lui-même chercher les outils pour améliorer la productivité de l’équipe.
L’apport de la méthode RAD à permis d’expérimenter à grande échelle les architectures 2 tiers et d’en identifier les limites. On a aussi pu voir à grande échelle l’exploitation d’un buzzword par l’industrie IT et les dérives au moment de déployer la méthode à travers simplement des outils.
Vous m’avez compris, l’intention initiale était louable et mérite notre intérêt encore aujourd’hui, ne serait-ce qu’en termes de leçons à retenir.
Merci à tous les consultants Valtech qui ont participé à l’élaboration de cet article.
September 7th, 2010 at 12:28 am
Hello
“où les individus sont respectés et la communication est assurée” > Ca mériterait d’être en gras !
Individuals and interactions over processes and tools
October 9th, 2010 at 11:53 pm
La partie concernant le RAD est un tissus d’ingnorance de la méthode.
J’ai pas le temps de corriger tout cela.
Juste un point pour l’exemple : c’est pas les itérations qui dure de 30 à 120 jours avec la méthode RAD mais le projet. Les itérations RAD étaient généralement de 1 semaines à 4 semaines suivant la durée du projet et en moyenne deux semaines. Et bien sur qu’il y avait des rétrospectives aau minimum à la fin de chaque itérations.
October 10th, 2010 at 6:50 pm
Merci pour la précision sur la durée du projet, je corrige. Dans la partie sur les différences avec l’agilité, nous assimilons un peu vite une itération agile à un projet RAD. Nous faisons correctement mention de la durée du projet RAD au début de l’article.
Il est possible qu’il y ait eu des rétrospectives dans la pratique, mais nous n’en avons pas trouvé de trace dans la méthode RAD originelle. Avez-vous une référence en tête ?
J’ai vu que vous aviez des sessions proposées et acceptées à L’Agile Tour. Donc nous nous croiserons peut-être pour nous rencontrer.
October 11th, 2010 at 12:11 am
On se croisera peut-être si vous êtes sur Vannes ou Nantes et si la grève ne pose pas trop de problème.
Allez, encore un petit point. Les rôles par exemple (http://www.rad.fr/focaorg1.htm). Dès le début, en 1991, la méthode RAD impliquait un animateur (de préférence neutre); l’équivalent du ScrumMaster. Il s’appuyait sur les informaticiens et les utilisateurs pour spécifier et valider en direct (video-projecteurs). Il y avait aussi l’équivalent du Product Owner côté client qui devait être le plus souvent possible “sur site” (c’est ensuite DSDM en 1995 qui a étendu les rôles : ambassadeur, sponsors, etc.). Côté informaticien ils devaient être tous des concepteurs-développeurs mais avec éventuellement des spécialisations particulières et complémentaires (SGBD, Test, outils de développement, facilité de représentation en comité de projet, etc.).
En ce qui concerne les retrospectices, il y avait tout les matin l’équivalent du standup meeting (mais il se faisait à la machine à café dès que l’équipe était au complet et avait son café en main afin de ne pas perdre de temps ensuite dans une pause café). C’était donc ainsi, par exemple, dès, 1993 à la régie des tabacs Seita à mon retour en France.
Bonne journée.
October 11th, 2010 at 12:31 am
J’ai oublié. La rétrospective journalière avait pour nom technique “planification jalon zéro défaut”. Celle de fin d’itération s’appelait Focus ou Show. On les voit sur cette illustration http://fr.wikipedia.org/wiki/Fichier:RADiteration.gif on (la rotation rouge est journalière et la bleu d’itération)
La notion de prototypage correspondait au travail de développement de l’application réelle (et non d’un prototype, ce terme était mal choisis). Pour finir, les partie Cadrage (spécifications et Design) de RAD correspondaient à la partie Exploration de XP. Par contre, si les notions d’arcchitecture émergeantes existaient au niveau développement comme dans XP, la phase de Design préalable s’appliquait à des choix d’architecture haute et surtout au design de la base de données).
Pour finir, je n’ai jamais trouvé de différence entre RAD et Scrum et si on observe l’illustration, la partie construction ressemble à du XP avec des techniques semblables mais pas systématiqquement mis en oeuvre.
On pourrait aussi évoquer, pour les grands projets, la nécessité de prévoir une planification stratégique pour coiffer la planification opérationnelle basée sur la priorité utilisateur.
On en parlera une autre fois.
October 12th, 2010 at 12:58 am
Un autre point, il n’y avait pas plus de lien entre la méthode RAD et une architecture technique comme le client-serveur par exemple. Pas plus qu’il n’y en a entre Scrum et un client léger ou un client lourd actuellement.
Si de nombreux outils ont essayé de générer du code en se qualifiant de RAD, cela n’avait pas de rapport direct avec la méthode, même si James Martin au début avait espéré que l’évolution des outils permettrait la génération automatique d’application. On trouve actuellement la même recherche avec le MDD/MDA. De tous les projets que j’ai fait à l’époque, aucun n’utilisait de générateur, c’était de la programmation en C, Visual Basic, Cobol, Java … Par contre l’usage d’outils de modélisation comme AMC Designor par exemple était généralisé.
En ce qui concerne ” la revendication agile tardive “, il faut savoir que DSDM (le RAD en Angleterre) fait partie des méthodes reconnues comme Agile et d’autres méthodes dites Agiles apparues dans le milieu des années 90 se réfèrent de l’évolution du RAD pour leurs origines. Comme je l’ai souvent écrit, si une nouvelle méthode apparaît et souhaite créer une rupture méthodologique la dispensant de se référencer des approches antérieures, il est indispensable qu’elle précise sur quelle nouveau paradigme elle se fonde. Sinon, c’est soit de l’ignorance de l’état de l’art, soit quelque chose de plus gênant en matière d’éthique.
Voila, à un autre jour.
Ps. Je m’amuse beaucoup à reparler de cette méthode que j’ai employé en gros de 1990 à 2000. Par contre, je n’aurais jamais pensé devoir écrire de nouveau, même ces quelques messages, sur ce sujet.
April 20th, 2011 at 1:04 pm
[...] de méthodes (ouvertes et propriétaires) ont vu le jour. Parmi elles, on citera notamment : RAD, Scrum, XP, Lean, FDD ou encore TDD, qui accaparent à elles six environ deux tiers du marché de [...]