Programmation extrême - Extreme programming

Planification et boucles de rétroaction en programmation extrême
Développement de logiciels
Activités principales
Paradigmes et modèles
Méthodologies et cadres
Disciplines de soutien
Les pratiques
Outils
Normes et corpus de connaissances
Glossaires
Grandes lignes

La programmation extrême ( XP ) est une méthodologie de développement logiciel qui vise à améliorer la qualité du logiciel et la réactivité aux besoins changeants des clients. En tant que type de développement logiciel agile , il préconise des « versions » fréquentes dans des cycles de développement courts, qui visent à améliorer la productivité et à introduire des points de contrôle auxquels les nouvelles exigences des clients peuvent être adoptées.

D'autres éléments de la programmation extrême comprennent : la programmation par paires ou la révision approfondie du code , les tests unitaires de tout le code, ne pas programmer les fonctionnalités jusqu'à ce qu'elles soient réellement nécessaires , une structure de gestion plate, la simplicité et la clarté du code, s'attendre à des changements dans les exigences du client au fil du temps et 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 de génie logiciel sont portés à des niveaux « extrêmes ». Par exemple, les revues de code sont considérées comme une pratique bénéfique ; poussé à l'extrême, le code peut être revu en continu (c'est-à-dire la pratique de la programmation en binôme ).

Histoire

Kent Beck a développé une programmation extrême au cours de son travail sur le projet de paie Chrysler Comprehensive Compensation System (C3) . Beck est devenu le chef de 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 était 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, de la planification et de la rédaction 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 (comme pour les tests d'acceptation ) ont été développés en parallèle (ou peu de temps avant) que le logiciel soit prêt pour les tests. Un groupe de test indépendant de la NASA peut rédiger les procédures de test, sur la base d'exigences formelles et de limites logiques, avant que les programmeurs n'écrivent le logiciel et l'intègrent au matériel. XP pousse ce concept à un niveau 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.

Origines

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

L'évolution rapide des exigences exigeait des cycles de vie des produits plus courts et se heurtait souvent aux 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 praticien Smalltalk, pour régler les performances du système, mais son rôle s'est élargi car il a noté plusieurs problèmes avec le processus de développement. Il a saisi cette opportunité pour proposer et mettre en œuvre quelques changements dans les pratiques de développement - sur la base de 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 des choses que je pensais être sensées, comme des tests et des critiques. La deuxième fois, il y avait beaucoup plus en jeu. J'ai pensé : « Au diable les torpilles, au moins ça fera un bon article », [et] j'ai demandé à l'équipe de monter tous les boutons à 10 sur les choses que je pensais être essentielles et de laisser de côté tout le reste.

Beck a invité Ron Jeffries au projet pour aider à développer et affiner ces méthodes. Jeffries a ensuite agi en tant qu'entraîneur pour inculquer les pratiques en tant qu'habitudes dans l'équipe C3.

Informations sur les principes et les pratiques derrière XP diffusées dans le monde entier à travers des 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 développement de logiciels agiles ). De plus, les concepts de XP ont été expliqués, depuis plusieurs années, à l'aide d'une carte du système hypertexte sur le site Web de XP à 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 sont passés en revue divers aspects liés à XP et à ses pratiques. La série comprenait un livre critique des pratiques.

État actuel

XP a suscité un vif intérêt 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 haute discipline exigée par les pratiques d'origine a souvent été abandonnée, provoquant la dépréciation ou la réduction, voire la non-achèvement de certaines de ces pratiques, telles que celles jugées trop rigides, sur des sites individuels. Par exemple, la pratique des tests d'intégration de fin de journée pour un projet particulier pourrait être changée en un calendrier de fin de semaine, ou simplement réduite à des tests à des dates convenues d'un commun accord. Un horaire aussi détendu pourrait éviter que les gens se sentent pressés de générer des talons artificiels juste pour réussir les tests de fin de journée. Un planning moins rigide permet, au contraire, le développement de fonctionnalités complexes sur une période de plusieurs jours.

Pendant ce temps, d'autres pratiques de développement agile ne sont pas restées immobiles et, à partir de 2019, XP continue d'évoluer, assimilant davantage de leçons d'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é plus de valeurs et de pratiques et a différencié les pratiques primaires et corollaires.

Concept

