Extreme Programming : développement de logiciels poussé à l’extrême

Il existe désormais des pratiques extrêmement variées du développement agile de logiciels. Outre le scrum et le kanban, l’extreme programming est toujours envisagé et appliqué. Qu’est-ce qui est si extrême dans ce mode de développement ?

L’extreme programming (XP) est considéré – d’où son nom – comme la mise en œuvre la plus radicale du développement agile de logiciels. En d’autres termes : il n’existe probablement pas de méthode plus agile que XP par rapport aux modes de programmation traditionnels. L’extreme programming se démarque donc concrètement aussi du modèle en cascade par exemple, qui présente de nombreux problèmes d’après les inventeurs de XP. Au milieu des années 1990, les développeurs Kent Beck, Ward Cunningham et Ron Jeffries ont décidé de bouleverser la méthode de travail classique et de suivre une autre route.

En principe, l’extreme programming est axé sur les exigences du client. Une évidence à priori ! Le développement de logiciels classique ne peut pourtant répondre aux désirs des clients que dans une certaine mesure, les choses se compliquant notamment quand ces désirs changent régulièrement. XP tente par ailleurs de stimuler la créativité des développeurs et accueille les erreurs comme un facteur évident dans le processus de travail.

Simultanément, XP, comme d’autres méthodes agiles, part de processus itératifs. La conception de A à Z d’un gros projet sur plusieurs mois avant de se rendre compte à la fin que le résultat n’est pas probant, XP n’en veut pas ! Il se fonde à la place sur des cycles courts impliquant des tests, des discussions et des livraisons continus. Les erreurs peuvent ainsi être détectées et éliminées rapidement.

Pour répondre aux exigences, on a développé un framework très net qui part de différents principes, valeurs et techniques. Des rôles concrets sont par ailleurs attribués pour pouvoir répartir clairement les tâches.

XP repose sur cinq valeurs fondamentales dont le but est de faire évoluer l’attitude générale à l’égard du travail de programmation. L’équipe doit respecter collectivement une mentalité donnée afin de pouvoir travailler au mieux ensemble et créer un produit de premier ordre.

La communication est très importante dans le cadre du XP, que ce soit entre les membres de l’équipe ou entre les développeurs et les clients. Un échange permanent doit permettre de résoudre les problèmes directement. Ce n’est que si tous les intervenants sont en permanence en discussion qu’il sera possible de détecter des anomalies dans les meilleurs délais. La communication permet par ailleurs à tous de travailler avec le même état de connaissances et de se sentir liés au projet. Il faut ici privilégier de bonnes discussions sur site plutôt qu’un échange de messages écrits.

Avec XP, l’objectif est toujours la solution la plus simple. Cela comporte plusieurs avantages : en ne se concentrant que sur les facteurs requis, on ne perd pas de temps avec des considérations insignifiantes. Cela implique également de ne développer que les caractéristiques nécessaires à l’instant T, sans préparer en amont d’éventuelles exigences futures. L’équipe accélère ainsi le développement. Un produit épuré est par ailleurs nettement plus simple à gérer, que ce soit au niveau du perfectionnement ou des travaux de maintenance. De plus, un code de programmation simplifié facilite la compréhension, ce qui va également dans le sens de la valeur Communication : si toute l’équipe peut comprendre le code source, il est plus simple d’échanger à ce propos.

Cette valeur est elle aussi étroitement liée à la grande place accordée à la communication directe. Le client doit pouvoir exprimer ses critiques le plus souvent possible. Dans le cas de l’extreme programming, des messages du système (logs) sont aussi traités comme un retour d’information (feedback). Pour pouvoir mettre en place une culture du feedback au sens de XP, il est important de penser par petites étapes : l’équipe travaille dans des cycles courts, teste le code encore et encore, et présente l’évolution au client à intervalles réguliers. Il est ainsi possible de procéder à des modifications et d’éliminer des erreurs à court terme.

