Concept: Pratiques Agile et RUP
Ces instructions expliquent comment appliquer certaines des "meilleures pratiques" de la communauté Agile aux projets utilisant RUP et voulant bénéficier de certaines de ces pratiques.
Relations
Description principale

Rubriques

Introduction

Le processus Rational Unified Process (RUP) est une infrastructure préfabriquée de processus que le Rational Software a amélioré au fil des ans et qui a été largement utilisée pour tous les types de projets logiciels, des plus petits aux plus grands. Un nombre croissant de processus dits "agiles" (comme les méthodes eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) et Crystal Clear) ont récemment été reconnus comme des méthodes efficaces pour concevoir des systèmes plus petits. (Pour plus d'informations sur le groupe Agile Alliance, voir www.agilealliance.org.)

Les sections suivantes fournissent une aide aux équipes projet dans l'évaluation des pratiques "agiles" identifiées dans ces méthodes, afin de voir comment elles sont traitées par le processus de développement logiciel le plus complet défini par RUP (pour plus d'informations sur RUP, voir Introduction à RUP).

Présentation

La communauté agile a synthétisé un certain nombre de "meilleures pratiques" qui s'appliquent particulièrement bien aux petites équipes de projet travaillant dans un même site. Bien que le processus RUP soit conçu pour des équipes de toute taille, il peut s'appliquer avec succès à de petits projets. En général, RUP et les processus de la communauté Agile ont une même conception des meilleures pratiques clés requises pour développer un logiciel de qualité - appliquant, par exemple, un développement itératif et mettant l'accent sur les utilisateurs.

Les sections suivantes expliquent comment appliquer certaines des "meilleures pratiques" identifiées dans la communauté agiles aux projets utilisant RUP et voulant bénéficier de certaines de ces pratiques. Dans ce cas, l'accent est particulièrement mis sur les pratiques de la méthodologie eXtreme Programming (XP). (Pour plus d'informations sur XP, voir le site web : http://www.extremeprogramming.org.)

Pratiques XP

XP présente quatre "activités" de base (coder, tester, écouter et concevoir) qui, en fait, correspondent davantage aux disciplines de RUP. Ces activités XP sont réalisées à l'aide d'un ensemble de pratiques nécessitant la réalisation d'activités supplémentaires, qui sont mappées à d'autres disciplines dans le processus RUP. Selon Extreme Programming Explained, les pratiques XP sont :

  • Jeu de la planification : Détermine rapidement la portée de l'édition suivante en combinant les priorités métier et les estimations techniques. La réalité dépassant souvent la planification, il faut mettre cette dernière à jour.
  • Petites éditions : Lancer la production d'un système simple rapidement, puis sortir de nouvelles éditions sur un cycle très court.
  • Métaphore : Guide tout le développement avec une explication simple et commune du fonctionnement de l'ensemble du système.
  • Conception simple : Le système doit être conçu aussi simplement que possible, à tout moment. Toute complexité doit être supprimée dès qu'elle est détectée.
  • Test : Les programmeurs écrivent continuellement des tests d'unité, qui doivent fonctionner parfaitement pour que le développement continue. Les clients écrivent des tests démontrant que les fonctions sont terminées.
  • Restructuration : Les programmeurs restructurent le système sans en modifier le comportement afin de supprimer les doublons, d'améliorer la communication, de simplifier le système ou d'améliorer la flexibilité.
  • Programmation par paire : Tout code de production est écrit par deux programmeurs sur une seule machine.
  • Propriété collective : N'importe qui peut changer n'importe quel code n'importe où dans le système, à tout moment.
  • Intégration continue : Intégration et construction du système plusieurs fois par jour, chaque fois qu'une tâche est terminée.
  • Semaine de 40 heures : Ne pas travailler plus de 40 heures par semaine est une règle. Ne jamais faire d'heures supplémentaires deux semaines d'affilée.
  • Client sur site : Inclure un utilisateur réel dans l'équipe, disponible à temps plein pour répondre aux questions.
  • Normes de codage : Les programmeurs écrivent le code conformément aux règles établies en mettant l'accent sur la communication via le code.