Buts

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 long. Dans cette doctrine, les changements sont un aspect naturel, incontournable et souhaitable des projets de développement logiciel, et devraient ê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 du cadre de programmation agile.

Activités

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

Codage

Les partisans de XP soutiennent que le seul produit vraiment important du processus de développement du système est le code – des instructions logicielles qu'un ordinateur peut interpréter. Sans code, il n'y a pas de produit fonctionnel.

Le codage peut être utilisé pour trouver la solution la plus appropriée. Le codage peut également aider à communiquer des réflexions sur les problèmes de programmation. Un programmeur traitant un problème de programmation complexe, ou ayant du mal à expliquer la solution à d'autres programmeurs, peut le coder de manière simplifiée et utiliser le code pour démontrer ce qu'il signifie. Le code, disent les partisans de cette position, est toujours clair et concis et ne peut être interprété de plusieurs manières. D'autres programmeurs peuvent donner leur avis sur ce code en codant également leurs pensées.

Essai

Article principal : Développement piloté par les tests

Les tests sont au cœur de la programmation extrême. L'approche de la programmation extrême est que 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 qu'elles sont 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, en tant qu'activité quotidienne de fin de journée, pour la détection précoce des interfaces incompatibles, pour se reconnecter avant que les sections distinctes ne s'écartent largement d'une fonctionnalité cohérente. Cependant, les tests d'intégration à l'échelle du système ont été réduits à hebdomadaires ou moins souvent, en fonction de la stabilité des interfaces globales du système.

Écoute

Les programmeurs doivent écouter ce que les clients ont besoin du système pour faire, quelle « logique métier » est nécessaire. Ils doivent suffisamment bien comprendre ces besoins pour donner au client des commentaires sur les aspects techniques de la façon dont le problème peut être résolu ou ne peut pas être résolu. La communication entre le client et le programmeur est également abordée dans le jeu de planification .

Conception

Du point de vue de la simplicité, on pourrait bien sûr dire que le développement du système n'a besoin que de codage, de test et d'écoute. Si ces activités sont bien exécuté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 va rester bloqué. 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 dans le 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.

Valeurs

La programmation extrême a initialement reconnu quatre valeurs en 1999 : la communication, la simplicité, la rétroaction 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 communication

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êmes peuvent être considérées comme des méthodes permettant de construire 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 vue partagée du système qui correspond à la vue détenue par les utilisateurs du système. À cette fin, la programmation extrême favorise des conceptions simples, des métaphores communes, la collaboration des utilisateurs et des programmeurs, une communication verbale fréquente et des commentaires.

Simplicité

La programmation extrême encourage à commencer par la solution la plus simple. Des fonctionnalités supplémentaires peuvent ensuite être ajoutées ultérieurement. La différence entre cette approche et les méthodes de développement de système plus conventionnelles est l'accent mis sur la conception et le codage pour les besoins d'aujourd'hui plutôt que ceux de demain, de la semaine prochaine ou du mois prochain. Ceci est parfois résumé 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 ; leur affirmation est 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. Le codage et la conception pour des besoins futurs incertains impliquent 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. Liée à la valeur « 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.

Retour d'information

