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

Bon, on avance… Lors du premier épisode, on a rappelé succintement de quoi il s’agit; lors du second, on a déterminé comment confronté les valeurs à la réalité des projets informatiques; il nous reste maintenant à déterminer ce qu’il en est des commandements, et on pourra enfin imaginer ce qu’est un mode XP « dégradé » acceptable dans le monde réel.

Les commandements

1. Client sur site

Je vous invite à rire un bon coup concernant celui-là, c’est amplement justifié. D’expérience, le seul cas qui pourrait toucher du doigt ce commandement n’est pas tant d’avoir votre client sur site que de travailler sur le site de votre client (et soyons clair, cela arrive fréquemment). Les préconisations XP indiquent cependant que cet interlocuteur privilégié doit remplir un certain nombre de critères :

  • avoir une connaissance solide du sujet;
  • avoir un pouvoir de décision suffisant pour faire des choix (qui sont nombreux, en mode XP);
  • être tout le temps disponible pour le projet (plus précisément, être tout le temps affecté au projet).

Du coup, cela signifie que votre client ne peut pas vous fourguer gentiment un stagiaire (j’en ai vus…) ou un administrateur système/réseau (quelque compétent soit-il).

Imaginez un instant que vous êtes en train de développer une solution CRM (gestion de la relation client) avec votre équipe de développement; cela vaudrait le coup de vendre (cher) des billets pour assister à la réunion au cours de laquelle vous allez demander à ce que, au choix, le directeur des opérations ou le directeur commercial de votre client soit affecté à plein temps à votre service.

Du coup, maintenant qu’on s’est bien moqué, et même si je reconnais que l’intention est fabuleuse, comment fait-on ? Voici mes préconisations en la matière, elles ne sont pas parfaites, mais elles sont suffisamment efficaces et raisonnables :

  • un seul interlocuteur côté client (charge à lui de gérer les désaccords côté client);
  • cet interlocuteur est directement affecté par le projet (pas d’assistante de direction qui n’est pas trop chargée);
  • cet interlocuteur est un salarié de la société clients (pas de stagiaire, pas de consultant externe, surtout PAS de conflit d’intérêt);
  • cet interlocuteur a tout pouvoir de décision concernant le projet (au moins dans des délais raisonnables pour les cas extrêmes);
  • cet interlocuteur a un niveau de disponibilité établi pour le projet (plusieurs formes possibles : tous les matins, tous les lundis, un jour sur deux, à la demande, etc.).

2. Jeu du planning

Votre client doit comprendre — c’est vrai quel que soit le mode de développement, mais c’est indispensable en mode XP — que c’est à lui de faire le boulot; j’ai souvent rencontré des clients qui nous disent : « j’ai besoin d’une application de gestion de clientèle » et qui en restent là ! Soyons clair, c’est notre travail de poser les bonnes questions, de proposer des solutions techniques et fonctionnelles, mais c’est au client de répondre précisément – et rapidement – à ces questions, et c’est à lui de valider que ce qu’on lui propose correspond bien à ses besoins. Un exemple très frappant, et très courant, qu’on peut donner pour illustrer ce point est l’exemple du site internet institutionnel d’une société; si vous en avez déjà réalisé un, vous savez de quoi je parle; le client qui vous demande de réaliser son site internet ne réalise lui-même en général pas qu’il va lui incomber de nous fournir du contenu — il croit sincèrement qu’on va écrire le contenu présentant sa boite; de plus, souvent, lorsqu’il va finalement réaliser son erreur, il va affecter un stagiaire à cette fin (grave erreur). Il ne faut jamais hésiter à expliquer au client, avec des mots choisis, qu’il est en train de déconner sévère et qu’il ne peut pas compter faire des choses sérieuses sans que ça lui coûte un peu de temps (et d’argent, mais c’est une autre histoire).

Mes préconisations, sur le jeu du planning, sont simples : AUCUNE CONCESSION.

Votre client doit vous fournir, éventuellement avec votre aide, des scénarios de ce que l’application devra faire et ne pas faire — ce sera votre plan de chantier.

3. Intégration continue

Dans 98% des cas, je suis d’accord et je considère que cela ne pose pas de problème particulier. Les 2% des cas restant entrent dans les catégories suivantes :

  • première livraison : selon le contexte, il est possible qu’il faille un minimum de développements avant de pouvoir réaliser la première livraison;
  • fonctionnalité complexe : selon le contexte, il peut y avoir un intérêt d’attendre qu’une fonctionnalité complexe soit complètement réalisée pour la livrer; attention, toutefois, cela comporte un certain niveau de risque en terme de maintenabilité.

