Les anciens programmeurs n’y verront qu’une resucée de méthodes datant des années soixante-dix. Pour les plus jeunes, ça risque d’être la révolution ! Arrivant principalement des Etats-Unis, les techniques de développement logicielles agiles se révèlent séduisantes à de nombreux égards. Elles sont en effet basées sur une organisation rigoureuse, centrée sur l’utilisateur, qui s’attache à cadrer parfaitement les contraintes de délais, de ressources, de qualité et de contenu.Rassemblées depuis peu sous la bannière de l’Agile Alliance, elles se nomment DSDM, Adaptive software development, Scrum
ou Crystal.Et celle qui monte en force est incontestablement l’Extreme Programming (XP). L’un de ses créateurs, Kent Beck – un gourou reconnu du monde Smalltalk – la définit comme “une méthode basée sur des pratiques qui sont autant de boutons de contrôle poussés au maximum “.
Les tests avant le codage logiciel
Comme premier essai, XP a été testée sur le projet C3 en 1997. Le Chrysler Comprehensive Compensation System doit, à l’époque, gérer la paie d’environ dix mille salariés du fabricant automobile. La méthode arrive à l’époque pour sauver un projet qui part à vau-l’eau, et qui comprend pas moins de deux mille classes Smalltalk et trente mille méthodes associées.Si finalement XP a échoué dans le projet C3 – non pas techniquement mais parce qu’il n’a pas suffisamment pris en compte le management -, ses pères, Ward Cunningham et Kent Beck, ont tiré de l’expérience de précieux enseignements, faisant de ce chantier le point de départ de la méthode.XP mise sur un petit nombre de règles qui sont toutes poussées à bout. L’une des principales lignes directrices est relativement simple : la majorité des activités techniques doivent être “permanentes”. Autrement dit, architecture, conception, codage, débogage, tests et même intégration sont menés en continu, par itérations courtes et fixées à l’avance.Une pratique, apparemment anodine, qui implique que la refonte quotidienne du code (refactoring) par les développeurs devient essentielle dans un contexte XP. Elle permet non seulement de factoriser des portions de programmes, anticipant une réutilisation ultérieure, mais surtout de lui donner un aspect “lisible”, avec des classes et des méthodes aux noms “parlants”. La documentation devient alors le code lui-même ou peu s’en faut.La façon dont sont menés les tests est particulièrement révélatrice de l’esprit véhiculé par XP. En premier lieu, c’est le client (ou l’utilisateur) qui écrit lui-même les tests fonctionnels, après une étape rapide de modélisation. Ensuite, le développeur s’attèle aux tests unitaires correspondants. Arrive, enfin, l’étape du codage proprement dit, l’idée sous-jacente étant de le réaliser grâce au travail effectué sur les tests unitaires.Cette logique de tests est poussée jusqu’à l’obsession par la méthodologie: “Tout test unitaire manquant à une étape donnée doit immédiatement être programmé (…). Lorsqu’un bug est trouvé, il faut créer un test pour éviter sa réapparition…” Avant sa livraison, le code doit passer l’ensemble des tests avec une réussite de 100%. De fait, entre 20 et 40 % du temps d’un projet de type XP est consacré aux tests.Dans la même logique, il est aussi prévu – et c’est bien sûr une priorité – de concevoir des “programmes d’exploration des solutions potentielles”, également appelés “solutions de pointe”. Ils doivent “être créés pour trouver des réponses à des problèmes techniques ou de conception difficiles (…). Ils ne concernent que les cas examinés et laissent les autres de côté”. Quand, malgré tout, un problème s’obstine à bloquer le projet, XP recommande d’y associer un binôme pendant une à deux semaines. Plutôt que de continuer sur des bases incertaines.
L’abandon des méthodes prédictives
Quelles sont les réticences les plus courantes à l’adoption de XP? On lui reproche tout d’abord son manque d’éléments méthodologiques sur les phases amont et aval d’un projet. Cette critique dénote le plus souvent une difficulté, voire une inquiétude à modifier son approche du développement logiciel. Contrairement aux méthodes classiques, voire aux pratiques émanant de langages de modélisation de type UML, la phase de conception initiale doit être très courte.Normal, puisqu’elle évolue et se redéfinit pendant toute la durée du projet. Ces contraintes “amont” – qui peuvent être liées à l’existant, au planning, à la disponibilité ou à la sécurité – sont détaillées au moment où on en a besoin. Donc, ce n’est pas systématiquement au début. En ce qui concerne les phases en aval, le schéma reste lui aussi fidèle au principe d’itération: intégration, validation, mise en exploitation, s’opèrent au fur et à mesure du projet. Il n’y a donc pas stricto sensu d’étape de déploiement dans XP.La conséquence de cette concentration des tâches amonts et avals au sein des phases d’itération, c’est l’abandon de toute velléité ” prédictive “. Traditionnellement, l’intérêt d’une méthodologie réside dans sa capacité à anticiper, à définir le plus tôt possible ce que sera le système final.Elle met donc en place des spécifications complètes, des diagrammes de transitions, d’états, de temps, etc. dès la rédaction du cahier des charges terminée. XP, au contraire, se donne les moyens d’adapter le logiciel aux changements en modélisant les fonctionnalités, puis en les codant, au fur et à mesure de l’avancée du logiciel.
Premières mises en oeuvre dans des projets réduits
Avec ces questions pointent naturellement les considérations sur l’intérêt de la modélisation. Par sa nature simplificatrice, notamment en termes de définition préalable de l’architecture applicative, XP est fréquemment présenté comme “anti-UML”.Hormis le fait que les deux ne se situent pas sur le même niveau, le langage de modélisation traîne en effet une réputation de lourdeur. Celle-ci étant en particulier alimentée par la vision (d’horreur) d’informaticiens passant un temps fou à traduire intégralement les spécifications utilisateurs pour se conformer au modèle.Dans XP, les “Use Cases” détaillés sont remplacées par des “User Stories”. La différence, c’est que ces “histoires” ne se limitent pas à l’interface utilisateur. Elles doivent être courtes, éviter les considérations technologiques, de bases de données ou même algorithmiques.En outre, elles sont rédigées dans le langage de l’utili- sateur et ne sont pas des simulations de processus. Par exemple, l’équipe projet peut indiquer sur une feuille Bristol: “Après impression du devis, une option doit permettre d’imprimer les marges prévues”. On y ajoute la priorité voulue par l’utilisateur, l’estimation en points donnée par les développeurs, et c’est terminé. Avec une telle remise en cause de l’esprit cartésien qui domine dans l’Hexagone, il n’est pas sûr que les méthodologies agiles séduisent. Pour l’heure, les premières mises en ?”uvre se limitent essentiellement en France à des projets réduits ou non stratégiques.On commence ainsi à trouver XP dans des entreprises d’électronique qui développent des pilotes pour leurs matériels. La méthode fait aussi une incursion chez certains éditeurs ou dans les entreprises de secteurs scientifiques et techniques, pour leurs projets de R&D. Quelques sociétés de services, dont des agences web, s’y intéressent également, voyant dans XP un moyen de raccourcir leurs délais. Mais finalement, peu ont l’air prêtes à passer au “tout XP”.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