Au sein de la programmation extrême, le retour d'expérience concerne différentes dimensions du développement du système :

  • Retour du système : en écrivant des tests unitaires ou en exécutant des tests d'intégration périodiques, les programmeurs ont un retour direct sur l'état du système après la mise en œuvre des changements.
  • Retour du client : Les tests fonctionnels (aka tests d'acceptation ) sont écrits par le client et les testeurs. Ils obtiendront des retours concrets sur l'état actuel de leur système. Cette revue est prévue une fois toutes les deux ou trois semaines afin que le client puisse facilement piloter le développement.
  • Retour de l'équipe : lorsque les clients présentent de nouvelles exigences dans le jeu de planification, l'équipe donne directement une estimation du temps qu'il faudra pour la mettre en œuvre.

La rétroaction est étroitement liée à la communication et à la simplicité. Les failles du système sont facilement communiquées en écrivant un test unitaire qui prouve qu'un certain morceau de code se brisera. Le retour 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. La rétroaction est le traitement."

Courage

Plusieurs pratiques incarnent le courage. L'un est le commandement de toujours concevoir et coder pour aujourd'hui et non pour demain. Il s'agit d'un effort pour éviter de s'enliser dans la conception et de nécessiter beaucoup d'efforts pour mettre en œuvre quoi que ce soit d'autre. Courage permet aux développeurs de se sentir à l'aise avec la refactorisation de leur code si 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 le code : le courage de supprimer le code source qui est obsolète, peu importe les efforts déployés pour créer ce code source. De plus, le courage signifie 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 persiste.

Le respect

La valeur du respect comprend le respect des autres ainsi que le respect de soi. Les programmeurs ne devraient jamais valider des modifications qui interrompent la compilation, qui font échouer les tests unitaires existants ou qui retardent autrement le travail de leurs pairs. Les membres respectent leur propre travail en recherchant toujours une haute qualité 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 conduit au respect des autres dans l'équipe. Personne dans l'équipe ne doit se sentir incompris ou ignoré. Cela garantit un haut niveau 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.

Règles

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

Une autre version des règles de XP a été proposée par Ken Auer dans XP/Agile Universe 2003. Il a estimé que XP était défini par ses règles, et non par ses pratiques (qui sont sujettes à plus de variations et d'ambiguïtés). Il a défini deux catégories : les « Règles d'engagement » qui dictent l'environnement dans lequel le développement de logiciels peut avoir lieu 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

Essai

  • Tout le code doit avoir des tests unitaires
  • Tout le code doit réussir tous les tests unitaires avant de pouvoir être publié.
  • Lorsqu'un bogue est trouvé, des tests sont créés avant que le bogue ne soit corrigé (un bogue n'est pas une erreur de logique ; c'est un test qui n'a pas été écrit)
  • Des tests d'acceptation sont souvent effectués et les résultats sont publiés

Des principes

Les principes qui forment la base de XP sont basés sur les valeurs qui viennent d'être décrites et sont destinés à favoriser les 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 traduits en conseils dans une situation pratique.

Retour d'information

La programmation extrême considère les commentaires comme des plus utiles s'ils sont effectués fréquemment et rapidement. Il souligne qu'un délai minimal entre une action et son retour d'information est essentiel pour apprendre et apporter des changements. 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 ses besoins. Avec des retours fréquents 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 retour rapide. Lors de l'écriture du code, l'exécution du test unitaire fournit un retour 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 tous les logiciels, à l'aide d'un processus automatisé qui peut être lancé par une seule commande. De cette façon, si les modifications du développeur provoquent une défaillance dans une autre partie du système dont le développeur connaît peu ou rien, la suite automatisée de tests complets 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 la nécessité de supprimer ou de modifier leur changement. Dans les pratiques de développement traditionnelles, l'absence d'une suite de tests unitaires automatisée et complète signifiait qu'un tel changement de code, supposé inoffensif par le développeur, aurait été laissé en place, n'apparaissant que pendant les tests d'intégration - ou pire, uniquement en production ; et déterminer quel changement de code a causé le problème, parmi tous les changements apportés par tous les développeurs au cours des semaines voire des mois précédant les tests d'intégration, était une tâche formidable.

Assumer 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 de systèmes disent de planifier pour l'avenir et de coder pour la réutilisabilité. La programmation extrême rejette ces idées.

Les partisans de la programmation extrême disent que faire de grands changements d'un seul coup 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 effectuées, le client a plus de contrôle sur le processus de développement et le système en cours de développement.

Accepter le changement

Le principe d'embrasser le changement consiste à ne pas travailler contre les changements mais à les adopter. 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 adopter cela et planifier les nouvelles exigences pour la prochaine itération.

Les pratiques

Informations complémentaires : pratiques de programmation extrêmes

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

Rétroaction à petite échelle

Processus continu

Compréhension partagée

Programmeur bien-être

Aspects controversés

Les pratiques dans XP ont été fortement débattues. Les partisans de la programmation extrême affirment qu'en modifiant de manière informelle la demande du client sur site, 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 entraîner des retouches coûteuses et un dépassement de la portée du projet au-delà de ce qui avait été précédemment convenu ou financé.

Les tableaux de contrôle des changements sont un signe qu'il existe des conflits potentiels dans les objectifs du projet et des contraintes entre plusieurs utilisateurs. Les méthodes accélérées de XP dépendent quelque peu de la capacité des programmeurs à assumer 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 des organisations qui se disputent des parts de projets.

D'autres aspects potentiellement controversés de la programmation extrême comprennent :

  • Les exigences sont exprimées sous forme de tests d'acceptation automatisés plutôt que de documents de spécification.
  • Les exigences sont définies progressivement, plutôt que d'essayer de toutes les obtenir à l'avance.
  • Les développeurs de logiciels doivent généralement travailler en binôme.
  • Il n'y a pas de Big Design Up Front . La plupart des activités de conception se déroulent à la volée et progressivement, en commençant par"la chose la plus simple qui puisse fonctionner" et en ajoutant de la complexité uniquement lorsque cela est requis par des tests ratés. Les critiques comparent cela au " débogage d' un système en apparence" et craignent que cela n'entraîne plus d'efforts de re-conception que de re-conception uniquement lorsque les exigences changent.
  • Un chargé de clientèle est attaché au projet. Ce rôle peut devenir un point d'échec unique pour le projet, et certaines personnes ont trouvé 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 techniques du logiciel.

Les critiques ont noté plusieurs inconvénients potentiels, notamment des problèmes d'exigences instables, aucun compromis documenté de conflits d'utilisateurs et un manque de spécification ou de document de conception globale.

Évolutivité

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

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

Divisibilité et réponses

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 Internet et les zones de discussion sur les sites Web. L'argument central du livre est que les pratiques de XP sont interdépendantes mais que peu d'organisations pratiques sont disposées/capables d'adopter toutes les pratiques ; donc tout le processus échoue. Le livre fait également d'autres critiques, et il fait 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 soutiennent que ces changements invalident les critiques précédentes ; d'autres prétendent que cela ne fait que diluer le processus.

D'autres auteurs ont tenté de réconcilier XP avec les anciennes méthodologies afin de former une méthodologie unifiée. Certains de ces XP ont cherché à se substituer, comme la méthodologie en cascade ; exemple : cycles de vie du projet : cascade, développement rapide d'applications (RAD) et tout cela. 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 Six Sigma . Ils ont constaté que les trois systèmes se renforçaient bien, conduisant à un meilleur développement, et ne se contredisaient pas.

Critique

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

En particulier, la programmation extrême a été revue et critiquée par Extreme Programming Refactored de Matt Stephens et Doug Rosenberg .

Voir également

Les références

Lectures complémentaires

  • Ken Auer et Roy Miller. Programmation extrême appliquée : jouer pour gagner , Addison–Wesley.
  • Ken Auer ; Ron Jeffries ; Jeff Canna ; Glen B. Alleman; Lisa Crispin ; Janet Grégoire (2002). « Les testeurs sont-ils éteints ? Comment les testeurs peuvent-ils contribuer aux équipes XP ? ». Programmation extrême et méthodes agiles — XP/Agile Universe 2002 . Notes de cours en informatique. 2418 . Springer-Verlag. p. 287. doi : 10.1007/3-540-45672-4_50 . ISBN 978-3-540-44024-6.
  • Kent Beck : Explication de la programmation extrême : embrasser le changement , Addison–Wesley.
  • Kent Beck et Martin Fowler : Planning Extreme Programming , Addison–Wesley.
  • Kent Beck et Cynthia Andres. Extreme Programming Explained : Embrace Change, deuxième édition , Addison–Wesley.
  • Alistair Cockburn : Développement logiciel agile , Addison–Wesley.
  • Martin Fowler : Refactoring : Améliorer la conception du code existant , Addison–Wesley.
  • Harvey Herela (2005). Étude de cas : Le système de rémunération global Chrysler . Galen Lab, UC Irvine.
  • Jim Highsmith . Écosystèmes de développement logiciel agiles , Addison–Wesley.
  • Ron Jeffries , Ann Anderson et Chet Hendrickson (2000), Extreme Programming Installed , Addison–Wesley.
  • Craig Larman & V. Basili (2003). "Développement itératif et incrémentiel: Une brève histoire", Ordinateur (IEEE Computer Society) 36 (6): 47-56.
  • Matt Stephens et Doug Rosenberg (2003). Extreme Programming refactorisé : le cas contre XP , Apress.
  • Waldner, JB. (2008). "Nano-ordinateurs et Swarm Intelligence". Dans : ISTE, 225-256.

Liens externes