Pour commencer avec XP

Un article de Agile-Swiss.

Introduction

L'avènement des nouvelles technologies et l'accélération des cycles de développement mettent à mal les méthodologies et les hiérarchies traditionnelles :

développer des logiciels comme on fabrique des voitures ne fonctionne plus. (à l'exception de certains domaines où sécurité et tracabilité priment sur rentabilité et réactivité).

Les méthodologies agiles répondent à ce constat. L'eXtreme Programming (XP) fait partie de cette famille, et rencontre le plus d'échos dans le monde du développement logiciel.

Adopter XP revient avant tout à changer de mentalités et d'habitudes.

Côté développeurs, cette évolution peut se faire assez rapidement. Même si certains principes déroutent, au point de susciter de la méfiance, le pragmatisme d'XP convainc généralement les personnes curieuses, et désireuses d'améliorer leur façon de travailler. Cette adoption enthousiaste a sa contre-partie. Elle peut creuser le fossé entre développeurs et le management.(XP c'est un truc de codeurs...) Il est vrai aussi que le terme eXtreme est peut-être malheureux, et engendre bon nombre de préjugés.

L'adoption côté management est un défi encore à relever. La meilleure connaissance d'XP, ainsi que la maturité croissante des équipes XP devraient y aider.

Nous sommes conscients qu'XP n'est pas la solution à tous les problèmes que peut rencontrer un développement informatique. Ni qu'elle puisse s'appliquer dans toutes les configurations (freins technologiques, hierarchiques ou historiques). Mais nous sommes convaincus que c'est la collaboration la plus efficace entre un client et une équipe de développement.

"Le" Livre...

...avec lequel tout a commencé pour bon nombre d'entre nous :

"eXtreme Programming explained, Embrace Change" de Kent Beck chez Addison Wesley.

Remarquablement synthétique, ce livre expose clairement les valeurs et pratiques de l'XP par l'un des fondateurs de cette méthodologie. Si vous ne deviez lire qu'un seul livre sur XP, ce doit être celui-ci. Aucune connaissance technique n'est requise. Mais une pratique de la gestion traditionnelle de projets devrait vous aider à vous convaincre de l'intérêt de cette méthodologie...

Nous vous recommendons tous les ouvrages de la collection XP Series chez Addison Wesley. Et particulièrement, en plus de l'ouvrage déjà cité :"Extreme Programming Installed" de Ron Jeffries, Ann Anderson, Chet Hendrickson et "Planning Extreme Programming" de Kent Beck, Martin Fowler

Au travail!

Les pratiques XP se soutiennent mutuellement, leur synergie est frappante lorsqu'il est possible de toutes les mettre en oeuvre.

Devez-vous passer brusquement à XP ? Nous ne vous le conseillons pas, et vous suggérons plutôt une adoption progressive des pratiques. C'est en les mettant en oeuvre que l'on se rend compte de leur intérêt. Par exemple, comment imaginer se passer de l'intégration continue une fois que nos scripts ant ou maven sont prêts, et que les compilations/tests de nuits tournent sans problèmes ?

J'emprunte à Ron Jeffries xprogramming.com le schéma qui présente les pratiques XP en montrant clairement quels acteurs elles impliquent :

La "traduction" de chaque pratique

Pair programming : Travail en binôme pour le code mis en production

Test Driven Development : Penser chaque fonctionnalité en termes de tests qui la valident avant de penser à leur conception.

Coding Standard : Des standards de codage utilisés systématiquement par toute l'équipe

Refactor : Nettoyer, épurer le code en continu sans changer la fonctionnalité

Simple Design : Rechercher la solution la plus simple (qui fonctionne !)

40h week (ou 42) : Eviter les heures sup. systématiques

On-site Customer : Une personne côté client est disponible tout le temps pour aider à la compréhension du métier

Short releases : Des livraisons fréquentes

Planning game : Les spécifications sont sous formes de petites "user-stories" pondérées dans une unité libre. cf le livre consacré déjà cité.

Metaphor : Diffuser un vocabulaire commun pour désigner les différentes parties du système

Continuous integration : La cohérence du système en cours de développement est vérifiée plusieurs fois par jour

Collective ownership : Tout le monde peut toucher au code de tout le monde

Pour continuer

Parcourez les indispensables liens en commençant par le Manifesto for Agile Software Development!