L’Extreme Programming (ou XP)
Et oui, c’est la rentrée (pour les étudiants, moi, je suis déjà revenue de vacances depuis longtemps !), et avec la rentrée vient une nouvelle idée d’article. En réalité, ça vient grâce au boulot, puisque lors de la journée de restitution des Tech Days (2 semaines durant l’été où on s’empare d’un sujet tech pour améliorer Pix), nous avons pu assister à la conférence d’un dev' senior (Pascal Le Merrer, trouvable chez Mastodon) sur le sujet de l’Extrême Programming.
Mais, savez-vous ce que c’est que l’extreme programming ?
Il faut admettre que ce terme fait peur “extrême”, on a l’impression qu’il faut coder h24 pour finir un projet à temps ! En réalité, c’est assez mal choisi, et j’aurais tendance à appeler ça plutôt “Cool Programming” !
Pour des raisons de simplification, on va dorénavant écrire XP pour faire référence à l’Extreme Programming, d’autant que c’est le raccourci souvent utiliser pour évoquer cette méthode.
La Méthode Agile, ça vous parle ?
Connaissez-vous la Méthode Agile ? Ce manifeste qui établi 12 principes de base pour développer des solutions de la meilleure des façons. Je pense que chacun et chacune d’entre vous qui dev' connaissent la Méthode Agile, et parfois même l’une d’entre elle, la plus connue Scrum, parfois confondue avec la méthode Agile, d’ailleurs.
Pour reprendre les bases : La Méthode Agile est donc un manifeste qui a été rédigé par 17 dev' afin d’essayer de trouver les principes qui permettraient de rendre plus efficace le travail de conception d’un logiciel. Puisqu’avant, on développait la plupart du temps en Cycle en V, la méthode de travail linéaire imposée rendait la gestion du projet très lourde.
Compliqué de faire des modifications, plusieurs mois sans revoir le client… bref, c’est comme si on demandait à un menuisier de faire un lit 2 places en 190x160, qu’il disait oui, et qu’on le revoyait 5 mois plus tard avec le lit fini. Mais entre deux, on aurait bien aimé pouvoir choisir le type de bois, et puis si on voulait des pieds carrés ou arrondis, voire même, le temps qu’il fasse ses schémas, qu’on réalise qu’en fait, c’est un peu petit, on préfèrerait plutôt du 200x170, …
Bref, vous l’aurez compris, la Méthode Agile tente de définir de meilleures conditions pour les 3 parties qui entrent en jeu dans la conception d’un projet : le client, le commercial, et l’équipe technique. Elle a été conçue en 2001.
L’XP est arrivé, lui, en 1999.
L’histoire de l’XP
Ces pratiques ont été pensées essentiellement par un certain Kent Beck, qui s’est servi de son expérience professionnel (notamment via son expérience de chef de projet chez Chrysler) afin de trouver un moyen de concilier l’humain et la qualité du travail fourni, via une discipline et une certaine souplesse.
Pratiques qui seront reprises en partie pour la rédaction du manifeste Agile.
Pour essayer de développer un peu, l’XP repose sur 5 valeurs fondamentales :
1. La communication
Il s’agit du moyen ultime pour éviter les problèmes. Ainsi, le pair-programming, notamment, très utilisé en XP, oblige à communiquer afin de résoudre les soucis, qu’ils soient techniques ou personnels.
2. La simplicité
Là, on parle aussi du code, mais qu’est-ce qu’un code simple ? Doit-il être court pour être simple ? Je pense que vous savez répondre à cette question, on sait tous qu’une condition rédigée en une ligne n’est pas forcément plus lisible qu’une succession de if.
let grade = "A";
// une condition classique, avec une succession d'if
if (grade == "A") (
return "Parfait";
)
if (grade == "B") (
return "Bien";
)
if (grade == "C") (
return "Pas mal";
)
return "Moyen";
// un one-liner. Plus court, mais pas forcément plus lisible
grade == "A" ? "Parfait": grade == "B" ? "Bien": grade == "C" ? "Pas mal": "Moyen";
// exemple tiré de chez linuxhint.com
C’est aussi une façon de faire évoluer plus sereinement un code. Si on démarre avec un code simple. On pourra faire évoluer le projet plus facilement.
Pour prendre un exemple concret : si ton projet perso, tu le penses comme si des millions de visiteurs allaient l’utiliser dès demain, c’est foutu. Tu vas vouloir implémenter des tonnes de trucs totalement inutiles pour faire marcher ton projet : on met en place un load balancer, on va metter en place un CI, et puis imposer la double authentification, etc. Commençons simple : on code ce pour quoi le projet existe (sa fonctionnalité principale). Ensuite, on pourra songer à faire agrandir le projet en fonction des besoins.
3. Le feedback
Le feedback, ou retour d’informations est capital tant du côté des développeurs et développeuses que du côté du client. Ainsi, on privilégiera le TDD. On créé un code qui teste la fonctionnalité à développer. Le test est au rouge. On code (simple !) la fonctionnalité pour mettre le test au vert. S’il passe au vert, on se limite à faire de la refacto si nécessaire. On ne complexifie pas inutilement notre code, s’il fonctionne ! Les tests fonctionnels permet de montrer l’avancement du projet. Les livraisons régulières (on reste dans le principe de l’itération pour intégrer le client le plus possible au projet) également.
4. Le courage
J’aime beaucoup cette notion, parce qu’il soulève un problème que beaucoup de gens dans le monde du travail ont sûrement déjà rencontré. Si on a fait une bêtise, que faire ? Doit-on l’exprimer à voix haute au risque de se faire engueuler par ses supérieurs ? Ou doit-on la taire et tout faire en douce pour essayer de rectifier son erreur ? Ici, la valeur courage implique d’oser dire quand on a faire une erreur. Cela implique aussi que la réponse n’est jamais le blâme, mais la résolution à plusieurs et même une réunion post-résolution afin d’apprendre tous pour améliorer les conditions de code/travail afin de ne pas répéter la même erreur (ce qu’on appelle un post-mortem).
Le courage, c’est aussi savoir dire “non, je ne sais pas”, ou même “je me suis planté, le choix de techno n’était pas le bon, on doit recommencer”.
Ayant vécu dans une boîte où on ne m’a jamais accordé la moindre confiance, cela permet de découvrir une autre façon de travailler, bien plus saine au quotidien !
5. Le Respect
Cette dernière valeur pourrait couler de source, malheureusement, ce n’est pas intrinsèque partout. Il s’agit du respect de chacun mais aussi de soi. Il s’agit de respecter aussi le travail qui est fait, afin que chaque dev' recherchent toujours la qualité.
Il existe des pratiques qui renforcent ces 5 valeurs. Elles sont au nombre de 13.
(Et c’est là où on est très orienté tech).
Je ne vais pas entrer dans le détails de chacunes de ces pratiques, mais je vais en expliciter quelques-unes parce que ça me parait important :
Des tests, des tests, des tests :
Faire des tests permet de rendre son appli plus robuste. On le sait. Mais en pratique, couplé avec les 2 pratiques suivantes, permet de bosser sur un projet de façon plus sereine. Pourquoi ? Parce que les tests sont dans
Intégration continue :
On a fini de coder une fonctionnalité, on a fait les tests d’acceptance, end-to-end et/ou unitaires ? On va pouvoir l’implémenter dans le projet ! Puisque l’intégration fonctionne à partir du moment où les tests passent, on est plus zen à chaque nouveau merge !
Petites livraisons :
Là, c’est assez facile à comprendre. Livrer régulièrement permet de désacraliser la mise en prod. D’autant plus quand on a automatisé l’intégration et la validation des tests. C’est une chaîne logique de travail de développement. Une fonctionnalité est testée et codée. Les tests sont validés, donc l’intégration est validée. On peut livrer rapidement.
Un rythme soutenable :
Là aussi, ça paraît évident, mais un bon dev' est un dev' reposé. Ca implique aussi de se prévoir de la marge dans le travail qu’on a à faire. Parce que si un ticket (ou une user story) n’est pas faite, ce n’est pas dramatique, on a de la marge.
du Pair-programming :
On connaît tous et toutes cette méthode de travail. Apprécié des juniors (puisque ça permet de démarrer en douceur avec une personne toujours à disposition pour répondre aux questions), le pair-programming est une pratique fondamentale de l’XP. Il part du principe que deux cerveaux sont plus efficaces qu’un seul. Concrètement, le pair s’effectue de la manière suivante : Il y a un pilote, qui tient le clavier, le second va faire des suggestions, apporter son aide, etc. durant un temps limite (en général, 20 minutes), puis ils vont inverser les rôles. Tout comme la méthode Pomodoro, au bout de quelques échanges, il y a un temps de pause de 15 minutes pour s’aérer l’esprit et revenir l’esprit plus aiguisé.
Il existe aussi une autre façon de faire où celui/celle qui tient le clavier n’est qu’un exécutant (toute proportion gardée, il peut aussi allumer son cerveau, bien entendu) et le second va indiquer quoi faire, quoi écrire. Cette pratique existe aussi en mob-programming, le travail de programmation en équipe.
Voici les dernières pratiques, que je vais moins détailler, mais qui sont tout aussi importantes : une conception simple (qui rejoitn la valeur de simplicité), le remaniement du code, qui permet d’améliorer régulièrement la qualité du code, l'appropriation collective du code, puisque le pair est est une pratique courante, il est important de comprendre que le code n’est pas un travail solitaire, mais collectif, une utilisation de la métaphore, là c’est pour que les non dev' comprennent de quoi on parle (et ça, je suis très fan, je pratique beaucoup la métaphore !), des conventions de nommage, une pratique que j’espère courante dans le monde du dev', afin de pouvoir relire plus facilement le code d’un.e autre, ou son propre code plusieurs mois plus tard, enfin le planning poker qui détermine le temps nécessaire à la réalisation d’une fonctionnalité et le client sur site, qui permet d’impliquer le client du début à la fin du projet.
Pourquoi plus Scrum que XP ?
Et bien, pour des raison purement capitalistes oserais-je dire, puisque l’un des principes fondamentaux du manifeste Agile évoque une certaine souplesse dans l’accueil des changements demandés en cours de route.
Accueillez chaleureusement les changements de besoins, même tardifs dans le développement. Les processus agiles tirent parti du changement pour renforcer l’avantage concurrentiel du client.
L’un des 12 principes du manifeste Agile
Et cela n’est pas tombé dans l’oreille d’un sourd, puisque c’est ce qui ressort le plus souvent dans le Scrum, qui est essentiellement axé sur le principe de l’itération, afin d’avoir un contact plus régulier avec le client, et de pouvoir modifier des choses en cours de route, si besoin est.
l’XP n’est pourtant pas dénué d’intérêt, et est massivement pratiqué chez Pix.
L’une des raisons du manque d’intérêt pour XP réside surtout dans le fait que c’est principalement dédié au monde du développement informatique.
L’une des autres raisons, c’est que Kent Beck, l’auteur principal de cette méthode est un très mauvais communicant (on vous a dit que le terme “extreme programming” était un très mauvais choix ^^), et dans la 1ère version de son livre détaillant l’XP, il était très orienté dev' et assez méprisant envers les autres corps de métier autour du développement d’un projet d’application ou de logiciel. (Il écrivait que les métiers non tech étaient une source de perte d’argent)
Pourtant, ces principes et valeurs de l’XP sont hyper importants pour développer un environnement de travail sain et serein.
Alors, c’est quand que vous vous mettez à l’XP ?
Note : cet article a été rédigé avec l’aide de la conférence de Pascal Le Merrer sur le sujet et de Wikipedia.