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

Nous y sommes; nous avons rapidement revu ce qu’est le mode XP dans un précédent article (cf. « eXtreme Programming dans le monde réel (Partie 1) » ), et nous allons maintenant confronter la viabilité de ses valeurs et des ses commandements à la réalité des projets.

Les valeurs

1. Communication

Il faut bien comprendre qu’en mode XP, il n’existe pas nécessairement de cahier de spécifications fonctionnelles et/ou techniques qui sont la bible de référence du projet; en effet, puisque nous travaillons à périmètre variable, un tel cahier est par définition variable; dans la pratique, cela peut tout à fait se faire, mais — et cela va être un maître mot dans toute la mise en pratique de ce genre de fonctionnement — cela demande un peu de discipline. Prenons un exemple concret et très simple qui nous permettra de mieux saisir comment les choses peuvent être faites.

Nous travaillons sur un projet d’application de gestion de clientèle d’une société; nous avons déjà mis au point un cahier d’expression des besoins qui définit une base pour l’application;ainsi, nous savons que le logiciel à développer permettra d’enregistrer des nouveaux clients, de les éditer, de les consulter et/ou de les supprimer.

Un exemple tout à fait basique de différence entre le mode XP et un autre mode plus classique consiste à ne pas savoir, par avance, de quoi est constitué un client; disons, pour simplifier le problème, dans un premier temps, que les clients sont des personnes physiques. Sans avoir besoin de plus de détails, nous savons déjà, à minima, qu’un client aura un nom et un prénom, en plus d’un identifiant interne.

Une bonne communication avec notre client permettra de définir plus précisément, au fur et à mesure des développements, ce qui constitue un client. Dans la pratique, cela peut se faire oralement, par téléphone (ce qui est toujours une mauvaise idée si on en reste là), par échanges d’e-mail (c’est mieux, mais cela pose encore des problèmes en termes de « faire-savoir », pour parler comme un consultant) ou par l’utilisation d’un outil de référence; il existe de nombreux outils de gestion de projet qui permettent de gérer ces échanges qui, soyons clair, constituent le cahier de spécifications. Vous pouvez par exemple utiliser TRAC, qui est assez complet : il dispose d’un Wiki pour l’écriture des fonctionnalités et des documentations, d’un gestionnaire de tickets pour les échanges directs avec, par exemple, le client, d’un browser SVN pour la gestion du versioning, etc.

La mise en place d’un tel outil vous permet donc d’échanger avec votre client pour :

  • définir, dans notre exemple, ce qui va constituer un client (nom, prénom, date de naissance, sexe, adresse de livraison, de facturation, etc.);
  • faire savoir l’évolution de cette définition à toutes les personnes concernées par le projet via une interface commune (éventuellement avec des droits d’accès plus ou moins restreints).

Cet outil va également vous permettre de gérer les communications entre les différents membres de l’équipe projet; par exemple, si votre client détermine après trois mois de développements qu’en fait un client peut également être une société, vous savez bien que cela va impacter les développements d’ores et déjà réalisés (cf. l’article à ce sujet); votre équipe va alors pouvoir échanger (d’abord oralement, soyons réalistes) pour déterminer la meilleure manière de prendre en compte ces changements sans remettre en cause tout ce qui a déjà été fait, elle va prendre un certain nombre de décisions, et il est important :

  • que tous soient au courant de ces décisions et de leurs implications en terme de développement (modification des API, par exemple);
  • que le client soit au courant de l’impact en terme de fonctionnalités et/ou de délais de livraison.

Bilan — dans la pratique, la communication est une valeur qu’on peut respecter sans trahir l’esprit du mode XP.

2. Simplicité

Notre client va vouloir mettre en place un moteur de recherche permettant de retrouver un client donné. Lors d’une discussion avec lui, il était apparu qu’il souhaitait pouvoir, notamment, trouver tous les clients d’une ville donnée, par exemple.

Le problème que nous pose le respect de cette valeur, c’est le « par exemple », justement; nous pouvons sans difficulté réaliser une méthode qui permet, pour une ville donnée, de retrouver l’ensemble des clients de cette ville; par ailleurs, nous savons également que nous pouvons, sans trop de peine, réaliser une méthode qui permet ce genre de recherche de façon plus générique, sans connaître à l’avance le critère de recherche (recherche par nom, code postal, année de naissance, sexe, etc.).

