… à l'Ecole de la V.I.E …

Avantages et inconvénients de la méthode XP (eXtreme Programming)

Extreme Programming apparaît comme la plus radicale des méthodes agiles.

Cette méthode se révèle particulièrement efficace dans le cadre de petits projets. XP réalise des applications de qualité grâce à la rigueur imposée sur les tests, qui plus est collent au désirs du client puisque celui-ci est intégré au projet de A à Z.

Aussi efficace qu’elle soit, la méthode XP n’est pas applicable dans tous les cas. Dans le cadre d’un projet de type forfaitaire où le prix, les délais et les besoins sont fixés, XP ne peut pas réellement être mise en œuvre. Le cas d’une équipe supérieure à une douzaine de personnes est un autre exemple où XP est difficilement adaptable car le nombre risque de ralentir, d’alourdir les procédures et de rendre la communication plus difficile et moins efficace.

Enfin, XP est sans doute une des plus contraignante des méthodes agiles, aussi bien pour le client que pour les développeurs. En effet, l’investissement demandé au client est très important puisqu’il doit déléguer une personne à temps plein sur le lieu où est développée l’application, avec toutes les conséquences que cela induit. En ce qui concerne les développeurs, la pratique de la programmation en binôme n’est pas forcément très bien ressentie par tous. Or un projet XP ne peut pas être un franc succès si tous ses participants n’adhèrent pas pleinement à la méthode. Avant de se lancer dans un tel projet, il faudra tout d’abord convaincre le client et motiver l’équipe ce qui n’est pas toujours aisé.

Avantages :

– Rapidité

– Réactivité

– Productivité

– Compétence

– Légereté

Inconvénients :

– Maintenance

– Blocage culturel

– Limite de taille

Documentation et communication

La façon classique de travailler en génie du logiciel favorise grandement la production de documentation (document de vision, de spécification, d’assurance qualité, de « configuration management », de métriques, etc.). Ainsi, ce concept est très difficile à accepter dans le domaine du génie Logiciel.

Le fait d’avoir le client en permanence sur le site de développement est très exigent et difficile à réaliser pour celui-ci. Ce n’est pas n’importe quelle compagnie qui est prête à sacrifier une personne à plein temps.

L’emphase sur la communication est un point très important qui favorise le bon développement d’un système adapté. « Plusieurs têtes valent mieux qu’une ! »

Ainsi le travail par paire (le pair programming) oblige les développeurs à bien comprendre leur code. Ils doivent être en mesure de pouvoir expliquer ce qu’ils font à leur paire. Mettre tous les programmeurs dans même pièce à aire ouverte est une très bonne idée qui permet une bonne communication. Fini les développeurs qui codent chacun dans leur coin.

Bien que le programmeur soit un peu réticent à accepter que le code qu’il fait ne lui appartient pas et que n’importe quel autre développeur à la permission de le modifier durant le projet, il y a cependant beaucoup de points positifs à cette méthode.

Un autre point important est l’abolition des heures supplémentaires. Souvent le problème du temps supplémentaire se fait sentir dans les équipes de développements. Selon la prémisse de XP, il ne doit pas avoir de semaine dépassant largement 40 heures d’ouvrage. En effet, c’est un point très important et qui permet d’avoir une bonne santé mentale et une vie sociale !

La communication sans délais avec le client, bien que demandant pour le client est très bon pour les développeurs. Ceux-ci ont besoin à plusieurs reprises d’avoir des réponses à leurs questions pour le bon déroulement du système.

Les tests sont aussi sans contre doute une nécessité. Autant les tests unitaires que les test de régression, cela doit être une pratique courante pour les développeurs. Classiquement lors de conception de logiciel l’habitude consiste à faire des tests à la fin du cycle de développement. Cela fait perdre beaucoup de temps, d’argents  et ne doit pas être une pratique courante.

Un autre point très intéressant, est de dégager la documentation non nécessaire pour les développeurs comme étant un requis du client et non une nécessité. En fait, plus souvent qu’autrement le développeur se retrouve à faire de la documentation à plein temps sur un logiciel qu’il développe ou qu’il doit développer. Souvent cette documentation ne sera jamais utilisée par les programmeurs. Donc, le fait de charger au client pour cette documentation extra de la même façon que pour des fonctionnalités logiciels est selon moi un bonne pratique.

Le changement

La méthodode XP permet au client de modifier ses spécifications en cours de route. Très utile lorsque le client n’a pas une idée ferme car il peut changer l’orientation que prend le projet à n’importe quel moment. Cela reflète plus la réalité que ce qui se fait chez les autres pratiques connues. Souvent lorsque le client décide de changer quelques fonctionnalités en cours de route : plusieurs documents doivent être modifiés, l’architecture doit être repensé, etc. Enfin tout un processus qui selon moi est très lourd se met en place et coûte très cher au client. XP par sa méthodologie logicielle allégée destinée à réduire le coût du logiciel est plus adapté à ce type de modification lors du développement du système

La productivité

La pratique XP est conçue pour une équipe de 2 à 10 personnes. Cela permet aux développeurs de bien connaître l’ensemble du projet qu’ils développent et aussi d’avoir une belle synergie au sain de leur équipe de développement.

En plus, elle favorise la productivité des développeurs car ils doivent toujours être alerte aux différentes questions de leurs pairs concernant le code qu’ils sont en train de faire. Comme le nom de cette méthodologie peu le laisser sous-entendre, « eXtrème Programming » elle pousse le développeur à l’extrême et l’oblige à donner sont « 110 pour cent. »

La livraison régulière des versions permet de motiver le client et le développeur. Tout le monde est en mesure de voir l’évolution du système. Le client peu enfin suivre cette évolution pendant que les développeurs bâtissent le logiciel. Ils n’ont plus à attendre des mois avant de voir leur logiciel en production. Chaque itération dure de 1 à 4 semaines ce qui donne un haut taux de « feedback ». Cela permet d’avoir assez rapidement des commentaires de la part du client. Ce processus permet d’avoir du code dynamique et continuellement en changement. Quiconque est en présence d’un bout de code très compliqué est encouragé et en mesure de le simplifier. Finalement, l’intégration du code plusieurs fois par jour force les développeurs à communiquer et à bien comprendre le fonctionnement et le processus de développement du système qu’ils bâtissent.

Le « eXtreme Programming » est une méthode qui ne propose rien de nouveau. Toutes les techniques utilisées sont déjà connues (utilisation de standards, utilisation des tests unitaires, utilisation de tests de régression, bonne communication, etc.).

Ce qui est très difficile à accepter dans les processus de XP est :

1. De ne pas documenter le code ;

2. De ne pas avoir de documentation externe ;

3. De dire que les tests unitaires sont plus importants que le code en soit.

Néammoins la méthode XP (eXtreme Programming) est une méthode ayant de l’avenir et qui devrait s’appliquer à tous les petits projets où le client n’est pas totalement sûr de ce qu’il veut.

Filed under:
Agile, agile, eXtreme Programing, extreme Programming, Extreme Programming, Méthodes Agile, XP, XP by admin