Extreme Pro­gram­ming : dé­ve­lop­pe­ment de logiciels poussé à l’extrême

Il existe désormais des pratiques ex­trê­me­ment variées du dé­ve­lop­pe­ment agile de logiciels. Outre le scrum et le kanban, l’extreme pro­gram­ming est toujours envisagé et appliqué. Qu’est-ce qui est si extrême dans ce mode de dé­ve­lop­pe­ment ?

L’extreme pro­gram­ming (XP) est considéré – d’où son nom – comme la mise en œuvre la plus radicale du dé­ve­lop­pe­ment agile de logiciels. En d’autres termes : il n’existe pro­ba­ble­ment pas de méthode plus agile que XP par rapport aux modes de pro­gram­ma­tion tra­di­tion­nels. L’extreme pro­gram­ming se démarque donc con­crè­te­ment aussi du modèle en cascade par exemple, qui présente de nombreux problèmes d’après les in­ven­teurs de XP. Au milieu des années 1990, les dé­ve­lop­peurs Kent Beck, Ward Cun­nin­gham et Ron Jeffries ont décidé de bou­le­ver­ser la méthode de travail classique et de suivre une autre route.

En principe, l’extreme pro­gram­ming est axé sur les exigences du client. Une évidence à priori ! Le dé­ve­lop­pe­ment de logiciels classique ne peut pourtant répondre aux désirs des clients que dans une certaine mesure, les choses se com­pli­quant notamment quand ces désirs changent ré­gu­liè­re­ment. XP tente par ailleurs de stimuler la créa­ti­vité des dé­ve­lop­peurs et accueille les erreurs comme un facteur évident dans le processus de travail.

Si­mul­ta­né­ment, XP, comme d’autres méthodes agiles, part de processus itératifs. La con­cep­tion 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 im­pli­quant des tests, des dis­cus­sions et des li­vrai­sons continus. Les erreurs peuvent ainsi être détectées et éliminées ra­pi­de­ment.

Pour répondre aux exigences, on a développé un framework très net qui part de dif­fé­rents principes, valeurs et tech­niques. Des rôles concrets sont par ailleurs attribués pour pouvoir répartir clai­re­ment les tâches.

XP repose sur cinq valeurs fon­da­men­tales dont le but est de faire évoluer l’attitude générale à l’égard du travail de pro­gram­ma­tion. L’équipe doit respecter col­lec­ti­ve­ment une mentalité donnée afin de pouvoir tra­vail­ler au mieux ensemble et créer un produit de premier ordre.

La com­mu­ni­ca­tion est très im­por­tante dans le cadre du XP, que ce soit entre les membres de l’équipe ou entre les dé­ve­lop­peurs et les clients. Un échange permanent doit permettre de résoudre les problèmes di­rec­te­ment. Ce n’est que si tous les in­ter­ve­nants sont en per­ma­nence en dis­cus­sion qu’il sera possible de détecter des anomalies dans les meilleurs délais. La com­mu­ni­ca­tion permet par ailleurs à tous de tra­vail­ler avec le même état de con­nais­sances et de se sentir liés au projet. Il faut ici pri­vi­lé­gier de bonnes dis­cus­sions 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 con­cen­trant que sur les facteurs requis, on ne perd pas de temps avec des con­si­dé­ra­tions in­sig­ni­fiantes. Cela implique également de ne dé­ve­lop­per que les ca­rac­té­ris­tiques né­ces­saires à l’instant T, sans préparer en amont d’éven­tuelles exigences futures. L’équipe accélère ainsi le dé­ve­lop­pe­ment. Un produit épuré est par ailleurs nettement plus simple à gérer, que ce soit au niveau du per­fec­tion­ne­ment ou des travaux de main­te­nance. De plus, un code de pro­gram­ma­tion simplifié facilite la com­pré­hen­sion, ce qui va également dans le sens de la valeur Com­mu­ni­ca­tion : si toute l’équipe peut com­prendre le code source, il est plus simple d’échanger à ce propos.

