Worldlex Wiki Parmi les autres éléments de la programmation extrême, on retrouve la programmation en binôme ou les revues de code approfondies , les tests unitaires de l'ensemble du code, le développement différé des fonctionnalités jusqu'à ce qu'elles soient réellement nécessaires , une structure de gestion horizontale, la simplicité et la clarté du code, la prise en compte de l'évolution des besoins du client au fil du temps et de l'amélioration de la compréhension du problème, ainsi qu'une communication fréquente avec le client et entre les programmeurs. Cette méthodologie tire son nom de l'idée que les aspects bénéfiques des pratiques traditionnelles du génie logiciel sont poussés à l'extrême. Par exemple, les revues de code sont considérées comme une pratique bénéfique ; poussées à l'extrême, elles permettent une revue de code continue (c'est-à-dire la programmation en binôme).
Kent Beck a développé la programmation extrême (XP) lors de son travail sur le projet de paie du système de rémunération global de Chrysler (C3) . Beck est devenu chef de projet C3 en mars 1996. Il a alors commencé à perfectionner la méthodologie de développement utilisée et a écrit un ouvrage sur le sujet ( 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 racheté l'entreprise. Ward Cunningham a également exercé une influence majeure sur XP.De nombreuses pratiques de programmation extrême existent depuis un certain temps ; cette méthodologie pousse les « bonnes pratiques » à l’extrême. Par exemple, la pratique du développement axé sur les tests, consistant à planifier et à écrire les 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. Afin de raccourcir le temps de développement total, certains documents de test formels (comme ceux destinés aux tests d’acceptation ) ont été élaborés en parallèle (ou peu avant) de la préparation du logiciel pour les tests. Un groupe de test indépendant de la NASA peut rédiger les procédures de test, en se basant sur des exigences formelles et des limites logiques, avant même que les programmeurs n’écrivent le logiciel et ne l’intègrent au matériel. XP pousse ce concept à l’extrême, en rédigeant des tests automatisés (parfois au sein de modules logiciels) qui valident le fonctionnement de portions de code logiciel, même petites, au lieu de se limiter aux fonctionnalités principales.
Origines
Deux influences majeures ont façonné le développement logiciel 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 la bulle Internet ont mis l'accent sur la rapidité de mise sur le marché et la croissance des entreprises comme facteurs de compétitivité.
L’évolution rapide des exigences a imposé des cycles de vie des produits plus courts et s’est souvent heurtée aux méthodes traditionnelles de développement logiciel.
Le système de rémunération global de Chrysler (C3) a été lancé afin de déterminer la meilleure façon d'utiliser les technologies orientées objet, en prenant pour objet d'étude les systèmes de paie de Chrysler, avec Smalltalk comme langage et GemStone comme couche d'accès aux données . Chrysler a fait appel à Kent Beck , un expert reconnu de Smalltalk, pour optimiser les performances du système, mais son rôle s'est élargi lorsqu'il a constaté plusieurs problèmes dans le processus de développement. Il a saisi cette occasion pour proposer et mettre en œuvre des changements dans les pratiques de développement, en s'appuyant sur son travail avec son collaborateur régulier, 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 s'occuper de quelques tâches que je jugeais raisonnables, comme les tests et les relectures. La deuxième fois, l'enjeu était bien plus important. Je me suis dit : « Tant pis, au moins ça fera un bon article », et j'ai demandé à l'équipe de se concentrer à fond sur les points que je considérais essentiels et de laisser tomber le reste.
Beck a invité Ron Jeffries à rejoindre le projet pour contribuer au développement et au perfectionnement de ces méthodes. Jeffries a ensuite joué le rôle de coach afin d'ancrer ces pratiques comme des automatismes au sein de l'équipe C3.
Les principes et les pratiques de l'eXtreme Programming (XP) ont été largement diffusés grâce aux discussions sur le wiki original , WikiWikiWeb de Cunningham . Divers contributeurs ont approfondi et enrichi ces idées, donnant naissance à des méthodologies dérivées (voir le développement logiciel agile ). Par ailleurs, les concepts de l'XP ont été expliqués pendant plusieurs années à l'aide d'une carte hypertexte disponible sur le site web de l'XP à l'adresse http://www.extremeprogramming.org ( ISBN0-201-61641-6), diffusant ainsi ses idées à un public beaucoup plus large. Les auteurs de la série ont abordé différents aspects de la pratique de l'XP. La série comprenait un ouvrage critiquant ces pratiques.
Concept
Les tests d’intégration à l’échelle du système étaient initialement encouragés comme une activité quotidienne de fin de journée pour la détection précoce des interfaces incompatibles. Cependant, la fréquence de ces tests a été réduite à une fois par semaine, voire moins fréquemment, en fonction de la stabilité globale des interfaces du système.
Écoute
Les programmeurs doivent être à l'écoute des besoins des clients concernant le système et la logique métier requise. Ils doivent comprendre ces besoins suffisamment bien pour pouvoir fournir au client un retour d'information sur les aspects techniques de la résolution du problème, ainsi que sur sa faisabilité compte tenu des contraintes imposées. La communication entre le client et le programmeur est abordée plus en détail dans le jeu de planification .
Conception
D'un point de vue simpliste, on pourrait dire que le développement d'un système se résume à coder, tester et écouter. Si ces activités sont bien menées, le résultat devrait toujours être un système fonctionnel. En pratique, c'est rarement le cas. On peut aller loin sans conception, mais on finit toujours par se retrouver bloqué. Le système devient trop complexe et ses dépendances internes ne sont plus claires. On peut éviter cela en créant une structure de conception qui organise la logique du système. Une bonne conception permet d'éviter de nombreuses dépendances internes ; ainsi, modifier une partie du système n'affecte pas les autres. Vous n'en aurez pas besoin » (YAGNI). Les partisans de l'XP reconnaissent l'inconvénient que cela peut parfois impliquer plus d'efforts ultérieurement pour modifier le système ; ils affirment que cet inconvénient est largement compensé par l'avantage de ne pas investir dans d'éventuelles exigences futures qui pourraient évoluer avant de devenir pertinentes. Coder et concevoir pour des exigences futures incertaines implique le risque de dépenser des ressources pour quelque chose qui pourrait ne pas être nécessaire, tout en retardant potentiellement des fonctionnalités cruciales. En ce qui concerne la communication, la simplicité de conception et de codage devrait améliorer la qualité des échanges. Une conception simple, avec un code très simple, serait facilement compréhensible par la plupart des programmeurs de l'équipe.
Retour
Dans le domaine 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 reçoivent un retour d'information direct sur l'état du système après la mise en œuvre des modifications.
- Retour d'information du client : Les tests fonctionnels (ou tests d'acceptation ) sont rédigés conjointement par le client et les testeurs. Ils reçoivent ainsi un retour d'information concret sur l'état actuel de leur système. Cette revue est prévue toutes les deux ou trois semaines afin de faciliter le pilotage du développement par le client.
- Retour d'information de l'équipe : Lorsque les clients formulent de nouvelles exigences lors de la phase de planification, l'équipe fournit directement une estimation du temps nécessaire à leur mise en œuvre.
Le feedback est étroitement lié à la communication et à la simplicité. Les défauts du système sont facilement communiqués par la rédaction d'un test unitaire démontrant qu'un certain fragment de code dysfonctionne. Ce feedback direct du système indique aux programmeurs comment recoder cette partie. Un client peut tester le système périodiquement en fonction des exigences fonctionnelles, appelées user stories . Pour reprendre les mots de Kent Beck : « L'optimisme est un risque professionnel en programmation. Le feedback en est le remède. »
la refactorisation de leur code lorsque cela s'avère nécessaire. Cela implique de revoir le système existant et de le modifier afin de faciliter l'intégration de changements futurs. Un autre exemple de courage est de savoir quand jeter du code : le courage de supprimer le code source obsolète, quel que soit l'effort déployé pour le créer. Enfin, le courage se traduit par la persévérance : un programmeur peut être bloqué sur un problème complexe pendant une journée entière, puis le résoudre rapidement le lendemain, à condition de persévérer.
Respect
Le respect englobe le respect d'autrui ainsi que le respect de soi. Les programmeurs ne doivent jamais apporter de modifications qui empêchent la compilation, qui rendent les tests unitaires existants infructueux ou qui retardent le travail de leurs collègues. Les membres respectent leur propre travail en écrivant du code de haute qualité et en recherchant la meilleure conception possible pour la solution à mettre en œuvre grâce à la refactorisation.
L'adoption des quatre valeurs précédentes favorise le respect mutuel au sein de l'équipe. Personne ne devrait se sentir sous-estimé ou ignoré. Ceci garantit une forte motivation et encourage la loyauté envers l'équipe et l'objectif du projet. Cette valeur est liée aux autres et est orientée vers le travail d'équipe.
Règles
La première version des règles d'XP a été publiée en 1999 par Don Wells sur le site web d'XP. Elle comprend 29 règles réparties en cinq catégories : planification, gestion, conception, codage et tests. La planification, la gestion et la conception sont explicitement mentionnées afin de réfuter les affirmations selon lesquelles XP ne prendrait pas en charge ces activités.
Une autre version des règles XP a été proposée par Ken Auer lors de la conférence XP/Agile Universe 2003. Selon lui, XP se définit par ses règles, et non par ses pratiques (plus sujettes à variation et à ambiguïté). Il distingue deux catégories : les « Règles d’engagement », qui définissent 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 au jour le jour, dans le cadre des Règles d’engagement.
Voici quelques-unes des règles (liste incomplète) :
Codage
- Le client est toujours disponible
- Codez d'abord le test unitaire
- Une seule paire intègre du code à la fois.
- Laissez l'optimisation pour la fin.
- Pas d'heures supplémentaires
Essai
- Tout code doit comporter des tests unitaires
- Tout le code doit réussir 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 corrigé (un bug n'est pas une erreur de logique ; c'est un test qui n'a pas été écrit).
- Les tests d'acceptation sont effectués régulièrement et leurs résultats sont publiés.
Principes
Les principes qui constituent le fondement de l'eXtreme Programming (XP) reposent sur les valeurs que nous venons de décrire et visent à faciliter la prise de décisions dans un projet de développement système. Ces principes se veulent plus concrets que les valeurs et plus facilement applicables en situation réelle.
Retour
La programmation extrême considère que le feedback est d'autant plus utile qu'il est fréquent et rapide. Elle souligne l'importance d'un délai minimal entre une action et son retour d'information pour apprendre et apporter des modifications. Contrairement aux méthodes de développement système traditionnelles, le contact avec le client est plus fréquent. 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 ses besoins. Grâce à ce feedback régulier, une erreur de conception du développeur est rapidement détectée et corrigée, avant que celui-ci ne consacre trop de temps à son implémentation.
Les tests unitaires contribuent au principe de retour d'information rapide. Lors de l'écriture de code, l'exécution des tests unitaires fournit un retour d'information direct sur la façon dont le système réagit aux modifications apportées. Cela inclut l'exécution non seulement des tests unitaires qui testent le code du développeur, mais également de tous les tests unitaires appliqués à l'ensemble du logiciel, grâce à un processus automatisé pouvant être lancé par une simple commande. Ainsi, si les modifications du développeur entraînent une défaillance dans une autre partie du système que le développeur connaît peu ou pas du tout, la suite de tests unitaires automatisée révélera immédiatement cette 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 la supprimer ou de la modifier. Avec les pratiques de développement traditionnelles, l'absence d'une suite de tests unitaires automatisée et exhaustive signifiait qu'une telle modification de code, considérée comme inoffensive par le développeur, aurait été laissée en place, n'apparaissant que lors des tests d'intégration – ou pire, seulement en production ; et déterminer quelle modification de code avait causé le problème, parmi toutes les modifications apportées par tous les développeurs au cours des semaines, voire des mois, précédant les tests d'intégration, était une tâche extrêmement complexe.
En supposant la simplicité
Il s'agit de traiter chaque problème comme si sa solution était « extrêmement simple ». Les méthodes traditionnelles de développement système préconisent d'anticiper l'avenir et de programmer en vue de la réutilisation. La programmation extrême rejette ces idées.
Les partisans de la programmation extrême affirment que procéder à des changements importants d'un seul coup est inefficace. La programmation extrême privilégie les changements incrémentaux : par exemple, un système peut bénéficier de petites mises à jour toutes les trois semaines. En procédant par petites étapes successives, le client exerce un meilleur contrôle sur le processus de développement et sur le système en cours de développement.
Accepter le changement
Le principe d'acceptation du changement consiste à ne pas lutter contre les changements, mais à les accueillir. Par exemple, si lors d'une réunion itérative il apparaît que les exigences du client ont considérablement évolué, les programmeurs doivent en tenir compte et planifier les nouvelles exigences pour l'itération suivante.
Pratiques
processus continu
- Intégration continue
- Refactorisation ou amélioration de la conception
- Petites sorties
Compréhension partagée
bien-être des programmeurs
Aspects controversés
Les pratiques de la programmation extrême (XP) ont fait l'objet de nombreux débats. Les partisans de la programmation extrême affirment qu'en permettant au client sur site de demander des modifications de manière informelle, le processus gagne en flexibilité et permet de réduire les coûts liés aux procédures formelles. Les détracteurs de la XP estiment que cela peut engendrer des reprises coûteuses et un dépassement du périmètre du projet, au-delà des accords et des budgets initialement prévus.de conception globale initiale . La conception se fait principalement au fur et à mesure et de manière incrémentale, en partant de « la solution la plus simple possible » et en n'ajoutant de la complexité que lorsque des tests infructueux l'exigent. Les critiques qualifient cette approche de « débogage d'un système jusqu'à ce qu'il prenne forme » et craignent qu'elle n'entraîne un effort de reconception plus important que si l'on se contentait de repenser le système lorsque les exigences évoluent.
Les critiques ont relevé 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 global.
Évolutivité
Thoughtworks a revendiqué un succès raisonnable sur des projets XP distribués impliquant jusqu'à soixante personnes.Matt Stephens et Doug Rosenberg ont publié * Extreme Programming Refactored: The Case Against XP* , un ouvrage qui remettait en question la pertinence du processus XP et proposait des pistes d'amélioration. Cette publication a suscité un long débat dans la presse, sur les forums et les espaces de discussion en ligne. L'argument principal du livre est que les pratiques XP sont interdépendantes, mais que peu d'organisations sont disposées ou capables de les adopter toutes ; par conséquent, le processus dans son ensemble est voué à l'échec. L'ouvrage formule également d'autres critiques et établit un parallèle, de manière péjorative, entre le modèle de « propriété collective » d'XP et le socialisme.
Certains aspects d'XP ont évolué depuis la publication d' Extreme Programming Refactored ; notamment, XP accepte désormais des modifications des pratiques, pourvu que les objectifs requis soient 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'un affaiblissement du processus.
D'autres auteurs ont tenté de concilier XP avec les méthodologies plus anciennes afin de former une méthodologie unifiée. XP visait notamment à remplacer certaines de ces méthodologies, comme la méthode en cascade ; par exemple, Project Lifecycles: Waterfall , Rapid Application Development (RAD), etc. JPMorgan Chase & Co. a essayé de combiner XP avec les méthodes de programmation informatique du modèle d'intégration de la 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 n'étaient pas contradictoires.
Critique
L’engouement initial pour 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 .
En particulier, la programmation extrême a été examinée et critiquée par Matt Stephens et Doug Rosenberg dans leur ouvrage Extreme Programming Refactored .