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.