Redonnant au codage une place respectable, l’Extreme Programming (XP) prône une responsabilité accrue pour les développeurs, une stratégie de tests continus, et une implication aussi fréquente que possible de
l’utilisateur/client. Et cela dans une démarche véritablement collaborative. Laurent Bossavit, président de l’Association française des utilisateurs de XP, fait le point sur ses implications.01 Informatique : L’Extreme Programming (XP) est une approche relativement récente. Avons-nous assez de recul pour juger de sa pertinence ?Laurent Bossavit : Contrairement à ce qui se passe lors de démarches plus conventionnelles, les personnes qui formulent XP ne se sont pas attachées à produire des études. XP est venu de la base, de développeurs qui
essaient, de façon pragmatique, d’améliorer les choses dans leur coin. C’est plus tard que l’idée est venue d’étendre ces principes au niveau du projet ou de l’équipe.XP s’appuie fortement sur des notions de collaboration. Sont-elles perçues comme une contrainte ou une libération ?Les deux. Le travail collaboratif est une discipline qui nécessite des efforts, et de déléguer une responsabilité beaucoup plus grande aux développeurs, d’impliquer davantage le client. Pour que cela fonctionne, il ne suffit pas de
le décréter. Pour avoir cette communication avec le client/utilisateur, certains comportements et attitudes doivent être modifiés.En quoi XP s’applique-t-il à la conception ?Un logiciel, à mesure qu’il se complexifie, a tendance à s’écrouler sous le poids de sa propre complexité. A moins que l’on ne définisse une structure lui permettant de demeurer robuste face aux contraintes d’évolution technique ou
du métier. Dans une approche plus classique, c’est l’architecte qui aura la charge de cette structure en dessinant des modèles Merise, UML ou autres.Peut-on parler d’une forme de conflit entre développeur et architecte ?Il y a forcément complémentarité. D’un côté, l’efficacité de certains provient de ce qu’ils savent représenter en quelques lignes la structure d’un système. D’autres auront la faculté de relier des points de détail du code à cette
vision d’ensemble. Ces compétences vont cohabiter dans le cadre du projet.Mais dans les approches à base de modèles, comme MDA (Model Driven Architecture), le codage semble pourtant passer à l’arrière-plan ?Ce serait vraiment une erreur d’imaginer que la partie la plus importante du travail consiste à modéliser le métier d’une entreprise. La réalité est plus subtile. L’interaction entre l’analyse d’une problématique métier et sa
concrétisation dans un produit est un dialogue. Et c’est dans ce dialogue que réside la valeur pour l’entreprise. On ne pourra supprimer ni l’écriture du code ni la mise au point des modèles.Si XP regroupe un ensemble de bonnes pratiques connues, pourquoi n’est-il pas arrivé plus tôt ?Il faut manier avec prudence la notion de nouveauté en informatique. Cela vaut pour les méthodes : on redécouvre des principes connus depuis vingt ou trente ans, comme le binôme, plus performant que deux développeurs
travaillant chacun de son côté. Les militaires, par exemple, l’ont institué depuis très longtemps. A l’université aussi, on travaille souvent en binôme.Souvent, les utilisateurs n’adaptent que certaines parties d’une approche méthodologique. Les éléments de XP sont-ils indissociables ?Tout projet comporte des risques dans trois domaines : la qualité, la perte de la relation avec le client ?” on ne le comprend pas, donc on fait quelque chose d’inutile ?” et enfin les délais. XP est complet
parce qu’il met en lumière un éventail complet des problèmes qui peuvent survenir dans un développement. L’un des dangers est de ne prendre de XP que ce qui passe facilement, ce qui est immédiatement compatible avec les modes de travail en place.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