L’extreme programming entend par courage le fait d’être prêt à dire la vérité, même si elle n’est pas agréable à entendre. S’il y a des défauts dans le produit, il faut les pointer du doigt, même si on en est soi-même responsable. Dans une équipe qui travaille selon les valeurs XP, il n’y a pas de place pour les excuses. Aucun membre de l’équipe ne devrait tenter de minimiser sa participation à une erreur, car il se détournerait ainsi de l’objectif. Par ailleurs, la valeur dans ce contexte implique également d’avoir le courage de modifier des structures organisationnelles, de remettre en cause ses propres méthodes de travail, d’accepter la critique et de réécrire complètement le code, le cas échéant.

Pour que l’équipe puisse offrir des prestations exceptionnelles dans une ambiance harmonieuse, le respect mutuel est de mise. Cela se traduit également par le fait qu’un développeur ne sabote pas le travail d’un autre en procédant à des modifications. L’estime doit s’appliquer à tous, de l’équipe de travail au client final. Ce n’est qu’en prenant au sérieux les préoccupations de l’autre que l’on peut y réagir de manière appropriée. La direction doit enfin montrer elle aussi du respect vis-à-vis de l’équipe de développement et fournir aux collaborateurs les ressources nécessaires.

Dans le cas de l’extreme programming, les principes se situent à mi-chemin entre les valeurs et les pratiques : ils relient ainsi l’abstrait au concret. Les principes dérivent plus ou moins des valeurs définies précédemment.

Il faut demander un feedback le plus tôt possible et le mettre également en œuvre dans les meilleurs délais. Le système à proprement parler (lors du test du code) doit utiliser ces informations en l’espace de quelques secondes ou minutes, plutôt que de commencer par collecter le feedback par exemple. Le feedback des clients doit en revanche être demandé et pris en compte au bout de quelques jours ou semaines.

Le principe de simplicité correspond fondamentalement à la valeur du même nom, mais comprend des indications de mise en œuvre plus concrètes. Deux méthodes sont appliquées ici :

• You ain’t gonna need it (YAGNI) : tant qu’une fonctionnalité n’est pas concrètement demandée, elle ne devrait pas être mise en œuvre afin d’éviter tout travail inutile.
• Don’t repeat yourself (DRY) : éviter les doublons et créer le code de manière à ne devoir procéder à une modification qu’à un seul endroit et non à plusieurs.

Dans le cas de l’extreme programming, les modifications sont toujours réalisées par petites étapes. Au lieu de grandes mises à jour pour éliminer plusieurs sources d’erreur d’un seul coup, les problèmes sont traités individuellement les uns à la suite des autres. Cela permet à l’équipe de réagir plus rapidement et de mieux retracer les modifications. Mais ce principe ne s’applique pas qu’au code de programme. Même des modifications au niveau de la conception, voire dans la structure de l’équipe à proprement parler, doivent se faire par petites étapes incrémentielles.

Étant donné que l’extreme programming place le client au centre de l’activité, ses désirs de modification sont également hautement évalués. C’est la raison pour laquelle toute l’équipe doit accueillir positivement ces modifications plutôt que d’essayer de les contrecarrer. L’idée serait même plutôt d’inciter le client à exprimer ses désirs de modification plutôt qu’à l’en dissuader.

Cela semble banal, mais à bien y réfléchir, c’est très important pour le fonctionnement de l’extreme programming : l’équipe doit réaliser une prestation exceptionnelle. Le niveau d’excellence est défini par le client. Or pour pouvoir fournir un travail de qualité, le management est la clé. Si les facteurs sont bons, que l’équipe peut donc être satisfaite du travail fourni, les répercussions sur le moral des intervenants sont très positives.

Les pratiques de XP sont des consignes et des méthodes de travail très concrètes. Alors que les valeurs et principes présentés sont également appliqués dans d’autres méthodes de travail agiles, les techniques concrètes de l’extreme programming sont des caractéristiques uniques. Elles ont aussi légèrement évolué au fil du temps et sont différentes d’une source à une autre. De manière générale, les techniques se divisent en quatre domaines différents.

Dans le cadre de l’extreme programming, les équipes de développeurs travaillent dans des cycles extrêmement courts. Cela permet de tester encore et encore le code écrit. Le test unitaire ou Test-Driven Development va même jusqu’à écrire un environnement de test avant la création du code source à proprement parler. Le code ne passant pas ce test ne peut pas continuer à être développé. Le feedback vient donc ici du système même.

