Fondements de l'eXtreme Programming

Lignes directrices

XP est une méthode basée sur des principes simples, que tout le monde pratique déjà sans le savoir. Mais alors, où est la « révolution » ?

Rendre moins lourdes les démarches

Le but d’XP est de trouver des solutions plus ou moins simples, basées sur des principes éprouvés, pour tenter de diminuer les risques pour respecter les délais et la qualité du produit commandé.
Cela, en trouvant un compromis équilibré entre "pas de démarche" et "trop de démarche", tout en respectant le minimum de discipline nécessaire pour attendre un retour sur investissement en temps et en effort immédiat et intéressant.
Ainsi, on souhaite réduire radicalement la production de documents en se focalisant sur un code bien commenté plutôt que sur des documentations techniques très formelles.
XP évite donc avec cela les lourdeurs des méthodes classiques et est donc un habile compromis entre une méthode traditionnelle et le développement « cow boy », sans règles précises. Par conséquent le travail des informaticiens est totalement tourné vers la technique où ils se sentiront vraisemblablement plus à l’aise.

Changer les principes

En outre, XP, en tant que méthode agile, se veut adaptative plutôt que prédictive. C’est à dire qu’à l’inverse des méthodes lourdes qui tentent de dresser un plan au début du projet, XP indique qu’il vaut mieux agir sur le court terme. Cela, tout simplement parce qu’il n’existe pas de projet figé où le prédicat de base ou le contexte ne changent pas du tout. Dans ce cas, le coût du changement a une croissance logarithmique en fonction du temps.
Le simple fait de ne pas être réticente aux changements permet dans un premier temps de mieux s’y adapter mais permet aussi une meilleure relation avec le client et la livraison d’un produit conforme totalement aux exigences de ce dernier.
Enfin, le dernier but d’XP est de se vouloir orienté sur les personnes plutôt que sur les processus. Alors, le développement tentera d’être une activité agréable plutôt qu’un cauchemar bureaucratique.

Les 4 valeurs d’XP

Le père d’XP et ses adeptes d’XP définissent quatre valeurs que l’on doit respecter pour entrer dans le clan, pourtant non fermé, des XPiens.

Communication

Le manque de communication est dans la vie courant un créateur de malentendu et cela devient encore plus grave dans un projet, pour tous les acteurs. Plusieurs pratiques dans XP ont pour finalité de permettre de se poser les bonnes questions et un partage de l’information entre acteurs du projet : au sein de l’équipe de développement et entre développeurs et clients.

Dans l’équipe

La communication avec XP est une valeur essentielle. Le code étant propriété de tous, chacun doit tenir au courant les autres de l’état d’avancement de son travail. Cela permet aussi de demander éventuellement de l’aide ou de répartir les travaux complexes ou plus long. Aussi, grâce à cette communication, chacun partage ses connaissances, ce qui est bénéfique pour l’équipe, le client, l’entreprise, etc ! Ainsi, se crée une réelle et formidable dynamique de groupe et un esprit d’équipe solide et efficace.
Lors des tests d’évaluations, la communication a lieu aussi avec le chef de projet puisque ce dernier s’entretient avec son collègue pour savoir ce qui a été fait et ce qui marche. Par la même occasion, cela permet éventuellement de redéfinir les tâches en fonction de la charge actuelle de travail et cela permet aussi d’avoir une discussion amicale avec tout le monde !
La communication écrite n’est pas en reste puisque le code se doit d’être toujours propre notamment pour permettre une relecture par les autres.

Avec le client

En plus de donner des avantages conventionnels au client, XP permet un rapprochement du client par rapport aux informaticiens, notamment lorsque le non-informaticien explique son métier. La communication s’instaure donc plus facilement entre tous les acteurs et les relations humaines n’en sont que meilleures.
C’est d’ailleurs ce qui ressort d’une interview de Dominic Williams, chef de projet à CSEE Transport, qui a du fournir une application à l’entreprise GoldOwner, réalisée par le groupe de réflexion Design-up. Dans celle-ci, M. Williams explique notamment les bénéfices qu’a apporté la méthode dans leur relation avec le client.
En effet, dans la première phase du projet, le client n’a pas été intégré au projet alors que dans une deuxième, il a fait partie intégrante de l’équipe. Selon lui, les rapports et les performances se sont alors beaucoup améliorés, ainsi que le respect des dates butoires qui est devenu au fur et à mesure complètement fiable.
Enfin, le client a beaucoup apprécié la souplesse que la méthode permet pour apporter des modifications aux spécifications en cours de projet (quotidiennement s’il le veut) et la très bonne réactivité pour le traitement des anomalies. La gestion des priorités est aussi plus pertinente puisqu’il peut réorienter les développeurs « en direct ».

