eXtreme Programming dans le monde réel (Partie 1)

Inutile de rejouer le film depuis le début avec résumé des épisodes précédents, je vous fais rapidement le pitch; il y a quelques années, un groupe de personnes telles que des architectes logiciels, des développeurs, des ingénieurs, etc. ont mis au point une méthode de développement sensée être bien mieux adaptée aux projets logiciels modernes que les autres, et l’ont appelée eXtreme Programming (ou XP si affinités). La question du jour — qui sera vraisemblablement traitée sur plusieurs articles, tant le sujet est copieux — est de savoir dans quelle mesure cette méthodes est implémentable dans la vraie réalité réelle du monde d’aujourd’hui. Est-il réellement possible de réaliser des projets en mode XP ? Si non, quel est le plus grand sous-ensemble des règles édictées par le mode XP qui puisse réellement être implémenté ?

XP — Rappel des faits

L’équation du projet

L’idée de base sous-jacente à l’eXtreme Programming est qu’un projet peut être résumé sous la forme de l’équation suivante :

Qc . Np = Pf . Px

où :

  • Qc : la qualité du code réalisé;
  • Np : le nombre de personnes consacrées au projet;
  • Pf : le périmètre fonctionnel du projet;
  • Px : le prix (ou le coût, ça dépend des écoles — je préfère l’idée de coût, plus objective, qui n’intègre pas de notion de marge commerciale) du projet.

Dans cette optique, on comprend bien ce qui permet de déterminer l’égalité ci-dessus, partant notamment des assertions suivantes régulièrement vérifiées (entre autres) :

  • mon client veut plus de fonctionnalités sans payer plus — avec les mêmes ressources sur le projet, la qualité va s’en ressentir;
  • je pense que ce projet, pour le niveau de qualité fixé par le client, va nécessiter plus de jours/homme qu’initialement prévu — le coût du projet va augmenter;
  • mon client a fixé son budget avant même que je fasse un devis — si on veut un minimum de qualité de code, il va sans doute falloir réduire le périmètre des fonctionnalités;
  • mon client a tout simplement changé d’avis sur une fonctionnalité, et il faut maintenant redévelopper une partie de l’application;
  • etc.

En bref, de ces observations, nos charmants coreligionnaires ont défini comme dogme XP l’hypothèse suivante :

mettons-nous d’accord avec le client uniquement sur
le niveau de qualité du code exigé et le nombre de personnes à affecter au projet

Un certain nombre de contraintes découlent directement de ce dogme, dont le plus important est le suivant (il est en fait si important qu’il en est quasiment le corollaire) :

puisque le client accepte de ne définir ni le périmètre ni le budget,
nous devons lui offrir la possibilité de clôturer le projet quand bon lui semble.

Cela se traduit, dans les préceptes XP, par un certain nombre de règles, dont les plus pertinentes sont sans doute :

  • code en livraison constante;
  • tests unitaires avant chaque livraison;
  • communication constante avec le client.

Ainsi, ce dernier connaît, au jour le jour, l’état du périmètre de l’application et peut contrôler au mieux l’adéquation entre son budget et les fonctionnalités.

XP n’aime pas se confronter à la réalité

Il existe une batterie de projets types propices au développement XP, et c’est sans aucun doute une méthode très efficace, lorsque tout le monde joue le jeu. Malheureusement, les réalités du métier étant ce qu’elles sont, la méthode est souvent confrontée à la réalité :

  • le client a un budget, c’est souvent une réalité;
  • de ce fait, il a besoin d’un minimum de garantie quant à ce qu’il pourra obtenir dans le respect de son budget;
  • etc.

Alors dans quelle mesure peut-on réellement développer un projet complet en mode XP ? Pour être parfaitement clair sur mes intentions, j’indique dès à présent au lecteur averti que je ne m’intéresserai pas ici au cas particulier de l’édition logicielle ( c’est à dire du développement complet d’un logiciel sans client en face), mais uniquement au développement d’une application, pour un client, dans le cadre d’une prestation informatique.