Les activités réalisées en tant que résultat de la pratique "jeu de la planification" par exemple, seront mappées à la discipline de gestion de projet de RUP. Certains sujets de RUP, comme le déploiement du logiciel édité, n'entrent pas dans la portée de XP. La clarification des exigences est largement en dehors de la portée de XP, puisque le client définit et fournit les exigences. En raison des projets de développement plus simples qu'il traite, XP ne peut traiter que simplement les questions que RUP couvre en détail dans la discipline de configuration et de gestion des changements et dans celle d'environnement.

Pratiques XP compatibles avec RUP

Pour les disciplines où XP et le processus RUP se recoupent, les pratiques suivantes qui ont été décrites pour XP pourraient (et dans certains cas le sont déjà) être employées dans le processus RUP :

  • Jeu de la planification : Les conseils de planification XP peuvent servir pour atteindre plusieurs des objectifs indiqués dans la discipline de gestion de projet de RUP pour un projet très petit. Cela est particulièrement utile pour les projets peu formels n'étant pas contraints de produire des artefacts de gestion de projet intermédiaires formels.
  • Conception pilotée par les tests et restructuration : Ce sont de bonnes techniques pouvant s'appliquer dans la discipline d'implémentation du processus RUP. La pratique de test XP nécessitant une conception pilotée par les tests est un excellent moyen de clarifier les exigences à un niveau détaillé. Comme nous le verrons à la section suivante, la restructuration peut ne pas bien s'adapter à des systèmes plus vastes.
  • Intégration continue : Le processus RUP prend en charge cette pratique par le biais de constructions, au niveau du système et du sous-système (au sein d'une itération). Les composants testés de façon unitaire sont intégrés et testés dans le contexte du système émergeant.
  • Client sur site : De nombreuses activités du processus RUP bénéficient largement de la présence d'un client au sein de l'équipe, ce qui peut réduire le nombre de livrables intermédiaires nécessaires, en particulier les documents. Comme il s'agit de son moyen de communication préféré entre client et développeur, XP met l'emphase sur la conversation, qui implique un certain degré de continuité et de familiarité. Cependant, lorsqu'il faut effectuer la transition d'un système, même petit, la conversation seule ne suffit pas. XP tient compte de cela après coup avec, par exemple, les documents de conception à la fin d'un projet. Bien que n'interdisant pas la production de documents ou autres artefacts, XP préconise de produire uniquement ceux dont vous avez vraiment besoin. Il en est de même avec le processus RUP, mais celui-ci décrit ce dont vous pouvez avoir besoin lorsque la continuité et la familiarité ne sont pas parfaites.
  • Normes de codage : Le processus RUP possède un artefact (les instructions de programmation) qui est presque toujours considéré comme obligatoire. (La plupart des profils de risque d'un projet, qui sont un élément majeur de personnalisation, le considéreraient comme tel.)
  • Semaine de 40 heures : Comme XP, le processus RUP préconise que les heures supplémentaires ne deviennent pas une habitude. XP ne préconise cependant pas une limite fixe de 40 heures par semaine ; il tolère un nombre d'heures de travail différent. Les ingénieurs logiciel sont connus pour faire de longues journées sans compensation supplémentaire - simplement pour le plaisir de terminer ce qu'ils ont commencé - et les responsables n'y mettent pas obligatoirement un frein. Ils ne doivent par contre ni exploiter cette pratique, ni l'imposer. Ils devraient toujours comptabiliser les heures de travail effectives, même non rémunérées. Si le journal des heures travaillées de quelqu'un semble élevé sur une certaine période, cela doit cependant être sujet à vérification. Mais il s'agit là d'une question à résoudre entre le responsable et l'individu, selon les circonstances dans lesquelles cela s'est produit, et en fonction des problèmes que cela peut soulever par rapport au reste de l'équipe. Quarante heures n'est qu'une indication, mais une indication fortement recommandée.
  • Programmation par paire : Pour XP, la programmation par paire est bénéfique pour la qualité du code et cette compétence est plus agréable à utiliser une fois acquise. Le processus RUP ne décrit pas la mécanique de la production de code à un niveau aussi détaillé bien qu'il soit certainement possible d'utiliser la programmation par paire pour un processus basé sur RUP. Certaines informations sur la programmation par paire - ainsi que la conception pilotée par les tests et la restructuration - sont maintenant fournies avec le processus RUP, sous la forme de livres blancs. De toute évidence, il n'est pas obligatoire d'utiliser une de ces pratiques dans le processus RUP. Cependant, dans un environnement d'équipe avec une culture de communication ouverte, nous pouvons supposer que les avantages de la programmation par paire (en termes d'effet sur les coûts totaux du cycle de vie) sont difficiles à cerner. Les gens vont se regrouper naturellement pour discuter des problèmes et les résoudre dans une équipe qui fonctionne bien, sans être obligés de le faire.

Le principe selon lequel un bon processus doit être appliqué au niveau "micro" est souvent désagréable à entendre et ne convient pas à certaines cultures d'entreprise. RUP ne prône donc pas une application stricte. Dans certaines circonstances, néanmoins, il est de toute évidence avantageux de travailler par paire - et selon certaines autres pratiques en équipe prônées par XP - car chaque membre peut aider l'autre, comme par exemple dans les cas suivants :

  • les premiers jours de la formation des équipes, lorsque les gens apprennent à se connaître
  • les équipes qui ne connaissent pas une nouvelle technologie
  • les équipes comprenant du personnel expérimenté et des débutants

Pratiques XP qui ne s'adaptent pas bien

Les pratiques XP suivantes ne s'adaptant pas bien à des systèmes plus larges (et XP ne prétend pas qu'elles le fassent), nous mettons à profit leur utilisation dans RUP sous certaines conditions.

  • Métaphore : Pour les systèmes complexes plus vastes, l'architecture en tant que métaphore ne suffit pas. Le processus RUP fournit une infrastructure préfabriquée de description beaucoup plus riche pour l'architecture, qui n'est pas simplement faite - comme le décrit Extreme Programming Explained - de "grandes cases et connexions." Même dans la communauté XP, la métaphore a plus récemment été désapprouvée. Il ne s'agit plus d'une pratique utilisée par XP (jusqu'à ce qu'ils trouvent comment la décrire correctement - une métaphore les aiderait peut-être).
  • Propriété collective : Utile si les membres d'une équipe responsable d'un petit système ou d'un sous-système sont familiers avec l'intégralité du code. Mais avoir tous les membres de l'équipe habilités à effectuer des changements à tout moment dépend de la complexité du code. Il sera parfois plus rapide (et plus sûr) que l'individu (ou la paire) travaillant sur le segment de code en question le corrige. La familiarité avec le code, même s'il est bien écrit, diminue rapidement dans le temps, particulièrement s'il est complexe au niveau des algorithmes.
  • Restructuration : Dans un vaste système, une restructuration fréquente ne compense pas une insuffisance de l'architecture. Selon Extreme Programming Explained, "La stratégie de conception XP ressemble à un algorithme d'escalade. Vous prenez une conception simple, vous la complexifiez un peu, puis vous la simplifiez un peu et de nouveau, vous la complexifiez un peu. Le problème des algorithmes d'escalade est d'atteindre un optimum local, où la situation peut être améliorée par de grands changements mais pas par des petits." Dans le processus RUP, l'architecture permet de voir et d'accéder à la "grande pente" pour rendre tractable un système vaste et complexe.
  • Petites éditions : Le rythme auquel un client peut accepter et déployer de nouvelles éditions dépend de plusieurs facteurs, dont la taille en général, qui est habituellement liée à l'impact métier. Un cycle de deux mois peut s'avérer bien trop court pour certains types de systèmes ; la logistique de déploiement peut l'interdire.