Feedback

Par le mot feedback, il faut entendre « retours », commentaires, avis...

Du client

Tout au long du projet, des retours réguliers du client sont demandés pour progresser. En effet, avec les livraisons régulières, le client donne en continue son avis sur les cohérences du produit avec ses souhaits en terme de fonctionnalité. Le moyen de faire ces feedbacks est la mise en place des tests unitaires qui détectent les bugs et les régressions. En découlent des félicitations, des changements et des améliorations pour coller de plus en plus près à la demande finale. Par conséquent, les développeurs peuvent programmer sans crainte puisque toute divergence sera détecter rapidement.

De l’équipe

En parallèle au feedback du client, au sein de l’équipe, les commentaires sont aussi les bien venu. Cela est possible grâce à la programmation en binôme et puisque chacun peut consulter le code de l’autre. Là aussi il en découle des congratulations ou des critiques constructives qui augmentent les compétences du fautif.

Simplicité

La vie est déjà assez difficile pour avoir envie de la rendre encore plus qu’elle ne l’est...

Le YAGNI

Une autre grande idée d’XP est donc de toujours avoir en tête un principe trivial. Celui-ci porte un nom qui semble complexe mais qui pourtant à des aspirations très élémentaires : le YAGNI (You're NOT Gonna Need It). C’est à dire qu’il faut toujours chercher à supprimer l’inutile pour optimiser au maximum la productivité. Ainsi, un développeur doit toujours avoir en tête cette phrase : "What is the simplest thing that could possibly work?" (« Qu’elle est la solution la plus simple qui peut fonctionner ?”).
Cette philosophie rejoint l’idée vue précédemment sur la flexibilité qu’apporte XP aux changements. Cela car, « il vaut mieux faire simple aujourd'hui, quitte à changer demain, plutôt que de faire tout de suite compliqué sans être absolument certain de l'utilité de ce que l'on développe ».
En conséquence, tout au long du développement, la vie du développeur n’est pas de tenter de rechercher une solution exceptionnelle pour les sujets considérés mais son but est plutôt d’évoluer le plus vite possible. Aussi, avec cette souplesse, le client peut demander des modifications sans que le développeur ne soit réticent à l’appliquer, sans non plus d’augmentation considérable des délais.

Pour faire des économies

De ce point de vue, XP fait donc le pari que la simplicité d'aujourd'hui revient moins cher et le surcoût éventuel dans le futur est compensé par le fait que, à propos de la solution compliquée, "vous n'en aurez probablement pas besoin". Donc, en moyenne, mieux vaut faire simple.
D’ailleurs cette simplicité est aussi essentielle pour que le code puisse être repris instantanément par n’importe quel développeur pour le compléter ou le changer.

Précisions

Attention toutefois, "le plus simple possible" ne signifie pas "simpliste", il ne faut pas se tromper sur ce but ! Par exemple, il ne faut pas se laisser tenter par la simplicité de ne pas reprendre une classe par exemple pour éviter de s’embêter à la relier et la comprendre (ce qui doit d’ailleurs être chose aisée !)... Toute duplication de code est bien sûr interdite !
Enfin, le client se doit aussi d’adhérer à ce principe pour ne pas demander des choses complexes qui ne seront jamais utilisées !

Courage

Les acteurs d’un projet qui décident d’utiliser XP, même si la méthode a de grandes qualités, doivent avoir du courage.

Avoir confiance en XP

Le client doit avoir le courage de donner des priorités à ses besoins, de dire que tel besoin n’est finalement pas très clair...
Le responsable doit avoir le courage de commencer le projet avant que tout ait été précisé clairement sur un document contractuel. Et même en amont, il doit faire preuve de courage en adoptant une méthode nouvelle, surtout sur des projets stratégiques.

Savoir jeter pour repartir sur de bonnes bases

De même pour le développeur qui doit s’obliger à jeter du code qui sent mauvais... Le code a une odeur, quelquefois il faut le changer et tout recommencer. Simplement, XP demande le courage de regarder le développement en face, sans tabou... De plus, la mise en place d’itérations très courtes implique une possibilité de reconsidération régulière de son travail ce qui serait susceptible de décourager certains, voire la plupart !
Enfin, la transparence vis à vis du client et de l’équipe (particulièrement des binômes) demande du courage car chacun peut voir les incompétences de l’autre...

Retour

|

Accueil

|

Plan du site

|

Recherche

adrien@machado-fr.com