Extreme programming (XP)

Proposé par Kent Beck en 1996, la méthode eXtreme Programming est une des implémentations les plus connues et fidèles de l'agilité, spécialisée dans le domaine de l'ingénierie logicielle.

Description rapide

Extreme programming (que l’on abrège souvent XP) est une méthode agile pour la gestion de projet de développement logiciel.

La méthode se focalise principalement sur la démarche pour créer du logiciel de qualité, en s’appuyant sur un certain nombre de bonnes pratiques (best practices) en ce sens.

Elle met l’accent sur le fait d’atteindre les objectifs, plutôt que sur les activités menées pour le faire.

Principales valeurs de XP

XP se fonde sur 5 principes, ou valeurs. Toute l’approche découlera de ces valeurs, que vous devez rapprocher assez naturellement des principes vus précédemment dans le manifeste agile :

  • La simplicité : éviter de perdre son temps à faire des choses inutiles et réduire toute complexité inutile dans les solutions créées.
  • Le feedback : obtenir des retours aussi rapides que réguliers de la part du client, pour s’améliorer et améliorer le produit.
  • La communication : faire en sorte que l’équipe travaille ensemble, échange, partage (notamment par le biais de daily stand-up meetings).
  • Le courage : être capable de tout partager et tout montrer… même son code source (!), et plus généralement ne pas avoir peur de prendre part au travail de l’équipe (proposer des choses, même si on n’est pas sûr de son coup).
  • Le respet : travailler ensemble de manière constructive passe par un respect mutuel des membres de l’équipe.

Rôles définis par XP

Comme la grande majorité des méthodes et frameworks que nous verrons dans cette formation agile, eXtreme Programming défini des rôles, donc une sorte de structure de gouvernance des projets agiles. Quatre rôles essentiels sont définis :

Le coach XP

Le coach XP est en quelques sorte le leader de l’équipe, le mentor.

À l’image du scrum master dans une équipe Scrum, c’est lui qui s’assure que la démarche XP est correctement implémentée, et que la méthode fonctionne comme il se doit dans le cadre du projet.

Il n’est pas le « n+1 » des développeurs : il est le facilitateur de l’équipe, un leader qui insuffle une dynamique et qui fait en sorte que les embûches qui se dressent sur le passage de l’équipe soient éliminées.

Le développeur

Le développeur (ou programmeur) est un membre de l’équipe, qui construit littéralement la solution.

Il produit notamment le code source, ainsi que des tests de ce code.

Le testeur

Le testeur aide l’équipe à produire un produit de la meilleure qualité possible. Il participe notamment à la production des tests d’acceptance (acceptance test), en collaboration avec le client, et exécute les tests.

Bon nombre de ces tests doivent être automatisés, par soucis d’optimisation du ROI de la démarche de test et recette.

Remarquez que ce rôle est parfois joué par les développeurs eux mêmes (notamment sur des projets dont les moyens ne permettent pas d’avoir des testeurs attitrés).

Le client

Le « client » (customer) est le représentant des utilisateurs, qui définit quelles fonctionnalités (features) doivent être intégrées au produit développé.

Il a également la (lourde) charge de définir les priorités du projet (tout comme le product owner dans la démarche Scrum), à savoir dans quelle ordre ces fonctionnalités doivent être créées et livrées.

Enfin, c’est lui qui a la responsabilité de valider la recette des features et du produit final.

Principales caractéristiques de XP

XP préconise un certain nombre de pratiques permettant de mettre en œuvre les valeurs énoncées plus haut.

Extreme programming XP

Conception simplifiée

Les choses les plus simples sont souvent les plus efficaces !

Les développeurs XP sont encourager à se poser continuellement la question suivante : « Quelle serait la manière la plus simple (mais fonctionnelle) de faire répondre à cette demande/problème ? ».

Un bon développeur est un développeur qui trouve des solutions simples à des problèmes simples. Un excellent développeur est un développeur qui trouve des solutions simples à des problèmes compliqués.

Pair programming

Le pair programming est une pratique fondamentale d’XP.

Ainsi, deux développeurs travaillent ensemble : l’un écrit le code, l’autre regarde, propose, corrige, commente. Et on change les rôles…

Les connaissances sont ainsi partagées, et les idées émanent plus facilement de ce type d’organisation. Quand Hervé, le créateur du module de gestion des stocks, est malade, Jean-Claude est capable d’intervenir dessus… puisqu’il connaît le code pour avoir assisté à son écriture !

Responsabilité commune

Les équipes XP sont considérées comme un tout unique et indissociable.

Les membres sont regroupé dans la même pièce, travaillent ensemble, et assument les succès et les échecs collectivement. Il n’y a pas de spécialistes attitrés qui défendent leur pré carré : tout le monde peut tout faire, en fonction de ses affinités et de ses compétentes.