Pratiques XP qui nécessitent une certaine prudence

Enfin, lorsqu'on applique de façon générale une pratique XP qui, à première vue, semble potentiellement utilisable dans le processus RUP (comme la conception simple) il faut la retravailler un peu et l'utiliser avec prudence.

  • Conception simple
    XP est fortement axé sur les fonctionnalités : les besoins fonctionnels de l'utilisateur sont sélectionnés, décomposés en tâches puis implémentés. Selon Extreme Programming Explained, une bonne conception pour un logiciel, à tout moment, est celle qui exécute tous les tests, n'a pas de logique en doublon, expose toutes les intentions importantes pour les programmeurs et a le moins de méthodes et de classes possibles. D'après XP, il n'est pas nécessaire d'ajouter quoi que ce soit qui ne soit pas nécessaire pour livrer la valeur métier au client.

    Il y a un problème ici, lié aux problèmes d'optimisations locales, avec ce que le processus RUP appelle les exigences "non fonctionnelles". Ces exigences donnent aussi au client une valeur métier, mais il est difficile de les exprimer en tant que besoins fonctionnels de l'utilisateur. Certaines des contraintes, appelées ainsi par le processus XP, tombent dans cette catégorie. RUP ne préconise pas une conception plus élaborée que nécessaire à quelque fin spéculative que ce soit, mais il préconise d'élaborer la conception avec un modèle d'architecture en tête, ce modèle étant l'une des clés pour répondre aux exigences non fonctionnelles.

    Pour RUP comme pour XP, une "conception simple" doit donc comprendre l'exécution de tous les tests, mais RUP précise en plus qu'elle doit comprendre des tests démontrant que le logiciel répond aux exigences non fonctionnelles. Là encore, cela apparaît comme un problème majeur au fur et à mesure que la taille du système et la complexité augmentent, lorsque l'architecture n'a pas de précédent ou lorsque que les exigences non fonctionnelles sont onéreuses. Le besoin de convertir des données (pour opérer dans un environnement distribué hétérogène) semble par exemple rendre le code trop complexe, mais cela sera toujours requis dans tout le programme.