Cette valeur est elle aussi étroi­te­ment liée à la grande place accordée à la com­mu­ni­ca­tion directe. Le client doit pouvoir exprimer ses critiques le plus souvent possible. Dans le cas de l’extreme pro­gram­ming, des messages du système (logs) sont aussi traités comme un retour d’in­for­ma­tion (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 à in­ter­valles réguliers. Il est ainsi possible de procéder à des mo­di­fi­ca­tions et d’éliminer des erreurs à court terme.

L’extreme pro­gram­ming 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 res­pon­sable. 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 par­ti­ci­pa­tion à une erreur, car il se dé­tour­ne­rait ainsi de l’objectif. Par ailleurs, la valeur dans ce contexte implique également d’avoir le courage de modifier des struc­tures or­ga­ni­sa­tion­nelles, de remettre en cause ses propres méthodes de travail, d’accepter la critique et de réécrire com­plè­te­ment le code, le cas échéant.

Pour que l’équipe puisse offrir des pres­ta­tions ex­cep­tion­nelles dans une ambiance har­mo­nieuse, le respect mutuel est de mise. Cela se traduit également par le fait qu’un dé­ve­lop­peur ne sabote pas le travail d’un autre en procédant à des mo­di­fi­ca­tions. 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éoc­cu­pa­tions de l’autre que l’on peut y réagir de manière ap­pro­priée. La direction doit enfin montrer elle aussi du respect vis-à-vis de l’équipe de dé­ve­lop­pe­ment et fournir aux col­la­bo­ra­teurs les res­sources né­ces­saires.

Dans le cas de l’extreme pro­gram­ming, 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é­dem­ment.

Il faut demander un feedback le plus tôt possible et le mettre également en œuvre dans les meilleurs délais. Le système à pro­pre­ment parler (lors du test du code) doit utiliser ces in­for­ma­tions 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 sim­pli­cité cor­res­pond fon­da­men­ta­le­ment à la valeur du même nom, mais comprend des in­di­ca­tions de mise en œuvre plus concrètes. Deux méthodes sont ap­pli­quées ici :

• You ain’t gonna need it (YAGNI) : tant qu’une fonc­tion­na­lité n’est pas con­crè­te­ment 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 mo­di­fi­ca­tion qu’à un seul endroit et non à plusieurs.

Dans le cas de l’extreme pro­gram­ming, les mo­di­fi­ca­tions 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 in­di­vi­duel­le­ment les uns à la suite des autres. Cela permet à l’équipe de réagir plus ra­pi­de­ment et de mieux retracer les mo­di­fi­ca­tions. Mais ce principe ne s’applique pas qu’au code de programme. Même des mo­di­fi­ca­tions au niveau de la con­cep­tion, voire dans la structure de l’équipe à pro­pre­ment parler, doivent se faire par petites étapes in­cré­men­tielles.

Étant donné que l’extreme pro­gram­ming place le client au centre de l’activité, ses désirs de mo­di­fi­ca­tion sont également hautement évalués. C’est la raison pour laquelle toute l’équipe doit ac­cueil­lir po­si­ti­ve­ment ces mo­di­fi­ca­tions plutôt que d’essayer de les con­tre­car­rer. L’idée serait même plutôt d’inciter le client à exprimer ses désirs de mo­di­fi­ca­tion plutôt qu’à l’en dissuader.

Cela semble banal, mais à bien y réfléchir, c’est très important pour le fonc­tion­ne­ment de l’extreme pro­gram­ming : l’équipe doit réaliser une pres­ta­tion ex­cep­tion­nelle. Le niveau d’ex­cel­lence est défini par le client. Or pour pouvoir fournir un travail de qualité, le ma­na­ge­ment est la clé. Si les facteurs sont bons, que l’équipe peut donc être sa­tis­faite du travail fourni, les ré­per­cus­sions sur le moral des in­ter­ve­nants 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 tech­niques concrètes de l’extreme pro­gram­ming sont des ca­rac­té­ris­tiques uniques. Elles ont aussi lé­gè­re­ment évolué au fil du temps et sont dif­fé­rentes d’une source à une autre. De manière générale, les tech­niques se divisent en quatre domaines dif­fé­rents.

Dans le cadre de l’extreme pro­gram­ming, les équipes de dé­ve­lop­peurs tra­vail­lent dans des cycles ex­trê­me­ment courts. Cela permet de tester encore et encore le code écrit. Le test unitaire ou Test-Driven De­ve­lop­ment va même jusqu’à écrire un en­vi­ron­ne­ment de test avant la création du code source à pro­pre­ment 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é­ve­lop­pe­ment. L’équipe et le client se réu­nis­sent pour parler du travail accompli, donner un feedback et discuter des fonctions à venir. Les tâches sont ensuite dis­tri­bué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 re­pré­sen­tant du client doit intégrer l’équipe afin de répondre ra­pi­de­ment aux questions ou amener des idées et définir des priorités.

Enfin, le pair pro­gram­ming applique le principe des quatre yeux : deux personnes tra­vail­lent toujours si­mul­ta­né­ment au code. Pendant qu’un collègue écrit le code, l’autre vérifie le code source, fait des pro­po­si­tions d’amé­lio­ra­tion et signale des erreurs. Cette méthode est certes très coûteuse car deux col­la­bo­ra­teurs doivent être affectés si­mul­ta­né­ment à une seule tâche, mais le code créé est fi­na­le­ment meilleur et requiert moins de rec­ti­fi­ca­tions.

Les équipes XP révisent leur code en per­ma­nence. Ce re­ma­nie­ment du code ou re­fac­to­ring doit veiller à améliorer le code source ainsi qu’à éliminer des ré­pé­ti­tions et des com­po­sants inutiles. Un code optimisé de la sorte est plus com­pré­hen­sible, même pour des lecteurs externes, et donc moins source d’erreur.

Dans le cadre de l’extreme pro­gram­ming et d’autres méthodes de travail agiles, l’in­té­gra­tion continue permet aux équipes d’intégrer en per­ma­nence le nouveau code dans l’ensemble du projet. Plusieurs fois par jour, un dé­ve­lop­peur intègre son travail dans le projet. Les dif­fé­rentes con­tri­bu­tions sont ainsi con­trô­lées en continu et tous les in­ter­ve­nants tra­vail­lent avec le dernier état.

La livraison des pro­grammes et des mises à jour opé­ra­tion­nels se fait le plus tôt possible selon XP. Les petites li­vrai­sons ou Small Releases aug­men­tent également la fréquence des feedbacks. Les erreurs peuvent ainsi être détectées plus ra­pi­de­ment et sup­pri­mées dès la mise à jour suivante. Le client a per­pé­tuel­le­ment la pos­si­bi­lité de tester di­rec­te­ment le dernier état du dé­ve­lop­pe­ment et de formuler des critiques et des pro­po­si­tions.

Avec une con­cep­tion simple (Simple Design), le code est com­pré­hen­sible pour tous les in­ter­ve­nants. Tout ce qui complique inu­ti­le­ment le code source doit donc être supprimé. Pour les dé­ve­lop­peurs qui tra­vail­lent suivant l’extreme pro­gram­ming, le but est d’éviter tous les doublons. L’objectif du pro­gram­meur concerné devrait par ailleurs ressortir clai­re­ment du texte source.

Pour que toute l’équipe puisse tra­vail­ler main dans la main, des normes de codage ou Coding Standards sont en principe définies. Ces spé­ci­fi­ca­tions se rap­por­tent à 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 mo­di­fi­ca­tion.

La pos­si­bi­lité de tra­vail­ler ensemble sur le code renforce l’ap­pro­pria­tion col­lec­tive du code ou Col­lec­tive 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 res­pon­sa­bi­lité tant pour les erreurs que pour les réussites. Cette technique invite en outre à per­fec­tion­ner le code d’un autre et à apporter ses idées.

Pour améliorer encore la com­pré­hen­sion du code source, on utilise dans l’extreme pro­gram­ming la technique des mé­ta­phores 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é­ta­phores. Elle se réfère aux con­ven­tions de nommage visant à donner les noms les plus ex­pli­cites possibles aux objets, classes ou fonctions dans le code. Les nouveaux col­la­bo­ra­teurs qui sont venus se greffer au projet devraient ainsi pouvoir le com­prendre ra­pi­de­ment. Même des personnes autres que des pro­gram­meurs peuvent ainsi avoir un aperçu du code source.

Dans l’extreme pro­gram­ming, les rôles servent à répartir les tâches et les com­pé­tences entre tous les in­ter­ve­nants, tant les dé­ve­lop­peurs que les clients.

L’extreme pro­gram­ming 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 re­pré­sen­tant sur site (On-Site Customer). Le client pose ses exigences pour le produit, mais n’indique que par­tiel­le­ment la façon d’atteindre les objectifs. Seule la hié­rar­chi­sa­tion des secteurs partiels relève de son domaine de com­pé­tences. Il doit ici également réussir à faire com­prendre ses propres souhaits.

Le rôle du client peut être rempli par une personne ou une équipe de dif­fé­rents re­pré­sen­tants du client. Dans la pratique, le chef de produit ou des col­la­bo­ra­teurs du secteur marketing (toujours en fonction de l’objectif du projet) se chargent souvent de ces tâches.

L’équipe de dé­ve­lop­peurs n’est pas sous-divisée. Autrement dit : toute personne créant ac­ti­ve­ment le produit prend la casquette de dé­ve­lop­peur. L’équipe regroupe donc non seulement les pro­gram­meurs, mais aussi d’autres personnes par­ti­ci­pant à la création, en fonction des exigences du projet. Outre le travail de dé­ve­lop­pe­ment effectif, la mission des dé­ve­lop­peurs est également de réagir aux désirs du client : évaluer la charge de travail, établir un ca­len­drier, planifier la mise en œuvre.

Le dé­ve­lop­peur est par­fai­te­ment 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é­ve­lop­peurs con­for­mé­ment aux tech­niques de XP. Dans l’intérêt du projet, les dé­ve­lop­peurs ne doivent pas être surmenés. L’équipe de dé­ve­lop­peurs définit à cet effet elle-même son ca­len­drier.

Le rôle du manager consiste à faire le lien entre les dé­ve­lop­peurs 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 con­ven­tions générales d’une dis­cus­sion cons­truc­tives soient res­pec­tées. Le manager endosse donc si né­ces­saire 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 per­for­mance clés (p. ex. le temps que chaque col­la­bo­ra­teur consacre au projet).

Toute l’équipe (y compris le client) doit savoir gérer l’extreme pro­gram­ming et pouvoir mettre en pratique cette méthode de travail de manière cohérente. Un coach peut con­tri­buer à ce que tous se fassent une même idée des pro­cé­dures. Il n’a rien à voir avec le dé­ve­lop­pe­ment du produit à pro­pre­ment parler et ne sert que d’aide externe, de manière très similaire à un Scrum Master. Dans les dis­cus­sions préa­lables, les règles et les pratiques peuvent être passées en revue avec cette personne. Le coach ac­com­pagne l’équipe idéa­le­ment pendant toute la phase de dé­ve­lop­pe­ment, est dis­po­nible pour répondre aux questions et aide à clarifier des points obscurs.

Un pres­ta­taire de services externe endosse souvent ce rôle. Il est néanmoins également possible que le coach vienne de l’en­tre­prise, mais dans ce cas d’un autre secteur. Il faut éviter les doubles cas­quettes (un dé­ve­lop­peur prenant en plus le rôle de coach).

S’il a re­dy­na­misé le dé­ve­lop­pe­ment de logiciels, l’extreme pro­gram­ming 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 sa­tis­fac­tion du client : on cherche col­lec­ti­ve­ment avec lui la solution adaptée et il est associé à chaque étape. D’autre part, les dé­ve­lop­peurs peuvent mettre en œuvre des projets d’une façon qu’ils jugent ap­pro­priée plutôt que de devoir faire des compromis en per­ma­nence. Cependant, si le client vient voir l’équipe de dé­ve­lop­peurs avec une des­crip­tion finie du produit et une liste de fonctions, il sera alors très difficile d’employer XP.

Le pair pro­gram­ming notamment peut mettre de petites équipes dans l’embarras, car les capacités requises à cet effet ne sont pas dis­po­nibles. Les réunions ré­gu­lières avec les clients demandent également du temps qui ne peut pas être réintégré dans le travail de pro­gram­ma­tion à pro­pre­ment parler. Dans une situation idéale, cela n’a aucune im­por­tance : le résultat sera nettement meilleur si l’équipe peut prendre le temps né­ces­saire et disposer des res­sources sou­hai­tées.

Dans la pratique en revanche, un budget limité tout comme des délais de livraison clai­re­ment fixés mettent les dé­ve­lop­peurs 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 pro­gram­ming, une équipe peut fournir un résultat ex­cep­tion­nel avec cette méthode. Les tests per­ma­nents génèrent des systèmes stables et le processus itératif garantit en com­bi­nai­son avec l’approche mi­ni­ma­liste que seules des fonctions im­por­tantes pour le projet sont ef­fec­ti­ve­ment créées.