Le Planning Game est une réunion organisée au début de chaque phase de développement. L’équipe et le client se réunissent pour parler du travail accompli, donner un feedback et discuter des fonctions à venir. Les tâches sont ensuite distribuées.

L’idée d’un client sur site ou On-Site Customer contribue également aux feedbacks réguliers. Dans le meilleur des cas, au moins un représentant du client doit intégrer l’équipe afin de répondre rapidement aux questions ou amener des idées et définir des priorités.

Enfin, le pair programming applique le principe des quatre yeux : deux personnes travaillent toujours simultanément au code. Pendant qu’un collègue écrit le code, l’autre vérifie le code source, fait des propositions d’amélioration et signale des erreurs. Cette méthode est certes très coûteuse car deux collaborateurs doivent être affectés simultanément à une seule tâche, mais le code créé est finalement meilleur et requiert moins de rectifications.

Les équipes XP révisent leur code en permanence. Ce remaniement du code ou refactoring doit veiller à améliorer le code source ainsi qu’à éliminer des répétitions et des composants inutiles. Un code optimisé de la sorte est plus compréhensible, même pour des lecteurs externes, et donc moins source d’erreur.

Dans le cadre de l’extreme programming et d’autres méthodes de travail agiles, l’intégration continue permet aux équipes d’intégrer en permanence le nouveau code dans l’ensemble du projet. Plusieurs fois par jour, un développeur intègre son travail dans le projet. Les différentes contributions sont ainsi contrôlées en continu et tous les intervenants travaillent avec le dernier état.

La livraison des programmes et des mises à jour opérationnels se fait le plus tôt possible selon XP. Les petites livraisons ou Small Releases augmentent également la fréquence des feedbacks. Les erreurs peuvent ainsi être détectées plus rapidement et supprimées dès la mise à jour suivante. Le client a perpétuellement la possibilité de tester directement le dernier état du développement et de formuler des critiques et des propositions.

Avec une conception simple (Simple Design), le code est compréhensible pour tous les intervenants. Tout ce qui complique inutilement le code source doit donc être supprimé. Pour les développeurs qui travaillent suivant l’extreme programming, le but est d’éviter tous les doublons. L’objectif du programmeur concerné devrait par ailleurs ressortir clairement du texte source.

Pour que toute l’équipe puisse travailler main dans la main, des normes de codage ou Coding Standards sont en principe définies. Ces spécifications se rapportent à l’approche et au format. Les collègues doivent également pouvoir s’y retrouver dans le code des autres, et en même temps il faut toujours pouvoir retrouver qui a procédé à telle ou telle modification.

La possibilité de travailler ensemble sur le code renforce l’appropriation collective du code ou Collective Code Ownership : plutôt que d’indiquer qui est chargé de telle ou telle partie (et donc des erreurs qui y sont contenues), on considère le code comme un produit commun. Toute l’équipe en porte la responsabilité tant pour les erreurs que pour les réussites. Cette technique invite en outre à perfectionner le code d’un autre et à apporter ses idées.

Pour améliorer encore la compréhension du code source, on utilise dans l’extreme programming la technique des métaphores du système ou System Metaphor. Cette pratique consiste à décrire le projet de la façon la plus simple possible, même en employant des métaphores. Elle se réfère aux conventions de nommage visant à donner les noms les plus explicites possibles aux objets, classes ou fonctions dans le code. Les nouveaux collaborateurs qui sont venus se greffer au projet devraient ainsi pouvoir le comprendre rapidement. Même des personnes autres que des programmeurs peuvent ainsi avoir un aperçu du code source.

Dans l’extreme programming, les rôles servent à répartir les tâches et les compétences entre tous les intervenants, tant les développeurs que les clients.

L’extreme programming agit de manière très orientée client, ce qui peut aller jusqu’à intégrer le client comme un membre de l’équipe et à avoir au moins un représentant sur site (On-Site Customer). Le client pose ses exigences pour le produit, mais n’indique que partiellement la façon d’atteindre les objectifs. Seule la hiérarchisation des secteurs partiels relève de son domaine de compétences. Il doit ici également réussir à faire comprendre ses propres souhaits.