Le mode XP est parfaitement clair : implémentez la recherche par ville. Dans la pratique, il est délicat d’en rester là, car :

  • le client ne sait pas toujours lui-même de quoi il a besoin;
  • il est essentiel, dans une relation client/prestataire que le prestataire soit proactif;
  • à ne faire que ce que le client demande stricto sensu, ce dernier va vite en avoir assez de devoir expliciter chacun de ses besoins et demander à faire rédiger un cahier de spécifications complet et détaillé.

Deux solutions jointes permettent de résoudre le problème :

  • le premier est le respect de la valeur communication : il faut sensibiliser immédiatement le client sur le fait de savoir plus précisément ce que saura faire le moteur de recherche de clients;
  • il faut proposer au client une solution plus globale mais qui reste dans le cadre de ce que j’appelle les « fonctionnalités utiles de même catégorie ».

Concernant les « fonctionnalités utiles de même catégorie », ne cherchez pas sur wikipedia, vous ne l’y trouverez pas, c’est un genre de néologisme. L’idée est double :

  • fonctionnalités utiles : inutile de proposer au client un moteur de recherche permettant de retrouver les clients dont le prénom contient deux fois la lettre « A »; il est essentiel pour cela d’avoir une bonne vision de ce que fait le client, et ce n’est pas toujours aussi simple qu’il n’y paraît;
  • même catégorie : dans notre exemple, rechercher un client par ville, par code postal ou par nom représente le même genre de computation; une fonctionnalité utile qui serait d’une autre catégorie serait par exemple de rechercher les clients ayant au moins passé une commande au cours des derniers 90 jours.

Du coup, vous allez faire trois choses :

  1. réaliser le moteur de recherche un peu plus large;
  2. l’implémenter, dans le cadre du respect de la valeur simplicité, uniquement sur les fonctionnalités définies par le client (en l’occurrence la ville);
  3. proposer, dans un cadre plus commercial, des fonctionnalités utiles plus complexes (d’autres catégories)  que vous ne réaliserez que s’il le souhaite.

Bilan — dans la pratique, la simplicité est une valeur qu’il est possible de respecter, mais il faut toujours veiller à l’intérêt du projet et à l’intérêt (et la vision) du client.

Note : veillez également à bien cadrer votre client; il est fréquent de voir un client qui veut d’abord réaliser un logiciel de gestion de clients de banque, puis qui explique qu’en élargissant un tout petit peu on peut aussi gérer les assurances, puis qu’en élargissant encore un peu on peut gérer tout type de domaines, et qui se retrouve à vous demander de redévelopper SAP — ça peut être une bonne idée, mais commencez par les clients des banques; ensuite seulement gérez les assurances; et ensuite, vous verrez. Ne perdez pas de vue que vous devez livrer régulièrement.

3. Feedback

A partir de là, on va aller plus vite, car on va commencer à enfoncer quelques portes ouvertes et à faire de la redite.

Concernant le feedback, l’idée est assez simple : on doit, à tout moment, savoir ce qui marche et ce qui ne marche pas; plus précisément, chaque livraison doit être assortie d’une batterie de tests unitaires et de tests fonctionnels et avoir passé avec succès tous ces tests. Dans la réalité, il arrivera que certains tests échouent et il est nécessaire de transmettre correctement l’information pour pouvoir effectuer les corrections conséquentes.

Aujourd’hui, la plupart des langages de programmation proposent des outils de tests unitaires relativement complets et qui permettent une implémentation rapide de ceux-ci, même s’il y aura toujours un peu de code à écrire (et heureusement, c’est ce qui fait de nous des auteurs); le plus compliqué est de réaliser une batterie correcte de tests fonctionnels, et ce au moins pour deux raisons :

  • c’est le client qui va définir les scénarios dont vont découler ces tests (et il arrivera, vous verrez, que le client n’ait pas franchement de temps à consacrer à cela et vous envoie un stagiaire plein de bonne volonté mais ignorant du contexte);
  • les nouvelles fonctionnalités peuvent impacter les scénarios existants (ce qui n’est quasiment pas le cas avec les tests unitaires : une modification fondamentale de ce qu’est une commande du point de vue de l’application ne changera quasiment rien aux tests unitaires concernant les clients — sauf pour leurs commandes).

