Principes de l'eXtreme Programming

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.

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.

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.

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.

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.

À 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.

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.

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.

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é.

É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…

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 !

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.

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.

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 !

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.

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.

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…

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 ?

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.

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…