Les valeurs et commandements de l’eXtreme Programming

Afin de définir précisément ce qu’on peut faire ou ne pas faire en XP, voici sommairement la liste des cinq valeurs et treize commandements XP :

Valeurs :

  1. Communication — l’équipe projet et le client doivent constamment communiquer;
  2. Simplicité — la façon la plus simple d’obtenir le résultat est la meilleure, et on ne doit pas anticiper des éventuelles extensions futures;
  3. Feedback — le retour d’information est primordial pour tous; c’est une valeur proche de la valeur communication, mais elle diffère par sa mise en oeuvre qui s’articule autour des tests unitaires côté équipe projet et des tests fonctionnels côté client;
  4. Courage — on attaque le grandiloquent; cela signifie qu’on n’a pas peur de remettre tout ce qu’on a déjà fait en question si on l’estime nécessaire;
  5. Respect — cette valeur a été rajoutée ultérieurement (probablement par un consultant ;) ).

De ces valeurs découlent treize commandements à respecter :

  1. Client sur site — un représentant du client, dûment mandaté comme interlocuteur unique, et tout à fait compétent sur le projet, doit être disponible auprès de l’équipe de développement à tout instant, pour améliorer le workflow de communication;
  2. Jeu du planning — le client crée des scénarios pour les fonctionnalités qu’il souhaite obtenir, puis les classes par priorité décroissante; l’équipe projet peut alors estimer le temps de chaque fonctionnalité et en commencer l’implémentation;
  3. Intégration continue — lorsqu’une tâche est terminée, on fait tourner l’intégralité des tests pour vérifier que la tâche est correctement implémentée ET qu’il n’y a aucune régression; si tel est le cas, les modifications sont immédiatement intégrées au produit complet;
  4. Petites livraisons — on livre le plus fréquemment possible;
  5. Rythme soutenable — l’équipe ne fait pas d’heures supplémentaires (laissez-moi rire), car la qualité du code produit par un développeur est inversément proportionnel à sa fatigue;
  6. Tests fonctionnels — à partir des scénarios fournis par le client, l’équipe crée des procédures de tests permettant de valider si ces scénarios sont respectés ou non, puis l’équipe crée le code nécessaire à la validation de ces tests;
  7. Tests unitaires — le code implémenté doit se comporter comme prévu, même à des niveaux de fonctionnalités en-deça des attentes du client (par ex : le code permettant la connexion à une base de données est rarement défini par le client);
  8. Conception simple — on s’en tient aux scénarios du client, on n’anticipe pas ses prochaines demandes;
  9. Utilisation de métaphores — on décrit le système via des métaphores pour permettre à chacun, quelle que soit sa spécialité, de parles des mêmes choses avec les mêmes noms;
  10. Refactoring — On améliore constamment son code; par exemple, une fonction identique ne doit pas être réécrite deux fois dans le code;
  11. Appropriation collective du code — l’équipe est collectivement responsable du code, et chaque développeur peut coder sur l’ensemble de l’application, y compris des parties qu’il n’a pas écrites;
  12. Convention de nommage — puisque tout le monde peut tout faire, il est essentiel d’avoir une nomenclature commune, et d’être discipliné ;
  13. Programmation en binôme — tout à fait : un ordinateur = deux développeurs (un pilote et un copilote); l’un (le pilote) écrit du code tandis que l’autre (le copilote) vérifie le code écrit, suggère des algorithmes alternatifs, des optimisations, des questions, etc.; ces deux rôles changent régulièrement, et les binômes eux-mêmes doivent changer régulièrement (pour promouvoir, notamment, la communication entre les uns et les autres sur un même projet).

Si vous en avez besoin, prenez un paracétamol, on en vient au vif du sujet; croyez-moi si vous le voulez, ceci n’était que le rappel des faits.

Le prochain article traitera de ce qu’il est possible ou non de mettre en oeuvre dans la réalité quotidienne des projets.

Lire la suite

Les commentaires sont fermés.