Mappage des artefacts pour un petit projet

Lorsque nous personnalisons le processus RUP pour un petit projet et réduisons en conséquence les exigences relatives au produit, comment cela se passe-t-il pour l'équivalent de nos artefacts dans un projet XP ? Le tableau 1 montre un ensemble type d'artefacts de RUP pour un petit projet RUP.

Artefacts XP
Artefacts RUP
(Exemple pour de petits projets)
Besoins fonctionnels
Documentation supplémentaire tirée des conversations échangées
Vision
Glossaire
Modèle de cas d'utilisation
Contraintes Spécifications supplémentaires
Tests de réception et tests d'unité
Données et résultats de test

 Plan de test,  Cas de test, Suite de tests (y compris  Scripts de test et  Données de test)
Journal de test
Récapitulatif de l'évaluation du test

Logiciel (code) Modèle d'implémentation
Versions  Produit (unité de déploiement)
 Notes sur l'édition
Métaphore Document d'architecture logicielle
Conception (esquisse CRC et UML)
Tâches techniques et autres tâches
Documents de conception produits à la fin
Documentation de support
Modèle de conception
Normes de codage  Instructions spécifiques au projet
Espace de travail
Infrastructure préfabriquée de test et outils
 Plan de développement
 Configuration de l'environnement de test
