le site http://www.extremeprogramming.org/ méritait une traduction, je n'ai pas trouvé d'explications aussi claires et en français. Le début de l'article est une traduction directe, la suite rend compte des idées, mais de manière plus éloignée du texte original.

Première approche

Commençons par une question simple: Qu'est-ce que XP ?
Si vous avez répondu "un produit de Microsoft", fuyez ce lieu ;-)
XP = extreme programming...Comme vous le verrez, c'est une approche volontaire et disciplinée du développement logiciel.
Nous pouvons ensuite nous demander quand employer XP. Les projets à risque avec un périmêtre fonctionnel mouvant sont parfaits pour mettre XP en oeuvre.
Ces projets bénéficieront en effet grâce à XP d'une plus grande productivité. Mais avons-nous besoin d'une n-ième méthodologie de développement ? Bien sûr !

  • XP a une approche régénératrice.
  • XP est réussi parce qu'il implique le client au maximum et promeut le travail d'équipe. Et ne me dîtes pas que c'est déja le cas sur vos projets, sinon c'est que vous faîtes du XP sans le savoir...Rassurez vous, il n'y a pas de copyright dessus, car ce n'est pas un produit de MIcrosoft... :-C

L'aspect le plus étonnant de XP est l'ensemble de règles qui le constitue, à la fois pratiques et simples.
Elles semblent peut-être même na?ves au début, mais apportent rapidement un changement d'esprit bienvenu. Les clients ont plaisir à être associé au processus de production du logiciel et les développeurs contribuent indépendamment de leur niveau d'expérience.
La carte de XP montre comment les rêgles travaillent ensemble pour former une méthodologie de développement.

- Finalement, XP c'est la méthode que tout le monde connait, 
mais que personne n'applique non? - Si si, c'est ça... - Ok, je suis convaincu, je veux essayer XP comment je commence ?

Vous pouvez commencer par ajouter un peu d'XP à vos habitudes ou l'adopter d'un coup d'un seul. Peu importe la taille du projet.

- Mais, existe-t-il déja des retour d'expérience sur XP ? 
- oui, ici.

La suite

L'extreme programming (XP) est une approche maîtrisée du développement logiciel. Beaucoup d'entreprises industrielles ou autres, de toutes les tailles, ont expérimenté avec succès cette méthode.
XP réussit parce qu'il est focalisé sur une chose : la satisfaction du client (et ça, ça me nous fait déja plaisir...).
La méthodologie est conçue pour fournir le logiciel au client en temps et en heure, et surtout en accord avec ses besoins. XP autorise les développeurs à répondre aux exigences parfois :-C changeantes des clients, même tardivement dans le cycle de vie du logiciel. Cette méthodologie met également en exergue le travail d'équipe. Les chefs de projets, les clients, et les développeurs sont tous membres d'une équipe dont la priorité première est de délivrer un logiciel de qualité.
XP met en application une méthode simple, mais efficace de développement s'appuyant sur le groupware (logiciel de travail en groupe, type oulook : mail, réunions, partage de documents etc.)
XP améliore la gestion d'projet de logiciel de quatre manières essentielles :

  • La communication : c'est le moyen fondamental d'éviter les erreurs. Le moyen à privilégier est la conversation directe, en face à face. Les moyens écrits ne sont que des supports et des moyens de mémorisation ;
  • Le courage : il est nécessaire à tous les niveaux et de la part de tous les intervenants, notamment chez les développeurs (quand des changements surviennent à un stade avancé du projet, ou quand des défauts apparaissent) et chez le client (qui doit pouvoir prioriser ses demandes) ;
  • Le retour d'information (feedback) : les itérations sont basées sur les retours d'informations du client, permettant une adéquation totale entre l'application finale et sa demande ;
  • La simplicité : en Extreme Programming, la façon la plus simple d'arriver à un résultat est la meilleure. Prévoir préalablement des évolutions futures n'a pas de sens. Ce principe est résumé en une phrase : ? Tu n'en auras pas besoin. ? (en anglais ? You ain't gonna need it. ?). La meilleure manière de rendre une application extensible est de la rendre aussi simple (et donc simple à comprendre) et aussi bien conçue que possible.