De mon expérience, il est assez aisé de mettre en place une batterie de tests unitaires à chaque livraison, mais les tests fonctionnels demandent une vraie discipline côté client, car c’est lui qui doit :

  • écrire les scénarios de tests
  • vérifier que ces scénarios couvrent tous les cas à tester (nous l’y aidons, mais ça reste son métier).

Bilan — la valeur feedback peut très vite devenir pain in the *ss si on n’a pas le client qui va bien derrière, mais testez au moins unitairement : cela ne coûte pas cher, et ça donne une base saine de travail, notamment quand les équipes de développement commencent à être grandes.

4. Courage

Il en faut, du courage, pour remettre à l’ouvrage trois mois de boulot en disant qu’on a effectué des mauvais choix (ou simplement qu’on avait effectué des bons choix dans le contexte de l’époque, mais que le contexte actuel est différent). Après, il ne faut pas confondre courage et inconscience. On parle bien d’un projet professionnel, avec un client derrière qui paye et qui attend, et il attend de nous un travail de qualité dans lequel il peut avoir confiance. Je vai distinguer trois cas représentatifs de ce que peut être la valeur courage :

  • le client a changé d’avis sur ce que doit être le projet : un ensemble de développements est remis en cause par le fait que le client en modifie le comportement;
  • l’équipe a changé d’avis sur ce que doit être l’implémentation : un ensemble de développements est remis en cause par le fait que l’équipe en modifie le fonctionnement (ou les API, ce qui impacte d’autres développements);
  • le contexte a changé : un ensemble de développements est remis en cause.

La frontière entre le courage et l’inconscience, en l’occurrence, n’est fine que dans des cas assez rares (mais soyons clair, d’expérience, ces cas se présenterons au moins une fois dans quasiment tous vos projets) : les cas simples sans trop d’impact sont fréquents mais ne demandent aucun courage; les cas remettant l’intégralité du projet en cause sont extrêmement rares et relèvent souvent de l’inconscience (sauf à pouvoir justifier d’une telle situation, d’expérience, on est dans un cas où il faut réfléchir à laisser tout bonnement tomber le projet — il est contre-productif de travailler avec un client qui veut une application différente chaque fois qu’il fait un mauvais rêve); un bon exemple peut être l’exemple cité plus haut des clients qui se retrouvent pouvoir être des personnes morales; cela implique un paquet de modifications :

  • toutes les représentations des clients dans l’application;
  • les interfaces de gestion des clients (consultation, édition, création);
  • des fonctionnalités ne sont plus toujours disponibles (par exemple, souhaitez un bon anniversaire au client le jour concerné) tandis que d’autres sont créées (recherche par chiffre d’affaires).

Vous devrez effectuer ces modifications, il vous faudra parfois du courage pour cela, mais vous devrez bien penser à évaluer ce que ces modifications vont représenter pour vos développements, et commencer par modifier tous vos tests (unitaires et fonctionnels) de façon ad hoc, et déterminer le meilleur moyen de modifier vos développements pour continuer à livrer régulièrement et ne pas partir dans des chantiers qui ne trouveront d’issue que très longtemps après. Une remise en cause d’une partie du dev ne doit pas remettre en cause le projet lui-même (sinon, c’est le signe qu’il y a un problème de fond avec le projet).

Bilan — soyez courageux, c’est toujours bien, mais n’oubliez pas que vous réalisez un projet professionnel que vous ne devez pas remettre en cause; par ailleurs, laissez vos équipes être courageuses, mais rappelez-vous bien que vous en êtes responsables.

5. Respect

Je n’ai pas de commentaire particulier à formuler sur cette valeur, si ce n’est qu’à ce compte là, on peut en ajouter d’autres : politesse entre les membres de l’équipe et avec le client, ponctualité aux rendez-vous, brossez-vous bien les dents au moins après chaque repas (et prévenez le retour de la plaque dentaire), ne permettez pas à un membre de votre équipe de facturer très cher la réalisation d’une présentation PowerPoint qui utilise la police « Comic Sans MS » ou des clipart animés, regardez bien à gauche, puis à droite, puis encore à gauche avant de traverser la route (inversez pour la Grande-Bretagne), ne laissez pas des gens dont ce n’est visiblement pas le métier vous imposer des valeurs ridicules dans vos modes de développements, etc.

Bilan — What the f*ck ?

Les commentaires sont fermés.