Pour information, la meilleure façon d’assurer une livraison continue consiste à versionner son code (de toute façon, je suis bien incapable de dire comment coder à plusieurs sans faire tourner un repository Subversion); pour info, et tant qu’on y est, on ne commit que des parties livrables, et ce pour plusieurs raisons :

  • d’abord, d’autres vont updater et récupérer votre code, donc si c’est incomplet, vous allez bloquer le boulot d’autres personnes;
  • les petites livraisons (dont on va parler après) sont faites par un export ou un checkout sur le repository; vous n’allez pas pourrir l’environnement de tests avec du code qui ne tourne pas.

Conclusion : on code, on teste sur son poste, on valide, et on intègre.

4. Petites livraisons

Cf. le paragraphe précédent; j’en profite simplement pour rajouter la règle d’or concernant le versioning : on update, et ENSUITE on commit; vous éviterez de vous fâcher avec votre client ou, pire, vos collègues.

5. Rythme soutenable

Le rythme de développement est quelque chose de très subjectif; pour ma part, une bonne journée de travail commence à 9h30 et se finit à 4h le lendemain matin; mais d’un autre côté, j’essaie toujours de dormir jusqu’à 11h — vous saisissez le paradoxe ? L’essentiel n’est pas tant le nombre d’heures travaillées.

Ce qui est essentiel, en terme de code, c’est, toujours selon moi, la concordance des points suivants :

  • tenir ses délais (je dis bien « ses » délais, et pas les délais des autres — ne promettez pas la lune, elle n’est plus à vendre ! Lorsque vous vous engagez sur une date, réfléchissez AVANT de vous engager, et tenez vos engagements ensuite); des délais raisonnables sont essentiels pour un bon rythme : trop courts et vous ne dormez plus, trop longs et vous êtres en vacances;
  • se rappeler qu’on est une équipe (lorsqu’on en est une); il y a deux aspects : aider vos potes qui sont à la ramasse, et ne pas planter le boulot de vos potes parce que vous êtes complètement dans le mur en termes de planning.

Bilan : bossez normalement, bossez dur, bossez bien.

6. Tests fonctionnels

Si déjà vous poussez votre client à jouer le jeu du planning, la moindre des choses est de valider que ce qu’il demande est pris en compte. Il existe aujourd’hui de nombreuses méthodes pour automatiser les tests fonctionnels; utilisez-les mais ne leur accordez qu’une confiance limitée. Rien ne remplace un utilisateur lambda (vraiment lambda) pour ce qui est de générer une erreur absolument improbable.

Conclusion : faites des tests fonctionnels pour chaque livraison : automatisez ce qui peut l’être et prenez des stagiaires pour trouver la petite bête.

7. Tests unitaires

Sur cette partie, il faut être intraitable; il est de votre responsabilité (de votre seule responsabilité) que le code que vous produisez se comporte comme il est censé se comporter selon vous. Il arrivera que vous ne vous compreniez pas avec votre client, et que la fonctionnalité développée ne soit pas ce qu’il attendait, mais lorsque vous créez une fonction de connexion à une base de données, vous devez garantir qu’elle se connectera à une base de données ou qu’elle renverra, le cas échéant, des erreurs que vous avez déjà prévues.

De plus, pour ceux qui ont commencé à coder avant la fin des années 70 du dernier millénaire, nous développons des architectures orientées objets, ce qui signifie : encapsulation, modularité, etc.

Du coup, les tests unitaires sont les meilleures garanties pour valider le fonctionnement de chaque brique, unitairement (ah, c’est pour ça qu’on appelle ça comme ça !!), dans l’ensemble qu’est votre gros bouzin.

Conclusion : soyez un dictateur concernant les tests unitaires — une batterie avant chaque update et avant chaque commit (si la première passe et pas la seconde, votre code plante — dans le cas contraire, du code commité plante, et par plante, je veux dire que le code est mauvais ou que l’intégration avec le reste est mauvaise).

8. Conception simple

Je ne vais pas revenir là-dessus; si le client vous demande un programme qui fait décoller un avion, ne cherchez pas à distribuer des cacahuètes aux passagers, ce n’est pas votre boulot.

9. Utilisation de métaphores

