Extreme programming : retour d’expérience

Par | Classé dans Agilité | Le 10/01/2012

Tags « »

0

Intro

SCRUM, Extreme Programming (XP), Lean-management, le développement agile, c’est tendance !

Objectifs : améliorer la réactivité, la qualité et le coût du logiciel avec en ligne de mire la sacro-sainte satisfaction client.

J’ai participé, pendant deux ans, à un projet réalisé « from scratch » en suivant une méthodologie agile : l’Extreme programming. En tant que développeur (sur les deux ans), et « coach XP » (sur les six derniers mois).  L’objectif du projet était le développement d’une application de trading « in-house » dans une banque d’investissement, la taille de l’équipe a varié au cours de ces deux ans de 3 à 7 (manager compris).

Ce post a pour but d’expliquer les pour et les contre de cette méthode tel que je l’ai vécu.

L’extreme programming

Sans chercher à être exhaustif (wikpedia est ton ami), voici les grands principes XP :

  • Pair-programming : on code à deux devant un PC, le codeur et le reviewer. les rôles s’inversant régulièrement. On change de binôme à chaque tâche.
  • TDD (Test driven development) : chaque méthode, chaque portion de code est systématiquement testée avant d’être codée.
  • KISS (Keep It Simple, Stupid) : On cherche toujours la solution la plus simple sans anticiper les besoins futures (pêché mignon du développeur ?).
  • Refactoring : On cherche en permanence à avoir le code le plus propre possible
  • Itérations courtes : le cycle développement-release est très court (1 semaine à 1 mois)

Les plus

  • Un code clean : Non seulement l’XP via ses principes favorise une plus grande qualité de code, mais j’irai plus loin : il l’impose ! En effet, le TDD dans du code spaghettis, dupliqué, du code mort…c’est sinon impossible, franchement pénible. Idem pour le refactoring, très cher s’il n’est pas fait suffisamment tôt.
  • Agilité : Je vous entends « Il est malin le type, c’est l’objectif ! ». Ok, mais c’est un objectif atteint. Le client peut changer d’avis et ses priorités comme de chemise (et il ne s’en prive pas).
  • L’équipe te rend plus fort : Grace au pair-programming, les développeurs montent rapidement en compétence. Pour le développeur, c’est l’opportunité de se former grâce au reste de l’équipe. Se former sur l’application bien sur, mais aussi sur tout ce qu’on peut apprendre à observer un autre développeur à l’oeuvre.
  • Interchangeabilité : XP refuse la spécialisation, chaque développeur doit maîtriser l’ensemble de l’application. C’est possible en associant sur chaque développement un « sachant » et un « ignorant » sur la partie concernée. C’est clairement un luxe pour le manager étant donné le turnover dans la plupart des projets informatiques. Les mauvaises langues parleront de développeur « jetable », mais pour le projet, c’est un plus.

Les moins

  • Dites au revoir à votre « Touch » : Si vous aimez utiliser vos raccourcis « custom », vos conventions de nommage, vos patterns, vos lib. Bref ! VOTRE façon de coder : Oubliez ! vous allez coder la moitié du temps sur un autre PC, et quelqu’un d’autre codera sur le votre. L’uniformisation des l’environnement, des outils et des pratiques est par conséquent obligatoire. C’est positif pour le projet, mais l’effort d’adaptation est réel.
  • Explications, négociations, compromis : Développer à deux, ce n’est pas naturel. Il faut en permanence argumenter, expliquer son cheminement de pensée. Quand au reviewer, il doit rester concentrer sans le clavier, challenger chaque décision,  être force de proposition et chasser chaque bug ou coquille, il doit enfin être patient s’il maitrise mieux le sujet sans chercher à « attraper » le clavier. Il faut aussi veiller à garder un équilibre, le plus timide ou le plus junior ne devant pas se faire « manger ». Bref, c’est formateur, le code écrit est meilleur, mais je suis convaincu que c’est plus exigent que de coder seul.
  • Le TDD, ce n’est pas sexy : Je suis fermement convaincu de l’intérêt du TDD (limitation des bugs et des régressions, refactoring sure, spécification, code découplé), mais il faut avouer qu’écrire des centaines de tests et avoir la (fausse ?) impression d’aller deux fois moins vite, c’est parfois rébarbatif.
  • Pas de petit chef : Le pair-programming, l’absence de spécialisation et la volonté en XP d’aller vers l’essentiel (le code) limite quelque part les responsabilités du développeur. Dans une équipe classique, chaque développeur deviendra probablement référent sur certains domaines, participera à des réunions, et prendra en charge certaines responsabilités.  En XP, le manager manage, les codeurs codent (PS : si c’est tout ce que vous aimez, vous pouvez passer cela dans la rubrique plus), et nul n’est indispensable.

Avant de conclure, quelques remarques inclassables, ni en plus, ni en moins

L’extreme programming, à prendre ou a laisser.

Je ne vois pas les différentes pratiques de l’XP comme une boîte à outil où l’on prend et on jette en fonction des envies. Les différentes pratiques se complètent et se renforcent mutuellement.

  • Pour livrer très fréquemment, il faut pouvoir valider une version très rapidement, d’où le TDD. (Si vous voulez tester l’application de fond en comble tous les 15 jours à la main, ce sera sans moi).
  • Prendre systématiquement la solution la plus simple en négligeant le refactoring, c’est la porte ouverte au code spaggeti et autres rustines.
  • Faire du refactoring fréquemment sans couverture de tests unitaires, c’est l’assurance de régressions.
  • Refactorer, c’est bien plus sûr avec une deuxième paire d’yeux.

Bien sur, ça n’est pas vrai pour tout,  le TDD n’a pas attendu l’XP pour exister.

N’est pas XP qui veut

Tout projet n’est pas adapté à l’XP. Il faut un client accessible et prêt à s’investir et des développeurs ouverts aux pratiques XP. Il faut enfin que le manager soit convaincu par la méthode et à l’écoute des développeurs (accepter les coûts donnés par des développeurs et les dépassements inévitables par exemple).

L’environnement de développement est également primordial. Framework de tests unitaires, de mocking, outils de refactoring, d’analyse statique de code, de couverture de tests, usine de build…Tous ces outils « nice-to-have » dans un autre projet deviennent plus ou moins indispensables en XP. En conséquence,  un projet C++ ou dans un langage web est sans doute moins adapté à l’XP qu’un projet Java ou .NET.

Conclusion

Au final, même si j’ai la critique un petit peu facile par nature, je me range plutôt du côté des « pro-XP / pro-agiles » .Le projet auquel j’ai participé est à mon avis un succès, mais il est important de noter qu’il correspond en tous points au « contexte idéal » décrit ci-dessus.

Quant aux objectifs mentionnés au début du post (améliorer la réactivité, la qualité et le coût du logiciel), les deux premiers sont clairement atteints. Pour le troisième,  c’est la question à 1 Milliard.

Ce qui est sûr, c’est que l’on est très loin d’un coût multiplié par quatre. Certes on code deux fois plus (TDD), et à un instant donné, la moitié de l’équipe ne code pas (elle ne dort pas non plus). Mais cela est compensé par des bugs à fixer en moins, un code de meilleur qualité, une montée en compétence plus rapide et un scope correspondant exactement au besoin client. Est-ce que c’est « surcompensé » ou « sous-compensé », là est le vrai débat. Mon intuition c’est que le gain est négatif dans un premier temps (un an, peut-être deux) puis positif par la suite.

Voilà pour ma vision de l’Extreme programming, à prendre pour ce que c’est, un avis basé sur une expérience mais certainement pas une vérité.

Partagez !    |