Programmation extrême

La programmation extrême ( XP ) est une méthodologie de développement logiciel destinée à améliorer la qualité des logiciels et leur réactivité face aux exigences changeantes des clients. En tant que type de développement logiciel agile , des versions fréquentes dans des cycles de développement courts, destinés à améliorer la productivité et à introduire des points de contrôle à partir desquels de nouvelles exigences des clients peuvent être adoptées.

D'autres éléments de la programmation extrême incluent la programmation en binôme ou la réalisation d'une révision approfondie du code , les tests unitaires de tout le code, la non-programmation des fonctionnalités jusqu'à ce qu'elles soient réellement nécessaires , une structure de gestion plate, la simplicité et la clarté du code, l'attente de changements dans les exigences du client au fil du temps et lorsque le problème est mieux compris, et une communication fréquente avec le client et entre les programmeurs. La méthodologie tire son nom de l'idée que les éléments bénéfiques des pratiques traditionnelles d'ingénierie logicielle sont portés à des niveaux « extrêmes ». À titre d'exemple, les révisions de code sont considérées comme une pratique bénéfique ; poussées à l'extrême, le code peut être révisé en continu (c'est-à-dire la pratique de la programmation en binôme ).

Kent Beck a développé la programmation extrême au cours de son travail sur le projet de paie Chrysler Comprehensive Compensation System (C3) . Beck est devenu le chef du projet C3 en mars 1996. Il a commencé à affiner la méthodologie de développement utilisée dans le projet et a écrit un livre sur la méthodologie ( Extreme Programming Explained , publié en octobre 1999). Chrysler a annulé le projet C3 en février 2000, après sept ans, lorsque Daimler-Benz a acquis la société. Ward Cunningham a été une autre influence majeure sur XP.

De nombreuses pratiques de programmation extrême existent depuis un certain temps ; la méthodologie pousse les « meilleures pratiques » à des niveaux extrêmes. Par exemple, la « pratique du développement basé sur les tests, la planification et l'écriture des tests avant chaque micro-incrément » a été utilisée dès le projet Mercury de la NASA , au début des années 1960. Pour raccourcir le temps de développement total, certains documents de test formels (tels que les tests d'acceptation ) ont été développés parallèlement (ou peu avant) à la préparation du logiciel pour les tests. Un groupe de test indépendant de la NASA peut écrire les procédures de test, en fonction des exigences formelles et des limites logiques, avant que les programmeurs n'écrivent le logiciel et ne l'intègrent au matériel. XP pousse ce concept à l'extrême, en écrivant des tests automatisés (parfois à l'intérieur de modules logiciels) qui valident le fonctionnement même de petites sections de codage logiciel, plutôt que de tester uniquement les fonctionnalités les plus importantes.

Deux influences majeures ont façonné le développement de logiciels dans les années 1990 :

• En interne, la programmation orientée objet a remplacé la programmation procédurale comme paradigme de programmation privilégié par certains développeurs.
• Sur le plan externe, l’essor d’Internet et l’ essor des dot-com ont mis l’accent sur la rapidité de mise sur le marché et la croissance des entreprises en tant que facteurs commerciaux compétitifs.

L’évolution rapide des exigences exigeait des cycles de vie des produits plus courts et entrait souvent en conflit avec les méthodes traditionnelles de développement de logiciels.

Le Chrysler Comprehensive Compensation System (C3) a été lancé afin de déterminer la meilleure façon d'utiliser les technologies objet, en utilisant les systèmes de paie de Chrysler comme objet de recherche, avec Smalltalk comme langage et GemStone comme couche d'accès aux données . Chrysler a fait appel à Kent Beck , un éminent spécialiste de Smalltalk, pour optimiser les performances du système, mais son rôle s'est élargi lorsqu'il a constaté plusieurs problèmes avec le processus de développement. Il a profité de cette opportunité pour proposer et mettre en œuvre certains changements dans les pratiques de développement, en s'appuyant sur son travail avec son collaborateur fréquent, Ward Cunningham . Beck décrit la conception initiale des méthodes :