Plan d'édition
Plan d'itération
Estimation des besoins fonctionnels et estimation des tâches
Plan de développement logiciel
Plan d'itération
Plan global et budget Etude de rentabilité
Liste de risques
Rapports sur la progression
Enregistrement du temps passé pour le travail relatif aux tâches
Données métriques (y compris les ressources, la portée, la qualité, le temps)
Suivi des résultats
Rapports et notes sur les réunions
Evaluation d'état
Evaluation d'itération
Compte-rendu de la revue
Incidents (et données associées) Demandes de changement
Outils de gestion de code Référentiel du projet
 Espace de travail
Solutions rapides (de type spike)

Prototypes
Prototype d'interface utilisateur
Bien-fondé de la conception de l'architecture

XP lui-même (ses recommandations et conseils)

Liste des idées de test
 Instructions spécifiques au projet

[Non compris dans XP]

Modèle de données
 Matériel de support utilisateur.

Tableau 1 : Mappage des artefacts de XP et de RUP pour un petit projet

Bien que la granularité des artefacts varie dans RUP et XP, les artefacts de RUP pour de petits projets (type de projets que XP traite facilement) sont facilement mappés aux artefacts d'un projet XP.

Notez qu'il y a dans le tableau des artefacts qui ne sont pas traités par XP mais sont nécessaires pour bon nombre de projets. Il s'agit du modèle de données et des artefacts liés au déploiement tels que le  matériel de support de l'utilisateur.

Activités

Le processus RUP définit une tâche comme étant un travail réalisé par un rôle, soit en utilisant et en transformant des artefacts d'entrée, soit en produisant des artefacts de sortie nouveaux et modifiés. Il énumère aussi ces activités et les répertorie selon ses disciplines. Ces disciplines comprennent : les exigences, l'analyse et la conception, le déploiement et la gestion de projet (entre autres).

Les activités sont liées au temps par le biais des artefacts qu'elles produisent et utilisent : une activité peut normalement commencer si ses entrées sont disponibles (dans un état de maturité convenable). Si l'état de l'artefact le permet, les activités producteur-consommateur peuvent se chevaucher dans le temps ; il n'est pas nécessaire qu'elles soient divisées en séquences de façon stricte. Les activités doivent fournir des conseils sur la façon dont un artefact doit être produit et peuvent aussi aider le responsable du projet dans sa planification.

Les "meilleures pratiques" sont intégrées au processus RUP tel qu'il est décrit en termes de cycle de vie, d'artefacts et d'activités : ce sont des principes d'ingénierie logicielle reconnus pour produire un logiciel de qualité, construit selon un calendrier et un budget prévisibles. Le processus RUP prend en charge ces meilleures pratiques (ce sont des thèmes qui reviennent tout au long du processus) et les réalise à travers ses activités (et leurs artefacts associés). Elles respectent les principes clés qui fondent le RUP. Notez que XP utilise aussi la notion de "pratiques" mais, comme nous le verrons plus loin, elles ne correspondent pas exactement au concept de "meilleures pratiques" de RUP.

XP présente une vision du développement logiciel plutôt engageante du fait de sa simplicité car il a quatre activités de base - coder, tester, écouter et concevoir - qui doivent être exécutées et structurées selon certaines pratiques de support (comme mentionné dans le chapitre 9 de Extreme Programming Explained). Comme il a déjà été dit, en termes de portée, les activités XP se rapprochent davantage des disciplines RUP que des activités RUP, et une grande partie de ce qui a lieu au cours d'un projet XP (en plus des quatre activités de base) résulte de l'élaboration et de l'application de ses pratiques.

Il existe donc un équivalent XP des activités du processus RUP, mais les activités XP ne sont pas formellement identifiées et décrites comme telles. Dans le chapitre 4 "User Stories" de Extreme Programming Installed par exemple, vous trouverez un paragraphe traitant de la "définition des exigences avec des besoins fonctionnels, décrits sur des cartes". Ce chapitre est un mélange de description de processus et de conseils sur les besoins fonctionnels et comment les produire. Et cela continue de la même manière : dans les différentes sections des livres XP (sous des titres qui sont un mélange de contenu orienté sur les artefacts et de contenu orienté sur les activités), vous trouverez une définition des "choses produites" et des "choses faites" avec un niveau de détail et de prescription varié.