Cette partie est essentielle : nous travaillons dans des environnements complexes, avec un champ sémantique (un vocabulaire) qui nous est propre, et nous discutons la plupart du temps — si on peut appeler ça discuter — avec des clients qui, non seulement ne comprennent rien à ce qu’on fait, non seulement s’en foutent comme de l’an quarante (que diable s’est-il passé en l’an 40 ?), mais en plus attendent de nous qu’on comprenne et qu’on s’intéresse à ce qu’ils font.

Développez, par projet, un langage commun, une nomenclature commune, tant avec votre équipe qu’avec votre client; faites preuve d’imagination (il en faut) pour expliquer des problèmes techniques ardus — soyez imaginatifs, mais soyez précis ! J’invite les lecteurs architectes à nous faire part, en commentaire, de leurs plus belles métaphores en la matière.

10. Refactoring

La plupart des IDE vous simplifient ce problème; soyez très attentifs à rester des feignasses rigoureuses (cf. l’article « Pourquoi chercher à ne pas réinventer la roue ?« ) et à toujours tout refactoriser, mais tout en conservant le sens de l’architecture (ne créez pas de classes ad hoc si elles ne correspondent à aucune réalité).

11. Appropriation collective du code

Ouais, ouais, on est une grande famille et tout et tout…Soyez rigoureux, documentez votre code, utilisez la même nomenclature que vos petits copains, et faites du code lisible; je répète : LI-SI-BLE !

12. Convention de nommage

A priori, les types qui ont inventé les 13 commandements étaient prêts à tout pour arriver à 13.

13. Programmation en binôme

Ils étaient même prêt à ça ?!! Si l’idée n’est pas débile, sa mise en oeuvre, en revanche…

Oh, les gars ! on a résolu le problème du chômage : deux types derrière chaque ordinateur…

L’idée du binôme est sans doute à creuser, mais n’espérez pas vendre à vos clients l’idée d’un pilote et d’un copilote derrière chaque machine, c’est impensable. Organisez des binômes pour que les tests de son propre code soient réalisés par d’autres, pourquoi pas ! Imaginer que des parties de programme ne sont jamais intégralement développées par une seule personne, c’est un vrai plus…mais un binôme devant chaque clavier…

Conclusion

Bon, on a fait le tour des valeurs, des commandements; le prochain article sera de fait beaucoup plus court, puisqu’il synthétisera ce qui, selon moi, est une version dégradée acceptable du mode eXtreme Programming, ce qui clôturera ce dossier. Et les vaches seront bien gardées.

3 réponses à to “eXtreme Programming dans le monde réel (Partie 3)”

  • GreG:

    « je suis bien incapable de dire comment coder à plusieurs sans faire tourner un repository Subversion »

    Tu t’es pas encore mis à la gestion de version décentralisée? C’est con tu vas adorer. Tiens ça pourrai me faire un sujet de contribution à ton blog…

  • Après quelques recherches (j’avoue que je n’avais jamais entendu parlé de gestion de version décentralisée), j’avoue que j’aimerais bien, en effet, que tu nous fasses un topo sur le sujet. Ça m’a tout l’air d’être un immense et joyeux bordel à gérer (j’adore !).

    Comme tu le sais, (toutes) les portes de ce blog te sont grandes ouvertes…

  • Gg:

    Pour la programmation en binôme il est clair que cela est difficilement soutenable.
    Cependant, pour de la programmation d’algorithmes un peu sérieux et volumineux je pense que c’est tout à fait indiqué de façon interne. Chercher une erreur d’inattention ou de mauvaise compréhension de l’algorithme dans des milliers de lignes de code peut prendre un temps considérable. Ainsi dans ce cas précis, le partenaire peut vérifier à la volée que ce qui est fait est juste en vérifiant les spécifications et le pseudo code préalablement établis. De plus, cela fait gagner beaucoup de temps parce que dès que l’un butte ou a un coup de barre l’autre peut prendre le relais. Je prends en exemple mes cours d’introduction de Lisp en binôme où les nouveaux concepts sont parfois difficiles, on finissait 30 minutes avant tout le monde sur 1h20 de td.

    Voilà mon modeste avis là dessus.

    Aussi pour les livraisons vous devez connaître Git depuis le temps et l’utilisation de branches serait bien indiquée pour le mode de commit que vous décrivez.

    Merci pour l’article très bien fournit avec des exemples bien concrets.