La première fois qu'on m'a demandé de diriger une équipe, je leur ai demandé de faire un peu de choses que je trouvais sensées, comme des tests et des critiques. La deuxième fois, les enjeux étaient bien plus importants. Je me suis dit : « Au moins, ça fera un bon article », [et] j'ai demandé à l'équipe de pousser tous les boutons à fond sur les choses que je considérais comme essentielles et de laisser de côté tout le reste.

Beck a invité Ron Jeffries à participer au projet pour l'aider à développer et à peaufiner ces méthodes. Jeffries a ensuite joué le rôle de coach pour inculquer ces pratiques sous forme d'habitudes au sein de l'équipe C3.

Des informations sur les principes et les pratiques qui sous-tendent XP ont été diffusées dans le monde entier par le biais de discussions sur le wiki original , le WikiWikiWeb de Cunningham . Divers contributeurs ont discuté et développé les idées, et certaines méthodologies dérivées en ont résulté (voir le développement logiciel agile ). De plus, les concepts XP ont été expliqués , pendant plusieurs années, à l'aide d'une carte système hypertexte sur le site Web XP à l'adresse http://www.extremeprogramming.org vers  1999 .

Beck a édité une série de livres sur XP, en commençant par son propre Extreme Programming Explained (1999, ISBN 0-201-61641-6 ), diffusant ses idées à un public beaucoup plus large. Les auteurs de la série ont passé en revue divers aspects liés à XP et à ses pratiques. La série comprenait un livre critique de ces pratiques.

XP a suscité un intérêt considérable parmi les communautés de logiciels à la fin des années 1990 et au début des années 2000, et a été adopté dans un certain nombre d’environnements radicalement différents de ses origines.

La grande discipline requise par les pratiques originales a souvent été abandonnée, ce qui a conduit à l'abandon ou à la réduction, voire à la non-réalisation, de certaines de ces pratiques, jugées trop rigides, sur certains sites. Par exemple, la pratique des tests d'intégration de fin de journée pour un projet particulier pourrait être remplacée par un calendrier de fin de semaine, ou simplement réduite à des tests à des dates convenues d'un commun accord. Un tel calendrier plus souple pourrait éviter que les gens se sentent obligés de générer des stubs artificiels juste pour réussir les tests de fin de journée. Un calendrier moins rigide permet, au contraire, le développement de fonctionnalités complexes sur une période de plusieurs jours.

Parallèlement, d’autres pratiques de développement agile ne sont pas restées immobiles et, en 2019, XP continue d’évoluer, en assimilant davantage de leçons tirées des expériences sur le terrain, pour utiliser d’autres pratiques. Dans la deuxième édition d’ Extreme Programming Explained (novembre 2004), cinq ans après la première édition, Beck a ajouté davantage de valeurs et de pratiques et a fait la distinction entre les pratiques primaires et corollaires.

Extreme Programming Explained décrit la programmation extrême comme une discipline de développement de logiciels qui organise les gens pour produire des logiciels de meilleure qualité de manière plus productive.

XP tente de réduire le coût des changements d'exigences en ayant plusieurs cycles de développement courts, plutôt qu'un seul long. Dans cette doctrine, les changements sont un aspect naturel, inévitable et souhaitable des projets de développement de logiciels, et doivent être planifiés, au lieu de tenter de définir un ensemble stable d'exigences.

La programmation extrême introduit également un certain nombre de valeurs, de principes et de pratiques de base en plus de la méthodologie agile.

XP décrit quatre activités de base qui sont réalisées dans le cadre du processus de développement logiciel : le codage, les tests, l'écoute et la conception. Chacune de ces activités est décrite ci-dessous.

Les partisans de XP soutiennent que le seul produit réellement important du processus de développement d'un système est le code, c'est-à-dire les instructions logicielles qu'un ordinateur peut interpréter. Sans code, il n'y a pas de produit fonctionnel.

Le codage peut être utilisé pour déterminer la solution la plus adaptée. Il peut également aider à communiquer des idées sur des problèmes de programmation. Un programmeur confronté à un problème de programmation complexe ou ayant du mal à expliquer la solution à ses collègues programmeurs peut le coder de manière simplifiée et utiliser le code pour démontrer ce qu'il veut dire. Selon les partisans de cette position, le code est toujours clair et concis et ne peut être interprété que d'une seule manière. D'autres programmeurs peuvent donner leur avis sur ce code en codant également leurs idées.