(Ces 4 points sont tirés de l'article XP de Wikipedia)

Les programmeurs XP communiquent avec leurs clients et collègues programmeurs. Ils maintiennent une conception simple et claire. Ils obtiennent un feedback (~retour client) en commençant les tests d'acceptation client dés le premier jour (façon de parler, ie le plus tôt possible). Ils fournissent les nouvelles versions aux clients le plus tôt possible. Sur cette base, les programmeurs peuvent répondre sans fléchir aux changements impromptus, qu'ils soient techniques ou fonctionnels.
XP est différent. Il ressemble beaucoup à un puzzle. Il y a beaucoup de petits morceaux. Individuellement les morceaux n'ont pas beaucoup de sens, mais une fois tous combinés, une image cohérente se dessine.
C'est une alternative vraiment intéressante par rapport aux méthodes traditionnelles de développement type cycle en V, par exemple...j'ai honte là...

Ok d'accord, mais concrêtement?

Se convaincre que faire un programme de qualité, appliquer les design patterns, c'est essentiel, et ça rapporte :
On sait que de manière générale, les coûts d'un développement informatiques sont répartis en 1/20 pour le matériel et 19/20 pour le développement, la maintenance, les évolutions (les coûts humains...). Voila la situation sans XP, vous allez vous reconnaître :

  • les programmeurs codent chacun dans leurs coin, parlent un peu, optimisent pas mal leur code, oublient de mettre des commentaires (bouhhh). Résultat, le projet aboutit, et grâce aux super tunings des uns et des autres, on économise 20% sur le prix des machines car le code est très optimisé, au détriment d'une lecture simple et d'une bonne maintenabilité...Pas grave, puisqu'on a beaucoup gagné sur les machines.

Avec XP, le projet ressemblerait à ça :

  • Les programmeurs programment par binômes (pair programming), ce qui augmentent beaucoup la lisibilité et les commentaires, ils discutent plus entre eux, et ils appliquent les design pattern, le couplage lâche, pensent à la maintenance... Bon les traitements sont moins optimisés car le code contient moins de tuning, ils n'ont rine économisé sur les machines, peut être même ont-ils perdu des sous. Par contre coté maintenabilité, évolutivité, scalabilité, ils sont au top. Ils ont réussi à gagner 10% sur les coûts humains...

Vous pouvez faire le calcul, XP.org l'a déja fait pour nous, gagner 10% sur les coûts de développement/maintenabilité vaut beaucoup mieux que 20% en achat de machines. Et les cheveux arrachés ne sont pas intégrés dans le calcul.

Bon ok, il faut maintenant tempérer ce calcul un peu trop simpliste, il est évident que certains projets ne pourront pas aboutir sans quelques tunings d'experts, mais penser dés le début maintenabilité, évolutivité, souplesse, scalabilité rapportera toujours plus. Les clients sont chaque jour plus exigents, en périmêtre et en délai, seuls des développements conçus pour durer pourront réussir.
Le travail à deux me semble aussi un point essentiel : il permet d'intégrer et de valoriser très rapidement des juniors sur un projet...

Encore?

Le développement piloté par les tests.
Concernant le problème des bugs, XP prône l'écriture de tests automatisés avant, pendant et après l'écriture du code. On constitue ainsi un filet de sécurité très serré, et il devient peu probable qu'un bug détecté se reproduise dans plusieurs versions consécutives.

Changement du périmètre fonctionnel.
L'une des spécifités de XP est de mener très tôt des tests d'acceptation au client. Cela consiste à présenter el plus rapidement possible au client une pré-version, afin d'être capable de réorienter le développement, de rajouter des fonctionnalités auxquelles le client n'avait pas pensé etc...Ainsi, la mouvance des besoins du client devient quelquechose de maîtrisé. Bien sûr, des changements techniques peuvent également intervenir dans ses pré-versions, mais l'anticipation permettra de les intêgrer sans douleurs.
Le développeur acquiert finalement une fonction de conseil auprès de son client. Arrêtons d'espérer que nos clients nous doivent, à nous techniciens des spécifications claires, complètes et cohérentes.

Itérative et incrémentale...

La méthode décrite ci-dessus est souvent dite itérative, on doit mener des tests d'acceptation des logiciels par le client à plusieurs reprises avant la livraison, et incrémentale : cela signifie qu'on va tester petit à petit l'ensemble du périmêtre de l'application.

Mais ...

- Si on commence à tester tout le temps, on va se rendre compte 
à l'avance de certains problèmes, techniques et fonctionnels? - En effet, XP permet de maîtriser ses risques projets. :-)

Le testing

Les plans de tests automatisés sont au coeur de XP, ils constituent ce qu'on appelait plus haut le filet de sécurité. Il est primordial de commencer par mettre en place des outils pour les développeurs qui permettent de créer facilement des tests unitaires et fonctionnels.
Ces plans de tests seront augmentés en continu par de nouveaux tests portant sur les développements en cours, ou concernant des points que l'on avait oublié de tester par le passé. Ce qu'il est important de retenir, c'est qu'il est primordial de rejouer l'ensemble des tests de manière récurrente pour maîtriser l'accroissement du nombre de bugs. Ainsi, si les tests ne sont pas automatisables, la charge de test grandira et ne sera plus maîtrisable très rapidement.

Pair programming, travail en binôme

La productivité de programmeurs travaillant en binôme, à deux sur un même poste est plus grande que la somme des productivités des programmeurs séparés. C'est l'expérience XP qui le dit...A chacun de se faire son idée la-dessus, en intégrant bien sûr des critères de mesure portant sur :

  • qualité du code
  • maintenabilité
  • l'aptitude à évlouer
  • commentaires dans le code

dans l'appréciation de la productivité...

Plus de lecture? l'intégration continue fait partie de XP, et présente de beaux atouts... Plus de lecture? les ''méthodes agiles'' sur wikipedia.