Le rôle du client peut être rempli par une personne ou une équipe de différents représentants du client. Dans la pratique, le chef de produit ou des collaborateurs du secteur marketing (toujours en fonction de l’objectif du projet) se chargent souvent de ces tâches.

L’équipe de développeurs n’est pas sous-divisée. Autrement dit : toute personne créant activement le produit prend la casquette de développeur. L’équipe regroupe donc non seulement les programmeurs, mais aussi d’autres personnes participant à la création, en fonction des exigences du projet. Outre le travail de développement effectif, la mission des développeurs est également de réagir aux désirs du client : évaluer la charge de travail, établir un calendrier, planifier la mise en œuvre.

Le développeur est parfaitement en droit de demander l’aide dont il a besoin, donc par exemple d’exiger de la direction qu’elle lui fournisse de plus amples capacités. La semaine de 40 heures s’applique par ailleurs aux développeurs conformément aux techniques de XP. Dans l’intérêt du projet, les développeurs ne doivent pas être surmenés. L’équipe de développeurs définit à cet effet elle-même son calendrier.

Le rôle du manager consiste à faire le lien entre les développeurs et les clients. Les personnes de ce groupe amènent les deux autres à une même table et animent par exemple le planning game. Le manager veille ici à ce que les règles définies au préalable ainsi que les conventions générales d’une discussion constructives soient respectées. Le manager endosse donc si nécessaire un rôle de médiateur.

Son rôle est parfois également qualifié de tracker (traqueur). En effet, l’une des missions du manager est de noter les indices de performance clés (p. ex. le temps que chaque collaborateur consacre au projet).

Toute l’équipe (y compris le client) doit savoir gérer l’extreme programming et pouvoir mettre en pratique cette méthode de travail de manière cohérente. Un coach peut contribuer à ce que tous se fassent une même idée des procédures. Il n’a rien à voir avec le développement du produit à proprement parler et ne sert que d’aide externe, de manière très similaire à un Scrum Master. Dans les discussions préalables, les règles et les pratiques peuvent être passées en revue avec cette personne. Le coach accompagne l’équipe idéalement pendant toute la phase de développement, est disponible pour répondre aux questions et aide à clarifier des points obscurs.

Un prestataire de services externe endosse souvent ce rôle. Il est néanmoins également possible que le coach vienne de l’entreprise, mais dans ce cas d’un autre secteur. Il faut éviter les doubles casquettes (un développeur prenant en plus le rôle de coach).

S’il a redynamisé le développement de logiciels, l’extreme programming ne convient pas dans tous les cas de figure ni à toutes les équipes. XP part du principe que le client, au début du projet, n’a encore aucune idée précise du produit fini. Dans un tel cas, le logiciel peut être planifié et développé de manière agile, c’est-à-dire petit à petit.

Il en résulte d’une part la satisfaction du client : on cherche collectivement avec lui la solution adaptée et il est associé à chaque étape. D’autre part, les développeurs peuvent mettre en œuvre des projets d’une façon qu’ils jugent appropriée plutôt que de devoir faire des compromis en permanence. Cependant, si le client vient voir l’équipe de développeurs avec une description finie du produit et une liste de fonctions, il sera alors très difficile d’employer XP.

Le pair programming notamment peut mettre de petites équipes dans l’embarras, car les capacités requises à cet effet ne sont pas disponibles. Les réunions régulières avec les clients demandent également du temps qui ne peut pas être réintégré dans le travail de programmation à proprement parler. Dans une situation idéale, cela n’a aucune importance : le résultat sera nettement meilleur si l’équipe peut prendre le temps nécessaire et disposer des ressources souhaitées.

Dans la pratique en revanche, un budget limité tout comme des délais de livraison clairement fixés mettent les développeurs sous pression. Par ailleurs, le client peut ne pas être intéressé ou ne pas être en mesure de prendre part au projet à la hauteur des exigences XP.

Si en revanche la situation permet de procéder selon l’extreme programming, une équipe peut fournir un résultat exceptionnel avec cette méthode. Les tests permanents génèrent des systèmes stables et le processus itératif garantit en combinaison avec l’approche minimaliste que seules des fonctions importantes pour le projet sont effectivement créées.