Les tests sont au cœur de la programmation extrême. L'approche de la programmation extrême est la suivante : si un petit test peut éliminer quelques défauts, beaucoup de tests peuvent éliminer beaucoup plus de défauts.

• Les tests unitaires déterminent si une fonctionnalité donnée fonctionne comme prévu. Les programmeurs écrivent autant de tests automatisés qu'ils peuvent imaginer qui pourraient « casser » le code ; si tous les tests s'exécutent avec succès, le codage est terminé. Chaque morceau de code écrit est testé avant de passer à la fonctionnalité suivante.
• Les tests d'acceptation vérifient que les exigences telles que comprises par les programmeurs satisfont aux exigences réelles du client.

Les tests d'intégration à l'échelle du système ont été encouragés, au départ, comme une activité quotidienne de fin de journée, pour détecter rapidement les interfaces incompatibles, afin de reconnecter les différentes sections avant qu'elles ne s'écartent largement de la fonctionnalité cohérente. Cependant, les tests d'intégration à l'échelle du système ont été réduits à une fréquence hebdomadaire, ou moins fréquente, en fonction de la stabilité des interfaces globales du système.

Les programmeurs doivent écouter ce que les clients attendent du système, quelle « logique métier » est nécessaire. Ils doivent comprendre ces besoins suffisamment bien pour donner au client un retour sur les aspects techniques de la résolution du problème, ou non. La communication entre le client et le programmeur est également abordée dans le cadre de la planification .

Du point de vue de la simplicité, on pourrait bien sûr dire que le développement d'un système ne nécessite pas plus que du codage, des tests et de l'écoute. Si ces activités sont bien réalisées, le résultat devrait toujours être un système qui fonctionne. En pratique, cela ne fonctionnera pas. On peut faire beaucoup de chemin sans concevoir, mais à un moment donné, on se retrouve coincé. Le système devient trop complexe et les dépendances au sein du système cessent d'être claires. On peut éviter cela en créant une structure de conception qui organise la logique du système. Une bonne conception évitera de nombreuses dépendances au sein d'un système ; cela signifie que la modification d'une partie du système n'affectera pas les autres parties du système.

La programmation extrême a initialement reconnu quatre valeurs en 1999 : la communication, la simplicité, le feedback et le courage. Une nouvelle valeur, le respect, a été ajoutée dans la deuxième édition d' Extreme Programming Explained . Ces cinq valeurs sont décrites ci-dessous.

La création de systèmes logiciels nécessite de communiquer les exigences du système aux développeurs du système. Dans les méthodologies formelles de développement de logiciels, cette tâche est accomplie par le biais de la documentation. Les techniques de programmation extrême peuvent être considérées comme des méthodes permettant de créer et de diffuser rapidement des connaissances institutionnelles parmi les membres d'une équipe de développement. L'objectif est de donner à tous les développeurs une vision partagée du système qui correspond à la vision des utilisateurs du système. À cette fin, la programmation extrême privilégie les conceptions simples, les métaphores communes, la collaboration des utilisateurs et des programmeurs, la communication verbale fréquente et le feedback.

La programmation extrême encourage à commencer par la solution la plus simple. Des fonctionnalités supplémentaires peuvent ensuite être ajoutées plus tard. La différence entre cette approche et les méthodes de développement de systèmes plus conventionnelles est l'accent mis sur la conception et le codage pour les besoins d'aujourd'hui plutôt que pour ceux de demain, de la semaine prochaine ou du mois prochain. On résume parfois cela comme l'approche « Vous n'en aurez pas besoin » (YAGNI). Les partisans de XP reconnaissent l'inconvénient que cela peut parfois impliquer plus d'efforts demain pour changer le système ; ils prétendent que cela est plus que compensé par l'avantage de ne pas investir dans d'éventuelles exigences futures qui pourraient changer avant qu'elles ne deviennent pertinentes. Coder et concevoir pour des exigences futures incertaines implique le risque de dépenser des ressources sur quelque chose qui pourrait ne pas être nécessaire, tout en retardant peut-être des fonctionnalités cruciales. En ce qui concerne la valeur de « communication », la simplicité de conception et de codage devrait améliorer la qualité de la communication. Une conception simple avec un code très simple pourrait être facilement comprise par la plupart des programmeurs de l'équipe.