Le code appartient à toute l’équipe !

C’est un principe important d’XP : le code n’est pas celui d’un développeur, personne n’est propriétaire unique d’une portion de code.

Au contraire, n’importe quelle paire de programmeurs peut s’intéresser à une portion de code existante, l’éprouver, la tester, l’améliorer, etc. Le but est que toute l’équipe connaisse le code, et que toutes les bonnes idées soient considérées.

Remarque – Notez que ceci est d’autant plus vrai que la responsabilité est partagée (cf. point du dessus) : plutôt que de prendre cher à cause d’une erreur faite par un autre, le programmeur préférera naturellement la corriger lui même au lieu de se défausser de la responsabilité.

Utilisation de standards de développement

C’est une nécessité, notamment impliquée par le fait que tout le monde peut toucher au code !

Une organisation stricte, respectant des standards (façon de documenter, d’écrire le code, patterns utilisés, etc.) et des bonnes pratiques, doit être mise en œuvre pour faire en sorte que les choses soient compréhensibles aisément par tous.

TDD : développement dirigé par les tests

XP accorde une importance critique au test, et pour cause : pas de code robuste sans tests.

En outre, il recommande une pratique systématique du TDD : on écrit les tests avant le code !

Refactoring

Au fur et à mesure de l’avancement d’un projet et du cycle de vie d’un produit, certaines parties du code deviennent caduques, non conformes aux standards qui évoluent, etc.

XP insiste sur le fait qu’il faut conserver une base de code la plus propre et à jour possible : les développeurs sont encouragés à pratiquer le refactoring, c’est à dire améliorer le design et l’implémentation des parties qui le nécessitent, le plus tôt possible.

Intégration continue

À chaque fois que du code est « comité » (livré par un développeur sur le système de gestion de versions du projet), voire à intervalles réguliers (chaque nuit par exemple), ce code est intégré.

Autrement dit, un certain nombre d’opérations sont automatiquement réalisées (exécution de tests notamment), afin de vérifier que le nouveau code cohabite correctement avec le reste de la base de code. Ceci permet de détecter très tôt, avant le déploiement, des erreurs éventuelles.

On automatise souvent cette pratique, à l’aide de serveurs d’intégration continue (souvent appelés serveurs CI) : Jenkins, Bamboo, Apache Continuum

Jeux de planning

Les jeux de planning sont utilisés pour planifier les itérations et les releases.

Au début de chaque itération, après que le client ait listé les fonctionnalités à intégrer à l’itération, l’équipe utilise notamment le planning poker pour estimer l’effort nécessaire pour les mettre en œuvre.

Petites releases fréquentes

Conformément au principe « Livrez fréquemment un logiciel opérationnel » du manifeste agile, XP recommande de livre souvent de petits lots fonctionnels bien testés et présentés au client pour obtenir son retour.

Tests d’acceptance client

Les tests ne sont pas seulement l’affaire de l’équipe de développement !

Pour la bonne réussite du projet, le client lui même, ou son représentant, doit être impliquée dans la rédaction des cas de test (how to demo ?). Ainsi, ce qui sera livré sera conforme aux attentes réelles.

Rythme raisonnable

XP part du principe que coder 24h/24 n’est pas une bonne solution pour produire du logiciel vraiment performant.

Même s’il peut y avoir des « coups de bourre », les cycles de développement doivent être fondés sur un rythme soutenable pour l’équipe. Cela implique donc, par exemple, un recours exceptionnel aux heures supplémentaires.

Utilisation de métaphores

Les équipes XP utilisent des métaphores pour se représenter le fonctionnement d’un système ou d’un logiciel.

On utilise pour cela un vocabulaire simple et compris par tous, faisant référence à des situations que tout le monde a l’habitude de rencontrer. Ex. : un système d’authentification peut être comparé à un gardien d’entrée d’une pièce sécurisée…

Testez-vous !

Vous êtes développeur dans une équipe XP. Que faites-vous avant d’implémenter une fonctionnalité ?
  • J’écris les tests
  • J’installe la dernière version de PHP
  • Je prends un café
  • J’écris et je lance les tests
XP recommande le TDD. Souvenez-vous de la démarche TDD : j’écris les tests, je lance les tests et constate qu’ils échouent, je code la fonctionnalité, je relance les tests et constate qu’ils sont au vert.
Qu’est-ce qu’un excellent développeur agile ?
  • Répond aux problèmes compliqués par une solution compliquée
  • Répond aux problèmes compliqués par une solution simple
  • Répond aux problèmes simples par une solution compliquée
  • Ne répond pas aux problèmes
  • Laisse les autres faire quand il ne sait pas

Commentaires