Le degré de prescription apparemment élevé de RUP résulte du fait qu'il est plus complet et formel dans le traitement des activités et des entrées et sorties de ces dernières. Il n'y a pas d'insuffisance de prescription dans XP, mais peut-être qu'en voulant rester simple, il omet simplement le formalisme et les détails. Un manque de spécificité ne représente ni une force ni une faiblesse, mais il ne faut pas pendre le manque d'informations détaillées dans XP pour de la simplicité. Les développeurs expérimentés peuvent très bien se passer de détails mais, dans beaucoup de cas, c'est une aide pour les nouveaux membres de l'équipe d'avoir davantage de détails ainsi que pour ceux qui essaient de rattraper leur retard par rapport à l'approche de l'équipe concernant le développement logiciel.

Avec les activités, tout comme avec les artefacts, il est important de rester concentré sur ce que l'on cherche à atteindre. Mener une activité à l'aveuglette n'est jamais très bon. Les activités et les instructions qui y font référence sont faites pour être consultées lorsque vous avez besoin d'atteindre un objectif mais elles ne représentent en aucun cas une excuse pour ne pas avoir à chercher à comprendre ce que vous essayez de faire. Les utilisateurs de XP ont cet état d'esprit et nous pensons qu'il devrait en être de même avec chaque utilisateur de RUP.

Rôles

Dans le processus RUP, les activités sont réalisées par les rôles (où plus précisément par des individus ou des groupes jouant des rôles). Les rôles sont aussi responsables d'artefacts particuliers ; le rôle qui est responsable va généralement créer l'artefact puis s'assurer que tout changement, quel qu'il soit, effectué par d'autres rôles (si cela leur est permis) n'endommage pas l'artefact. Un individu ou un groupe de personnes peut avoir un seul rôle ou plusieurs. Il n'est pas nécessaire de mapper un rôle à une position unique seulement ou un "emplacement" dans une organisation.

Extreme Programming Explained identifie sept rôles pouvant être appliqués à XP - programmeur, client, testeur, auditeur, conseiller, consultant et patron - et décrit leurs responsabilités et les compétences requises pour les personnes qui vont tenir ces rôles. Certains autres livres XP y font aussi référence. La différence entre le nombre de rôles dans XP et dans RUP est facile à expliquer :

  • XP ne couvre pas toutes les disciplines de RUP.
  • Les rôles dans XP sont davantage comparables aux positions au sein d'une organisation (peut-être avec plusieurs responsabilités) qu'aux rôles dans RUP. Par exemple, un programmeur de XP tient plusieurs rôles de RUP - implémenteur, réviseur de code et intégrateur - qui requièrent des compétences légèrement différentes.

Rôles XP et RUP pour un petit projet

Lorsque les rôles de RUP sont mappés vers un petit projet, le nombre de rôles de style XP correspondants est considérablement réduit en ce sens que les positions, ou fonctions, sont au nombre de 5. Le tableau 3 (tiré du processus RUP) montre ce mappage avec le rôle XP correspondant.

Rôle XP Membre de l'équipe de petit projet RUP Rôle RUP
Conseiller
Consultant
Patron
Sally Slalom, cadre supérieur Responsable de projet
 Responsable du déploiement
Réviseur technique
Responsable de la configuration
Responsable du contrôle des changements
Client Partie prenante (comme documenté dans la Vision)
Réviseur de gestion
Réviseur technique (exigences)
Client
Patron
Auditeur
Tom Telemark, ingénieur logiciel senior Analyste système
Spécificateur d'exigences
Concepteur d'interface utilisateur
Architecte logiciel
Réviseur technique
Responsable de test
Analyste de test

Rôles de développeur (moindre)

Programmeur
Testeur

Susan Snow, ingénieur logiciel

Henry Halfpipe, second ingénieur logiciel