Dans le cadre de la programmation extrême, le feedback concerne différentes dimensions du développement du système :

• Retour d'information du système : en écrivant des tests unitaires , ou en exécutant des tests d'intégration périodiques, les programmeurs ont un retour d'information direct sur l'état du système après la mise en œuvre des modifications.
• Feedback du client : Les tests fonctionnels (aussi appelés tests d'acceptation ) sont rédigés par le client et les testeurs. Ils recevront un retour concret sur l'état actuel de leur système. Cette revue est planifiée une fois toutes les deux ou trois semaines afin que le client puisse facilement piloter le développement.
• Commentaires de l'équipe : Lorsque les clients émettent de nouvelles exigences dans le cadre de la planification, l'équipe donne directement une estimation du temps qu'il faudra pour les mettre en œuvre.

Le feedback est étroitement lié à la communication et à la simplicité. Les défauts du système sont facilement communiqués en écrivant un test unitaire qui prouve qu'un certain morceau de code va échouer. Le feedback direct du système indique aux programmeurs de recoder cette partie. Un client est en mesure de tester le système périodiquement en fonction des exigences fonctionnelles, appelées user stories . Pour citer Kent Beck , « ​​l'optimisme est un risque professionnel de la programmation. Le feedback est le traitement. »

Plusieurs pratiques incarnent le courage. L’une d’entre elles est le commandement de toujours concevoir et coder pour aujourd’hui et non pour demain. Il s’agit d’éviter de s’enliser dans la conception et de devoir déployer beaucoup d’efforts pour mettre en œuvre quoi que ce soit d’autre. Le courage permet aux développeurs de se sentir à l’aise pour refactoriser leur code lorsque cela est nécessaire. Cela signifie revoir le système existant et le modifier afin que les changements futurs puissent être mis en œuvre plus facilement. Un autre exemple de courage est de savoir quand jeter du code : le courage de supprimer le code source obsolète, peu importe les efforts déployés pour le créer. Le courage signifie également la persévérance : un programmeur peut être bloqué sur un problème complexe pendant une journée entière, puis résoudre le problème rapidement le lendemain, mais seulement s’il est persévérant.

La valeur du respect inclut le respect des autres ainsi que le respect de soi-même. Les programmeurs ne doivent jamais effectuer de modifications qui interrompent la compilation, qui font échouer les tests unitaires existants ou qui retardent le travail de leurs pairs. Les membres respectent leur propre travail en s'efforçant toujours d'obtenir une qualité élevée et en recherchant la meilleure conception pour la solution à portée de main grâce au refactoring.

L'adoption des quatre valeurs précédentes permet de gagner le respect des autres membres de l'équipe. Personne dans l'équipe ne doit se sentir sous-estimé ou ignoré. Cela garantit un niveau élevé de motivation et encourage la loyauté envers l'équipe et envers l'objectif du projet. Cette valeur dépend des autres valeurs et est orientée vers le travail d'équipe.

La première version des règles pour XP a été publiée en 1999 par Don Wells sur le site Web XP. 29 règles sont données dans les catégories de planification, de gestion, de conception, de codage et de test. La planification, la gestion et la conception sont mentionnées explicitement pour contrer les affirmations selon lesquelles XP ne prend pas en charge ces activités.

Une autre version des règles XP a été proposée par Ken Auer dans XP/Agile Universe 2003. Il pensait que XP était défini par ses règles, et non par ses pratiques (qui sont sujettes à plus de variations et d'ambiguïté). Il a défini deux catégories : les « règles d'engagement » qui dictent l'environnement dans lequel le développement logiciel peut se dérouler efficacement, et les « règles de jeu » qui définissent les activités et les règles minute par minute dans le cadre des règles d'engagement.

Voici quelques règles (incomplètes) :

Codage

• Le client est toujours disponible
• Commencez par coder le test unitaire
• Une seule paire intègre le code à la fois
• Laissez l’optimisation pour la fin
• Pas d'heures supplémentaires

Essai

• Tout le code doit avoir des tests unitaires
• Tout le code doit passer tous les tests unitaires avant de pouvoir être publié.
• Lorsqu'un bug est détecté, des tests sont créés avant que le bug ne soit traité (un bug n'est pas une erreur de logique ; c'est un test qui n'a pas été écrit)
• Des tests d'acceptation sont exécutés fréquemment et les résultats sont publiés

Les principes qui constituent la base de XP reposent sur les valeurs qui viennent d'être décrites et visent à favoriser la prise de décisions dans un projet de développement de système. Les principes sont censés être plus concrets que les valeurs et plus facilement transposables en orientations dans une situation pratique.

La programmation extrême considère que le feedback est plus utile s'il est effectué fréquemment et rapidement. Elle souligne qu'un délai minimal entre une action et son feedback est essentiel pour apprendre et apporter des modifications. Contrairement aux méthodes traditionnelles de développement de systèmes, le contact avec le client se fait par itérations plus fréquentes. Le client a une vision claire du système en cours de développement et peut donner son avis et orienter le développement selon les besoins. Grâce à un feedback fréquent du client, une décision de conception erronée prise par le développeur sera remarquée et corrigée rapidement, avant que le développeur ne passe beaucoup de temps à la mettre en œuvre.

Les tests unitaires contribuent au principe de rétroaction rapide. Lors de l'écriture de code, l'exécution du test unitaire fournit un retour d'information direct sur la façon dont le système réagit aux modifications apportées. Cela comprend l'exécution non seulement des tests unitaires qui testent le code du développeur, mais également l'exécution de tous les tests unitaires sur l'ensemble du logiciel, à l'aide d'un processus automatisé qui peut être lancé par une seule commande. De cette façon, si les modifications apportées par le développeur provoquent une défaillance dans une autre partie du système dont le développeur ne connaît que peu ou pas du tout l'existence, la suite automatisée de tests unitaires révélera immédiatement la défaillance, alertant le développeur de l'incompatibilité de sa modification avec d'autres parties du système et de la nécessité de supprimer ou de modifier sa modification. Dans les pratiques de développement traditionnelles, l'absence d'une suite de tests unitaires automatisée et complète signifiait qu'une telle modification de code, considérée comme inoffensive par le développeur, aurait été laissée en place, apparaissant uniquement pendant les tests d'intégration - ou pire, uniquement en production ; et déterminer quelle modification de code a causé le problème, parmi toutes les modifications apportées par tous les développeurs au cours des semaines ou même des mois précédant les tests d'intégration, était une tâche redoutable.

Il s'agit de traiter chaque problème comme si sa solution était « extrêmement simple ». Les méthodes traditionnelles de développement de systèmes préconisent de planifier l'avenir et de coder pour la réutilisabilité. La programmation extrême rejette ces idées.

Les partisans de la programmation extrême affirment que faire de gros changements en une seule fois ne fonctionne pas. La programmation extrême applique des changements incrémentiels : par exemple, un système peut avoir de petites versions toutes les trois semaines. Lorsque de nombreuses petites étapes sont réalisées, le client a plus de contrôle sur le processus de développement et sur le système en cours de développement.

Le principe d'acceptation du changement consiste à ne pas s'opposer aux changements mais à les accepter. Par exemple, si lors d'une des réunions itératives, il apparaît que les exigences du client ont radicalement changé, les programmeurs doivent accepter ce changement et planifier les nouvelles exigences pour l'itération suivante.

La programmation extrême a été décrite comme comportant 12 pratiques, regroupées en quatre domaines :

• Programmation en binôme
• Jeu de planification
• Développement piloté par les tests
• Toute l'équipe

• Intégration continue
• Refactoring ou amélioration de la conception
• Petites sorties

• Normes de codage
• Propriété collective du code
• Conception simple
• Métaphore du système

• Rythme soutenable

Les pratiques de XP ont fait l'objet de nombreux débats. Les partisans de la programmation extrême affirment qu'en laissant le client sur site demander des modifications de manière informelle, le processus devient flexible et permet d'économiser le coût des frais généraux formels. Les critiques de XP affirment que cela peut conduire à des retouches coûteuses et à un dépassement de la portée du projet au-delà de ce qui avait été convenu ou financé auparavant.

Les tableaux de contrôle des modifications sont un signe qu'il existe des conflits potentiels dans les objectifs et les contraintes du projet entre plusieurs utilisateurs. Les méthodes accélérées de XP dépendent quelque peu de la capacité des programmeurs à adopter un point de vue client unifié afin que le programmeur puisse se concentrer sur le codage, plutôt que sur la documentation des objectifs et des contraintes de compromis. Cela s'applique également lorsque plusieurs organisations de programmation sont impliquées, en particulier les organisations qui se disputent des parts de projets.

D’autres aspects potentiellement controversés de la programmation extrême incluent :

• Les exigences sont exprimées sous forme de tests d’acceptation automatisés plutôt que de documents de spécifications.
• Les exigences sont définies de manière incrémentielle, plutôt que d’essayer de les obtenir toutes à l’avance.
• Les développeurs de logiciels doivent généralement travailler en binôme.
• Il n'y a pas de grande conception en amont . La plupart des activités de conception se déroulent à la volée et de manière incrémentale, en commençant par « la chose la plus simple qui pourrait fonctionner » et en ajoutant de la complexité uniquement lorsque cela est requis par des tests en échec. Les critiques qualifient cela de « débogage d'un système en apparence » et craignent que cela n'entraîne plus d'efforts de reconception que de simplement repenser la conception lorsque les exigences changent.
• Un représentant du client est rattaché au projet. Ce rôle peut devenir un point de défaillance unique pour le projet, et certaines personnes ont constaté qu'il s'agissait d'une source de stress. En outre, il existe un risque de micro-gestion par un représentant non technique essayant de dicter l'utilisation des fonctionnalités et de l'architecture du logiciel technique.

Les critiques ont noté plusieurs inconvénients potentiels, notamment des problèmes liés à des exigences instables, l’absence de compromis documentés sur les conflits entre utilisateurs et l’absence d’une spécification ou d’un document de conception globale.

Thoughtworks a revendiqué un succès raisonnable sur des projets XP distribués impliquant jusqu'à soixante personnes.

En 2004, la programmation extrême industrielle (IXP) a été introduite comme une évolution de XP. Elle vise à apporter la capacité de travailler dans des équipes de grande taille et distribuées. Elle compte désormais 23 pratiques et des valeurs flexibles.

En 2003, Matt Stephens et Doug Rosenberg ont publié Extreme Programming Refactored: The Case Against XP , qui remettait en question la valeur du processus XP et suggérait des moyens de l'améliorer. Cela a déclenché un long débat dans les articles, les groupes de discussion sur Internet et les zones de discussion sur les sites Web. L'argument principal du livre est que les pratiques de XP sont interdépendantes, mais que peu d'organisations pratiques sont désireuses/capables d'adopter toutes les pratiques ; par conséquent, l'ensemble du processus échoue. Le livre formule également d'autres critiques, et il établit une similitude négative entre le modèle de « propriété collective » de XP et le socialisme.

Certains aspects de XP ont changé depuis la publication d' Extreme Programming Refactored ; en particulier, XP s'adapte désormais aux modifications des pratiques tant que les objectifs requis sont toujours atteints. XP utilise également des termes de plus en plus génériques pour les processus. Certains estiment que ces changements invalident les critiques précédentes ; d'autres affirment qu'il s'agit simplement d'une dilution du processus.

D'autres auteurs ont essayé de réconcilier XP avec les méthodologies plus anciennes afin de former une méthodologie unifiée. Certaines de ces méthodologies ont cherché à être remplacées par XP, comme la méthodologie en cascade ; exemple : Project Lifecycles: Waterfall, Rapid Application Development (RAD) et All That. JPMorgan Chase & Co. a essayé de combiner XP avec les méthodes de programmation informatique de l'intégration du modèle de maturité des capacités (CMMI) et de Six Sigma . Ils ont constaté que les trois systèmes se renforçaient mutuellement, conduisant à un meilleur développement, et ne se contredisaient pas mutuellement.

Le buzz initial de la programmation extrême et ses principes controversés, tels que la programmation en binôme et la conception continue , ont suscité des critiques particulières, notamment celles de McBreen, Boehm et Turner, Matt Stephens et Doug Rosenberg. Cependant, de nombreuses critiques sont considérées par les praticiens Agile comme des malentendus sur le développement agile.

En particulier, la programmation extrême a été examinée et critiquée par Matt Stephens et Doug Rosenberg dans leur livre Extreme Programming Refactored .