Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

Principes de l'eXtreme Programming

Pour réagir sur cet article, un espace de dialogue vous est proposé sur le forum : Commentez Donner une note à l'article (0)

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Spécifications itératives par le client

La mise en œuvre de XP est basée sur des principes que l'on retrouve tout au long de la vie du projet et qui régissent le cycle de vie de ce dernier.

Avec des méthodes classiques, plus le temps passe, et plus les réalisations semblent s'éloigner du souhait (changeant !) du client. Alors le mieux est de réaliser de nombreuses itérations…

I-A. Diviser pour mieux régner

Cette expression va vraiment dans la philosophie d'XP, si bien sûr on ne parle pas dans le sens péjoratif qui est de diviser l'équipe, mais de se séparer pour arriver à de meilleurs résultats !

I-A-1. Des spécifications régulières

Tout projet commence obligatoirement par les précisions de la demande du client : les spécifications. Cependant, avec XP, cette première phase ne prend pas le temps généralement constaté. En effet, ne dit-on pas « diviser pour mieux régner » ? C'est tout à fait la façon de penser de XP.
Plutôt que de tout spécifier au début du projet, le client (on entend par client une personne ayant une vision d'utilisateur final et habilitée à définir les besoins du projet et ses priorités) va expliquer aux développeurs la première fonctionnalité qui est pour lui la plus importante. Cela se fait lors de réunions nommées les « planning game » où la discussion entre les développeurs et le client est très importante. On y discute des spécifications, des solutions et du planning. Ensuite, les informaticiens s'attachent à implémenter cette première demande dont le temps de développement ne devra dépasser une à deux semaines.

I-A-2. De nombreuses itérations

Chaque partie du projet, qui devient très itératif, est ainsi divisée en sous-modules qui doivent être opérationnels au bout d'un intervalle de temps prédéfini relativement court.
À la fin de chaque itération, une minilivraison est faite permettant au client de déjà « s'amuser » avec le produit, de le tester et de se rendre compte du résultat final. Grâce à ces premiers essais, le client peut demander des améliorations, des réorientations plus ou moins profondes au développeur qui a une grande réactivité puisque tout est encore « chaud » dans sa tête. Une fois que la fonctionnalité est validée, on passe à une autre période de spécification, etc.
Avoir plusieurs changements au fur et à mesure est d'ailleurs une chose préférable à un grand chamboulement !
Dans la pratique, un délai de trois semaines est généralement choisi par l'équipe pour une fonctionnalité à tester. Ces délais sont bien sûr révisables, mais sont généralement considérés comme optimaux par l'équipe et le client.

I-B. Définition des besoins par des user stories

Traduit en français, user stories signifie « histoires de l'utilisateur » et c'est bien ce que ça représente : récit de ce que veut l'utilisateur.

I-B-1. Définition

On demande donc au client de définir les spécifications en petites histoires testables en une à deux semaines. Or, n'arrive-t-il jamais que le client ne sache pas comment faire ? Après tout, chacun sa spécialité ! En fait, la question ne se pose pas, car dans XP, le client utilise des « user stories » pour définir ses besoins. Comme leurs noms l'indiquent, ces fonctionnalités nécessaires à l'utilisateur sont décrites à la façon d'une bande dessinée (contenu simple et imagé), sur des fiches Bristol format A5. Elles sont donc courtes et n'abordent pas les considérations techniques pour rendre la production la plus intuitive possible. On doit utiliser des métaphores pour que tout le monde puisse bien se comprendre. Tout doit rester bien concret avec XP !

Inévitablement, les besoins ne sont pas suffisamment précis. Le développeur est donc dans l'obligation de dialoguer avec le client pour obtenir les détails ce qui favorise encore une fois l'établissement d'une réelle communication.

I-B-2. Points forts et faiblesses

L'un des avantages de cette technique est que l'utilisateur écrit vraiment ses besoins, alors que dans une approche plus classique le développeur (ou l'ingénieur d'affaires ou le chef de projet) retranscrit plus ou moins bien ce qu'il a compris.
Ainsi, le résultat est fondamentalement différent. En effet, les user stories sont vraiment une technique d'expression des besoins alors que les cas d'utilisation, demandés par les méthodes classiques (UML), se cantonnent souvent à une translation des besoins. De plus, l'implication du client est également sans commune mesure. Dans XP, il est effectivement partie prenante dans le pilotage du projet, itération après itération.
Toutefois, le niveau de détail d'une « user story » est inférieur à celui d'un cas d'utilisation UML. Pour cause, elle n'est constituée que d'un titre, d'une ou deux phrases d'explication du fonctionnement voulu et d'un schéma, sans aborder les conditions d'erreurs et les traitements associés.
Aussi, XP se voulant très itératif, son contenu ne pourra excéder un cycle d'itération ou dans le cas contraire, l'user story devra être découpée. À l'opposé, une user story trop légère sera fusionnée avec un autre Bristol.

I-C. Les prévisions détaillées

Le rôle d'un chef de projet est souvent décrit comme la personne qui planifie. Qu'en est-il de cette problématique avec XP ?

I-C-1. Des estimations précises

Grâce à ces jalons fréquents, on peut se permettre de prévoir avec une plus ou moins grande précision les délais et la date de fin du projet : chaque fiche correspond à une itération dont la durée est approximativement connue. Cette durée est composée d'unités arbitraires (XP units ou gummy bear) dont la valeur est discutée avec le client et dont le nombre est défini par les développeurs. En effet, seuls ces derniers connaissent précisément le temps qui leur est nécessaire, en fonction de leurs compétences et de leurs expériences, pour aboutir au résultat décrit dans la fiche. D'ailleurs, pour se décider, le développeur peut utiliser son PC pour faire de l'expérimentation, ce qui est nommé « spike solutions ».
De même, on peut prévoir les coûts humains puisque chaque user story engendre un cycle de développement d'une ou deux paires de programmeurs.

I-C-2. Des mises à jour régulières

À noter que ces prévisions peuvent, bien sûr, être renégociées et reconsidérées puisque le projet est revu à chaque itération. Cela, pour deux raisons : la première est que tout ne se passe jamais comme prévu (une équipe de développeurs peut rester bloquée sur un problème qui ne semblait pas complexe par exemple). La deuxième vient du fait qu'avec XP le client peut se permettre de changer, compléter ou de supprimer sa demande.
Quoi qu'il en soit, plus on arrivera vers la fin du projet et plus les estimations seront précises, notamment avec l'augmentation des compétences des programmeurs leur permettant d'affiner leurs estimations.
Les prévisions reprécisées régulièrement, à chaque itération, permettent de donner aux directions des chiffres précis et en temps réel, pour anticiper des dérapages éventuels et diminuer les risques de dépassement. En connaissance de cause, les responsables pourront ainsi ajouter, si nécessaire, des ressources pour respecter les délais, redéfinir les objectifs ou, même, décider de stopper le projet, s'il semble s'avérer irréalisable, avant que les pertes ne soient trop grandes.

II. Les tests écrits avant le programme

Après avoir obtenu des user stories précises, les développeurs entrent en jeu plus activement. Leur première activité après les spécifications, n'est pas de coder les fonctionnalités, mais les tests. « Écrire les tests puis coder : si vous ne le faites pas, vous n'êtes pas un Extreme Programmer » affirme Kent Beck.
Avec le principe de ne travailler que par itérations courtes, le processus de test se voit pour cela aussi modifié.

II-A. Écrire les tests avant tout

XP se veut totalement novateur dans le domaine des tests. En effet, les tests jouent un rôle fondamental dans XP à tel point que leur importance est comparable à celle de la programmation elle-même.
D'ailleurs, on considère que les tests sont une partie intégrante de la documentation puisque que la programmation de conditions de tests est une indication directe sur la façon d'utiliser l'élément testé.

II-A-1. Des tests écrits tôt et automatisés

Avec XP, dans la pratique, la mise en place des tests demande une rigueur importante. Le but est de réaliser à chaque itération des tests fonctionnels définis par les souhaits du client. Ainsi, le développeur écrit donc le programme de test unitaire à partir de souhaits du client et cela, AVANT le code de l'application.

D'écrire les tests avant, permet de ne rien oublier puisque les spécifications viennent d'être exposées par le client. De plus, on code les tests, qui sont garants de la qualité du produit final, quand on n'est pas encore lassé du développement, avant les fatigantes séances de développement…

Une telle rigueur n'est que très rarement demandée dans les méthodes de gestion de projets informatiques. La phase de tests y est souvent complètement disjointe de la programmation et même parfois faite par une tout autre équipe. Or, cela entraîne forcément des pertes de temps puisque le codeur doit prendre le temps de comprendre l'application et parce que le développeur doit se remettre en tête le code à déboguer après cette phase de test plus ou moins longue !

Avec XP, les tests sont écrits au début, mais sont aussi caractérisés par leur automatisme ! Ainsi, lancer un test ne revient pas à plusieurs tâches laborieuses à faire les unes à la suite des autres. Tout est regroupé dans une fonction « main » qu'il suffit de lancer. Si tout se passe bien, on le sait tout de suite et si un problème survient, nos propres commentaires permettent de savoir d'où vient l'erreur.
En tout cas, il faut noter que le résultat ne peut être que dichotomique : soit le module fonctionne parfaitement bien dans sa globalité et on peut continuer, soit il faut corriger les problèmes avant de passer à autre chose.

II-A-2. Les deux types de tests

XP définit deux types de tests. Les premiers sont les tests de recettes ou tests fonctionnels qui sont rédigés par le client, à partir d'un langage formel si possible. Comme leur nom l'indique, ces tests (Acceptance Tests) servent à valider le travail du prestataire, comme on peut le voir dans les projets classiques avec un cahier de recettes. Ainsi, il s'agit tout simplement de vérifier que tout fonctionne correctement et est conforme à la demande, avant de donner le dernier chèque… Mais, avec XP, le client définissant au fur et à mesure ses besoins aux développeurs, il n'y a généralement pas de grandes surprises lors de ces tests…

Le deuxième type de tests que recense XP est le test unitaire (Unit Testing). On appelle généralement test unitaire, tout test écrit par l'un des programmeurs dans le but de s'assurer du bon fonctionnement de son programme. Avec XP, c'est la même signification sauf qu'ils sont plus nombreux et plus fréquents. Ainsi, au contraire du test de recette, son but n'est pas de satisfaire le client directement, mais permet de vérifier la qualité du développement. Ces tests sont, bien sûr, écrits comme les autres avant le codage et sont exécutés après chaque phase de codage.
Ils doivent tester généralement une itération et leur durée d'exécution est comprise entre une et dix minutes. Au-delà, ils doivent être découpés.

Ces tests sont les plus importants, car ils garantissent la stabilité du produit et cela, dès le début, pour éviter de partir sur des bases bancales. Pour cause, ils garantissent la qualité du produit, mais incitent aussi le développeur à réfléchir sérieusement sur la conception, puisqu'ils sont réalisés avant le code. Ils peuvent être alors considérés comme plus « contractuels » que les tests de recettes qui découlent de ceux-là.

Pour écrire ces tests, la démarche est la suivante : on commence par écrire le test puis on l'exécute après la compilation qui garantit la logique du code. Puisque le test est codé avant le programme, le test échouera. Une fois que le code de l'application est écrit, il devra par contre réussir.
Une modification du code (refactoring) ne devra en aucun faire échouer les tests qui garantissent donc, dès le début, la conformité du développement. Par contre, un changement dans le caractère fonctionnel du code rappellera au développeur que ce changement est peut-être inutile, car non demandé par le client.

II-B. Un produit fiable et toujours opérationnel

Le rêve, diront en cœur développeurs et clients… Avec XP, le rêve peut devenir réalité !

II-B-1. Des tests conformes à la demande du client

Les tests systématiques assurent que le système en cours de création est constamment opérationnel puisqu'un dysfonctionnement provoqué par une évolution du code source est tout de suite détecté et donc rapidement corrigé.

De ce fait, le client peut toujours connaître l'avancement exact du projet et surtout obtenir des livraisons régulièrement.
Aussi, la livraison, qui peut se faire donc dès la fin du développement, est donc celle d'un produit totalement fonctionnel et sans aucun bogue.

En outre, les tests permettent d'analyser les résultats, déterminer ce qui vous ralentit, et améliorer les procédures pour aller plus vite, tout cela, presque en « live ».
Les tests étant écrits avant le codage, une fois que la partie programmation est finie, on peut tester tout de suite le module.
De ce fait, on peut obtenir très rapidement un feed-back du client qui validera la partie ou demandera tout de suite des modifications, tant que tout est « tout chaud » dans la tête du développeur.
On a donc à chaque itération, un raffinage instantané des besoins clients d'autant plus que chacune des modifications demandées est aussi testée jusqu'à une satisfaction totale du client.

Par conséquent, avec ces tests écrits avant le début de la programmation du logiciel, on obtient obligatoirement du code conforme à la demande. On évite aussi les oublis, car on ne programme que ce qui va être testé, c'est-à-dire tout ce qui est demandé.

II-B-2. Des tests optimaux pour une meilleure conception

Écrire les tests d'une classe avant même d'écrire la classe permet aussi de réfléchir à son fonctionnement dans sa globalité et à ses interfaces. Avec ce recul, puisqu'on ne se précipite pas tête baissée dans la technique, on peut remarquer, dès cette phase de conception, les oublis ou manques éventuels des user stories.

D'avoir les tests avant la fin du développement permet aussi de tester régulièrement le code créé, d'un point de vue syntaxique, sémantique, mais aussi logique. En effet, pour les langages assembleurs, seule la syntaxe était vérifiée, les compilateurs C s'occupent aussi de la sémantique et ceux des langages objets vont encore plus loin : « cet objet est-il bien utilisé ? » , « Cette méthode est-elle bien appelée ? ». Avec les bibliothèques de tests Junit (de Java) et CppUnit (de c++), la philosophie des tests performants est encore plus intégrée au langage lui-même !

Mais les tests présents dans les compilateurs ne peuvent aller plus loin et les fonctionnalités ne peuvent être testées. C'est pourquoi d'écrire les tests au début, permet d'avoir systématiquement et automatiquement, après chaque phase de développement, l'assurance d'avoir un module bien conçu et totalement correct.

D'ailleurs, on en arrive à se demander si ce n'est pas grâce aux tests que l'on arrive à programmer mieux et plus rapidement. Pour cause, on possède un garde-fou : si on fait quelque chose de faux, le filet de sécurité des tests intégrés au langage prévient qu'il y a un problème et montre même où il réside…

III. Programmation

Dans une méthode de gestion de projet de développement logiciel, on s'attache souvent à respecter beaucoup de règles d'organisation, mais on s'occupe beaucoup moins de la matière première du projet : le code source.

III-A. Un code propre et efficace

Tout comme le voulait notre maman : « je veux que ta chambre soit propre » ! C'est aussi ce que nous disent les XPiens, au sujet du code.

III-A-1. Programmer simple…

Pour développer avec XP, il faut respecter des règles précises qui ont beaucoup d'intérêts.
La conception doit être la plus simple possible (Simple Design) surtout, au début, puisque le code est susceptible d'être complètement modifié par la suite, en cas de changement de besoins.
Le code créé doit être composé de petites classes et de courtes méthodes. La relecture du code doit être la plus aisée possible. Cela passe aussi par l'utilisation de noms explicites pour les variables, les méthodes, etc. Élémentaire pourrait-on penser, eh bien oui ! XP utilise bien des principes de base « poussés à fond » !
La relecture passe aussi par la présence obligatoire de commentaires dans le code qui sont dans la pratique souvent bâclés. Il faut aussi penser à remettre à jour ces commentaires au même rythme que le code ce qui n'est malheureusement pas toujours le cas. Attention toutefois à ne pas inonder le code de commentaires. On doit insérer dans le code le strict nécessaire.
Aucune duplication de code ne doit exister, conformément au principe DRY (Don't Repeat Yourself) de « The Pragmatic Programmer ».
Grâce à l'application de ces règles, on obtient un code homogène pour toute l'application. Et pourtant, l'équipe est composée d'une dizaine de développeurs de générations différentes !

III-A-2. Du code propre grâce au refactoring

XP va plus loin encore dans la clarté du code. En effet, des séances de « refactoring » doivent avoir lieu régulièrement et au moins quotidiennement. Ce terme a été défini et décrit très en détail par Martin Fowler dans son ouvrage « Refactoring, Improving the Design of Existing Code » qui n'est pas disponible en version francophone. Sa définition est « toute modification d'un programme permettant d'en améliorer la structure interne sans en modifier le comportement externe ».
Pendant ces périodes, le développeur permet de prendre un peu de recul sur le code et de revoir d'un côté l'architecture du programme et de l'autre, la simplicité du code. Par exemple, il s'agit de décomposer les algorithmes en entités très courtes à placer dans des méthodes distinctes, de donner des noms clairs aux variables et méthodes et surtout de positionner correctement dans l'espace, les blocs formés par les boucles et les conditions.
Ainsi, un « extrême développeur » se doit d'améliorer fréquemment le code existant afin qu'il puisse mieux s'adapter aux exigences du lendemain.

III-B. L'organisation du développement

Le développement est loin d'être une simple tâche de dactylographie. Cette activité se doit donc d'être bien organisée, et d'autant plus avec XP.

III-B-1. Pair Programming

Concernant le développement, une caractéristique de XP, qui est aussi la plus controversée, est la programmation par binôme, c'est-à-dire, deux développeurs pour une machine. Et le but n'est pas dans cette démarche de faire des économies de matériel informatique…
Les règles pour réaliser cette pratique sont strictes. Il ne s'agit pas de permettre à l'un de se reposer pendant que l'autre travaille. Chacun programme sa partie de code, dont il reste propriétaire. La programmation se fait alors à tour de rôle et l'échange du clavier est régulier, soit à la fin de chaque classe ou quand la fatigue commence à trop peser.
Dans la programmation en binôme, la personne qui ne tape pas au clavier peut réfléchir à la suite, à l'architecture globale de l'application, vérifier la frappe et surtout commenter pour faire évoluer le code. Une personne produit donc le code (le « driver ») tandis que l'autre prend du recul pour vérifier la cohérence globale et réfléchir à la conception générale. Le « partner » garde aussi à portée de main les règles de XP ! Cela permet aussi d'avoir une autre personne qui sait ce qui a été fait et qui est capable de continuer au cas où (accident ou vacances).
Aussi, il est important que les binômes changent régulièrement, c'est-à-dire à chaque nouvelle itération d'un à deux jours. Ainsi, chacun travaille avec toutes les personnes de l'équipe, ce qui permet forcément d'un rapprochement et permet aussi un partage de savoir entre les développeurs. Aussi, si un binôme reste bloqué, leur discussion peut être entendue par une autre personne de l'open workspace (grand bureau partagé par plusieurs personnes), qui pourra venir apporter son aide.
La première critique qu'on pourrait faire à ce principe est la perte de productivité globale. Pourtant, ce fondement fait la force de XP, car, dans la pratique, le rendement horaire s'approche de 1. Pour cause, la fatigue de l'un est compensée par l'énergie de l'autre et ils s'autodisciplinent. Aussi, de grandes économies sont réalisées pour la phase de débogage puisqu'on s'offre une relecture constante du code.

III-B-2. Des développeurs heureux

XP se veut une méthode humaine et plutôt orientée vers le confort des développeurs et cela pour plusieurs raisons. La première est que la communication est grande et notamment grâce aux « stand-up meeting », réunions debout (pour s'assurer qu'elles ne s'éternisent pas) quotidiennes qui permettent d'exposer la situation de chacun, les éventuelles demandes d'aide… Aussi, le développeur a la possibilité de choisir l'itération qu'il souhaite traiter, à condition bien sûr que le sérieux de l'équipe soit assez grand pour ne pas laisser traîner une tâche lassante qui peut ralentir l'avancée globale du projet. Ainsi, les développeurs ne se sentent pas frustrés par l'autoritarisme d'un boss, qui ne fait alors plus que motiver son équipe…
Chacun ne peut aussi refuser d'apporter son aide à un collègue !
Grâce à tout cela, naît aussi un réel esprit d'équipe et réelle dynamique de groupe. Les développeurs jouent pour gagner (et non pour participer) et cela fonctionne !
Dans la pratique, on a pu aussi constater que les développeurs étaient plus motivés, heureux et compétents.
Enfin, XP préconise de ne pas réaliser d'heures supplémentaires (si si !), en tout cas, jamais deux semaines de suite. Une semaine de travail ne devra qu'exceptionnellement dépasser 40 heures (comme pour les « 40-hour week » des États-Unis). En effet, une telle surcharge indique un problème structurel, de planning, plutôt qu'un problème de productivité. De plus, la réalisation d' « heures sup » ne peut qu'avoir un effet néfaste sur la productivité, la motivation et surtout sur la qualité du code !

IV. Documentation

Avec les commentaires du code pourtant complets, il faut quand même prévoir une petite documentation. En effet, XP n'est pas antidocumentation, par contre, la méthode se veut très vigilante à la quantité des documents.

IV-A. Uniquement deux types de documents

Par conséquent, il faut bien se demander quels documents sont réellement utiles. À ce sujet, il faut distinguer deux types de documents correspondant aux deux types de destinataires, les informaticiens et le client. Pour ce dernier, ils ne peuvent être réduits, voire supprimés puisqu'ils apparaîtront dans le décompte final de la facture.
Par contre, une importante réflexion doit avoir lieu avant de commencer toute rédaction. En effet, il faut bien avoir en tête que de bons commentaires devraient suffire et surtout que le travail en équipe et plus particulièrement par deux tel que le définit XP, ne devrait pas engendrer de documentation complémentaire.

Aussi, la création de documentation ne permet en aucun cas d'augmenter la vitesse de programmation, de rendre le système plus fiable ou même de le rendre plus facile à maintenir. Les seuls intérêts qui pourraient être envisagés seraient une éventuelle aide à la relecture par une autre équipe, une éventuelle lecture pour les clients ou enfin un support pour la publication d'articles. Or, ces cas ne semblent guère fréquents, voire exceptionnels.

IV-B. Des formes bien précises…

Toutefois, il peut arriver qu'une documentation soit nécessaire dans un cas où la globalité du projet serait difficile à voir. Mais dans ce cas, il faut bien s'interroger sur l'utilité effective de ce document qui ne doit être en aucun cas être redondant par rapport à un éventuel dossier existant. Aussi, le document final ne devra en aucun cas excéder dix pages et devra mixer textuel, diagrammes (UML par exemple, mais épurés) et surtout rediriger vers les fichiers source (le code) et leur « javadoc » (documentation au format HTML créée automatiquement par Java, à partir des commentaires du code). Notons bien qu'on pourra s'aider des tests qui mettent en avant les fonctionnalités essentielles de l'application.
Pour conclure, concernant les spécifications pour la documentation, on retrouve bien le principe YAGNI (You aren't gonna need it) de XP avec la suppression de tout travail inutile. Encore une fois, ce principe tout simple est une grande innovation puisque dans les autres méthodes, une documentation de plusieurs dizaines de pages est demandée alors qu'elle ne sera probablement jamais lue par personne.

V. Intégration - Livraison

Le fait que XP ne permet pas réellement de prévoir à long terme les échéances ne pose en aucun cas un problème pour les livraisons.
En effet, les intégrations des classes développées sont faites plusieurs fois par jour ou au moins tous les soirs ! Les tests sont alors lancés pour vérifier la cohérence et la non-régression du produit.
Cela a l'avantage d'avoir un produit fonctionnel toujours à jour, ce qui est permis par le fait que les tests sont écrits auparavant. Ainsi, un « eXtreme Programmer » ne sera que très rarement contraint de passer des week-ends ou des nuits à développer pour respecter une deadline. Cela permet aussi de permettre à l'équipe et au client de connaître précisément l'avancement.
À tout moment, on peut donc fournir au client un produit utilisable, bien que les livraisons soient prévues environ tous les trois mois. Chaque trimestre, un module entier et complètement fonctionnel est donc réceptionné et validé par le client, ce qui permet d'obtenir des paiements (restons concret tout de même !).

VI. Conditions de mise en œuvre

Extreme Programming apparaît comme la plus radicale des méthodes agiles. De ce fait, elle draine autour d'elle d'« extrémistes » et farouches opposants. Parmi eux, le plus actif est sans conteste Matt Stephens qui critique la méthode dès qu'une occasion se présente (notamment sur plus d'une trentaine de pages sur Internet d'après Google).

VI-A. Des équipes particulières

Le facteur humain est très important pour la réussite d'un projet, XP en est bien conscient…

VI-A-1. Une composition d'experts

Les buts de XP sont de pallier des carences constatées dans les projets informatiques. Cependant, il ne peut y avoir d'évolutions sans compétences de ses acteurs.
C'est pourquoi les premières limites à l'utilisation de cette méthode sont les capacités techniques de chaque membre de l'équipe et ses capacités relationnelles. En effet, chacun devra être capable d'assumer une productivité optimale (pendant 35 heures par semaine, soit…) puisque règne le « death march », c'est-à-dire une grande conscience professionnelle pour finir le projet dans les délais.

Aussi, le niveau technique exigé pour un développement avec XP ne demande pas qu'une bonne connaissance dans le langage de programmation, mais aussi en génie logiciel. En effet, pour construire des choses solides, il faut avoir mis en place une architecture habile et puissante.
De plus, du fait de la perpétuelle remise en question possible du produit par le client, clients et développeurs sont disposés à faire évoluer leur façon de faire. Cela demande encore une équipe courageuse et très ouverte.
Enfin, avec cette méthode moins structurée, certains développeurs, surtout les plus jeunes peuvent souffrir de l'absence d'un cadre formel structurant qui n'apporte pas l'aide que peut fournir une méthodologie offrant plus de repères.
De même, la plupart des responsables peuvent ne pas se sentir à l'aise ou redouter plus les pépins…
Finalement, les membres de l'équipe doivent donc être performants et polyvalents, ce qui n'est pas forcément inné chez tous les ingénieurs.

VI-A-2. Une taille d'équipe limitée

Jusqu'à présent, XP n'a été utilisé que par des équipes de deux à dix développeurs.
Au-delà de douze personnes, certaines pratiques de XP ne peuvent plus être adaptées en raison de l'alourdissement des procédures et des problèmes de communication qui apparaissent. Cela est contraire aux principes mêmes de XP !
Alors, aussi efficace que la méthode puisse être, elle ne peut malheureusement pas se généraliser à toutes les organisations et donc à toutes les entreprises.

VI-A-3. Des experts en relationnel

Avec XP, chacun devra faire preuve d'un bon esprit relationnel pour discuter et négocier avec le représentant du client, c'est-à-dire la personne qui paye !
Aussi, la communication doit être bonne avec l'équipe et plus particulièrement le binôme, qui change en permanence, ce qui oblige à travailler avec des personnes de tout âge, ou qu'on n'apprécie pas forcément…
Enfin, il ne faut pas négliger le fait que certains développeurs sont littéralement « paralysés » dès lors qu'ils se sentent observés…

VI-B. Pour des projets particuliers

Le monde de l'informatique est très éclectique, et cela se retrouve dans les projets…

VI-B-1. Le code, source de conflits ?

Avec XP, une classe appartient à une seule et unique personne, ce qui la responsabilise, mais le code de l'application appartient à toute l'équipe et est donc consultable par tous. Cela a l'avantage de permettre à tous, une connaissance et une visibilité globale du projet. Chacun est soucieux de la qualité globale du projet et peut être fier de sa contribution.
Cependant, si le niveau des développeurs est peu homogène, cela peut entraîner, du fait de la confiance qu'accorde XP aux développeurs, des pertes de qualité. Aussi, des critiques peuvent apparaître, voire des conflits, en raison du refactoring qui permet à chacun, dans un but d'optimisation, de modifier le code, ce qui peut en vexer plus d'un…
XP, par ses exigences, implique aussi une restriction dans le choix des langages à utiliser. En effet, le choix devra se porter sur un langage objet qui favorise des itérations courtes et qui permet la mise en œuvre facile de tests.
Parmi ceux correspondant à cette caractéristique, on trouve le Smalltalk, Python ou Perl, et plus généralement les langages de scripts, mais qui sont de moins en moins enseignés.
Aujourd'hui, ceux qui ont « remporté » le choix des XPiens sont donc le C++ et le Java. Toutefois, le premier est reproché pour sa difficulté de débogage (allocation mémoire, erreurs de compilation, d'exécution…) et commence d'après certains à faire un peu vieillot par rapport au miraculeux Java. (Pour plus d'info sur les différences en Java et le C++ : xpose.free.fr.) Avec ses classes JUnit, c'est donc Java qui apparaît comme le plus adapté. D'ailleurs, XP est décrit et conseillé dans le livre « Thinking in Java ».
Mais dans la pratique, tous les développeurs partagent-ils tous cette préférence ? La culture d'entreprise a-t-elle déjà intégré l'utilisation de Java ?

VI-B-2. Pour des projets de petite envergure

XP ne peut s'adresser qu'à des projets petits ou moyens en raison de ses caractéristiques.
En effet, une itération de trois semaines ne semble pas réaliste pour une équipe de 100 développeurs, trois semaines étant approximativement le délai pour, tout simplement, contacter et informer l'ensemble des personnes…
La communication, le feedback, les itérations courtes ne peuvent s'accommoder d'un grand projet.
Aussi, l'investissement de tous est demandé pour un projet XP. Quand l'équipe s'agrandit cette demande n'est-elle pas trop utopique ?
À nouveau, les principes mêmes de XP ne permettent donc pas de généraliser la méthode à l'ensemble du monde informatique.

VI-B-3. Le client sur place

XP demande à l'organisation de pratiquer des tests très peu espacés dans le temps et en présence d'un représentant du client afin d'avoir un feedback constant. D'autant plus en raison du mode de données des spécifications et de l'intégration quotidienne qui obligerait le client à conserver un de ses responsables pendant des mois avec les développeurs, sans qu'il soit réellement productif.
Ainsi, et c'est probablement un des freins à l'adoption de XP, une mutation dans le rapport client-développeurs doit avoir lieu pour respecter les principes de la méthode puisqu'elle suppose une souscription du client à la plupart des journées de développement.
Le client doit donc être intégré à l'équipe de développement, être dans le même bureau (On-Site Customer), ce qui se marie mal avec le principe même de la sous-traitance qui est une grosse partie du marché de l'informatique…

VII. Note de la rédaction de Developpez.com

Nous tenons à remercier Claude Leloup pour la relecture orthographique.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2017 Adrien Machado. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.