Concepteur
Implémenteur
Réviseur technique
Intégrateur
Concepteur de test
Testeur
 Rédacteur technique
Auditeur Patrick Powder, Assistant administratif Responsable de la maintenance du site Web du projet, assistant du responsable de projet pour la planification et le calendrier et du responsable du contrôle des changements pour le contrôle des changements apportés aux artefacts. Il peut aussi assister d'autres membre du personnel si nécessaire.

Table 3 : Mappage des rôles XP aux rôles RUP pour un petit projet

Utilisation des pratiques XP avec RUP

Le processus RUP est une architecture préfabriquée de processus à partir de laquelle on peut configurer et instancier des processus particuliers. Il doit être configuré ; cette étape est obligatoire, définie par le processus lui-même. Nous devons comparer une version personnalisée de RUP avec XP, c'est-à-dire avec le processus RUP personnalisé selon les caractéristiques du projet que XP établit explicitement (ainsi que celles que l'on peut induire). Un tel processus RUP personnalisé peut intégrer beaucoup de pratiques XP (telles que la programmation par paire, la conception pilotée par les test et la restructuration) mais il n'en est pas pour autant identique à XP en raison de l'importance qu'il donne à l'architecture, à l'abstraction (dans la modélisation), aux risques et de sa structure différente dans le temps (phases et itérations).

XP est volontairement orienté sur l'implémentation d'un processus léger pour de petits projets. Il comprend aussi les descriptions partielles (tout au moins dans les livres). Lors d'une implémentation XP, il y a toujours des choses à découvrir, inventer ou définir à la volée. Le processus RUP peut être utilisé à la fois pour des projets dans la portée de XP ou en dehors, que ce soit en termes de taille ou de type. Comme le montre cette introduction, le processus RUP est finalement bien compatible avec la plupart des pratiques décrites par XP.

Il faut bien garder à l'esprit que l'essence de XP est de se concentrer sur l'organisation, les gens et les cultures. C'est un élément important pour tous les projets et cela s'applique certainement aux projets utilisant le processus RUP. Les projets de petite envergure peuvent grandement bénéficier du recours à ces pratiques.

Références concernant le processus Agile

  • eXtreme Programming (XP) (voir http://www.extremeprogramming.org/more.html pour plus d'informations.):
    • Extreme Programming Explained: Embrace Change. Kent Beck explique les concepts et la philosophie de cette méthode. Ce livre explique le quoi et le pourquoi mais pas le comment.
    • Refactoring Improving the Design of Existing Code. Martin Fowler écrit ici le premier volume de référence sur la restructuration. Il est présenté sous la forme de patterns et beaucoup d'exemples sont au format Java. Ce livre explique comment et pourquoi restructurer.
    • Extreme Programming Installed. De Ron Jeffries, Chet Hendrickson, Ann Anderson. Ce livre présente des pratiques XP particulières de manière plus détaillée que Extreme Programming Explained. Ce livre explique comment programmer XP.
    • Planning Extreme Programming. De Kent Beck et Martin Fowler. Ce livre présente les dernières réflexions sur la planification de logiciel dans un environnement de livraison rapide. Ce livre explique comment mener un projet XP.
    • Extreme Programming Examined. De Giancarlo Succi et Michele Marchesi. Articles présentés à la conférence XP2000. Ensemble d'articles qui couvre la plupart des sujets.
    • Extreme Programming in Practice. De Robert C. Martin et James W. Newkirk. Description en détail d'un projet réel ayant eu recours à XP.
    • Extreme Programming Explored. De William C. Wake. Ce livre est basé sur le fameux site web XPlorations. Il explore en détails certains sujets particuliers.
    • Extreme Programming Applied: Playing to Win. De Ken Auer et Roy Miller. Expériences menées par des pionniers sur l'application de XP. Publication en septembre.

Pour des informations concernant les autres membres du groupe Agile Alliance, voir http://www.agilealliance.org.