Le demi-cercle (épisode 24 -- Épisode Neigeux)

le 09/02/2018 par Christophe Thibaut

Il a neigé. Tu prends le temps de passer par le parc. C'est beau. Tu penses à ton cousin, qui vit dans l'Aveyron : - Quand il commence à neiger, les voisins viennent te passer le bonjour pour voir si tout va bien, souvent avec des provisions. Je parle des voisins les plus proches; ceux qui habitent à deux kilomètres.

Tu marches dans le froid. Tu te sens vivant.

Dans la rue qui mène au boulot, la file ininterrompue des automobilistes en colère avance dans la bouillasse avec un concert de klaxon. Tu n'es pas fâché d'arriver. Tu te précipites dans l'ascenseur.

Tu t'installes à ton poste et tu dépiles tes mails.

_de : teamxxl à : jb.locronan cc : m.perez sujet : expérience comparative et résultat Hello Jean-Bernard

À propos de la démarche de travail en équipe (mob programming) : nous avons effectué la semaine dernière une expérimentation afin de comparer deux approches. Ce message présente les résultats que nous avons trouvé.

Le problème que nous nous sommes posé était le suivant :

Étant donné un programme que nous voulons coder, et dont nous avons partagé la spécification, quels résultats obtient-on en une heure : a) en codant seul à son poste b) en codant en équipe

Nous avons donc sélectionné deux problèmes relativement simples, portant sur le même thème, dont tu trouveras les énoncés ici et là.

Comme tu peux voir, les solutions à ces problèmes sont soumises à un test automatique (juge en ligne), ce qui rend indiscutable le critère le plus important, à savoir : le programme soumis au test fonctionne-t'il correctement.

Ci-dessous, les résultats. Nous tenons le code à ta disposition si tu es intéressé.

programme A1 : conformité : passe le test en ligne maintenabilité : insuffisante : pas de tests unitaires, mauvaise lisibilité

programme A2 : conformité : passe le test en ligne maintenabilité : insuffisante : pas de tests unitaires, testé manuellement, nommage peu clair des variables et méthodes

programme A3 : conformité : ne passe pas le test en ligne maintenabilté : bonne : 10 tests unitaires (dernier ne passe pas), facile à comprendre et à faire évoluer

Programme A4 : programme non effectué (recherche d’une approche basée sur librairie existante)

Programme B : conformité : passe le test en ligne maintenabilité : bonne : 8 tests unitaires, séparation des responsabilités (E/S, algorithme), noms de variables standard

Conclusion En codant en équipe, on résoud plus rapidement le problème qu'en codant seul, et on obtient un code plus facile à maintenir. Il nous semble que cette approche va être bénéfique au code d'XXL, dont tu n'es pas sans savoir qu'il comporte de nombreux problèmes de maintenabilité, en plus des défauts constatés dernièrement en recette.

Nous envisageons donc de continuer dans cette direction. À ta disposition pour plus d'information. L'équipe XXL._

—

Bonjour à tous, Mes réponses en bleu. À propos de la démarche de travail en équipe (mob programming) : nous avons effectué la semaine dernière une expérimentation afin de comparer deux approches. Ce message présente

Merci de passer le constaté de votre "expérimentation" sur la ligne R&D perso, et non sur le budget du projet SVP. Comment comptez-vous rattraper le temps qui a été consacré à ce sujet et qui n'a pas été passé sur XXL ?

Nous avons donc sélectionné deux problèmes relativement simples, portant sur le même thème, dont tu trouveras les enoncés ici et là.

Merci pour le lien, je ne connaissais pas.

Conclusion prématurée. Du code plus facile à maintenir, certes, mais à quel coût ? Votre expérimentation montre clairement que le programme peut être réalisé en 1H par une personne. Dès lors, pourquoi dépenser 4H ? Pensez-vous que la direction des Ventes soit prête à débourser quatre fois le coût de chaque fonctionnalité ?

—

Jean Bernard, Tu sembles déduire du rapport que le programme peut être réalisé individuellement en une heure. Or les résultats montrent que : a) seulement 2 personnes sur 4 ont un programme qui marche (i.e. passe le test en ligne) b) les programmes qui marchent ne sont pas pour autant terminés, puisqu'ils ne satisfont pas aux critères de maintenabilité.

—

Où veux-tu en venir ? Je ne suis pas ton raisonnement.

—

_Pour que ce que tu dis, à savoir : Votre expérimentation montre clairement que le programme peut être réalisé en 1H par une personne. soit tout à fait correct, il faudrait que les progammes de la série A soit complètement terminés. Or, aucun n’est complètement terminé.

Même dans le cas où au moins un des programmes serait terminé, alors on pourrait seulement dire : "L'équipe a réalisé à quatre, en une heure, ce que l'un de ses membres a pu réaliser tout seul en une heure", mais non pas que "Chaque tâche que l'équipe réalise en une heure, chacun de ses membres pourrait la réaliser en une heure"._

Qu'est-ce que tu entends par complètement terminé ? Les programmes A1 et A2 marchent, n'est-ce pas ?

—

_Ces programmes marchent mais ils ne sont pas terminés parce qu'ils n'ont pas de tests, et ne sont pas maintenables. Ils devraient être refactorés pour une meilleure maintenabilité.

Donc, pour les terminer il faudrait y consacrer encore du temps : pour écrire les tests, et pour améliorer le code.

Et si l'auteur du programme ne sait pas écrire de tests, alors il faut également compter le temps qu'il lui sera nécessaire pour déboguer le code. Ou pour apprendre à écrire des tests._

—

Excusez moi, je n'ai peut être pas tout suivi, mais : Pourquoi améliorer encore et toujours un programme qui marche ?

—

_Bonjour Maria,

Comme tu peux voir en suivant les liens, l'énoncé des programmes donnés en exercice est complètement spécifié, et de plus cette spécification ne changera pas dans le temps.

Dans XXL en revanche, c'est extrêmement rare d'avoir une user story qu'on peut considérer comme complètement spécifiée, et dont la spécification ne changera pas dans le temps.

Par conséquent dans XXL, le fait qu'un programme marche n'est pas suffisant pour qu'on le considère comme terminé. Il faut encore que ce programme soit facile à maintenir et à faire évoluer.

Normalement, c'est à dire, si on veut faire les choses correctement, ce programme devrait avoir des tests, et répondre à nos standards de lisibilité, modularité, etc._

—

Oui, c'est sûr. Mais à un moment donné, quand on a une échéance à tenir, il vaut mieux livrer que d'améliorer la qualité à l'infini. On pourra toujours améliorer plus tard.

—

On pourra, si on ose encore toucher au code…

—

En fait, dans cette "expérimentation" comme vous dites, vous êtes à la fois juge et partie.

—

Pas tout à fait : le programme passe sous les fourches caudines du juge en ligne, et le juge est implacable.

—

Peut être. Mais ce que vous pouvez démontrer à l'aide d'un petit programme écrit en une heure, peut avoir de la valeur pour ce qui est des petits programmes. Mais ça ne prouve pas que votre approche passe à l'échelle.

—

Ecrire du code à la rache non plus ça ne passe pas à l'échelle.

—

Ce n'est absolument pas ce qui vous est demandé.

—

Ça passe mieux à l'échelle que se mettre à quatre de front sur une story !

—

Ça reste à prouver.

—

Je ne vois même pas pourquoi je devrais m'en mêler. Je n'ai pas le temps de discuter de tout ça. Vous voyez avec Maria. Je n'en reviens pas qu'il faille vous dire comment faire votre job.

—

Tu n'as pas besoin de nous dire comment faire le job. Tu le fais, mais c'est ton choix.

—

Vous mettez le projet dans une situation qui me force à intervenir.

—

Parce que tu considères que nous faisons fausse route.

—

Précisément.

—

Excuse-moi si j'insiste : mais l'expérience ne permet pas d'affirmer qu'il est plus rapide de réaliser un programme tout seul plutôt qu'en équipe, en particulier si l'on souhaite que ce programme soit maintenable.

—

Pour moi c'est évident. J'en ai fini avec cette discussion, personnellement. Je vous saurais gré de reprendre une activité normale.

Tu te tournes vers Jérémie : - Bon alors qu'est-ce qu'on fait ?

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown 4 -- Driver / Navigator 5 -- Brown Bag Lunch 6 -- Conseils à emporter 7 -- Crise / Opportunité 8 -- Le Cinquième Étage 9 -- Que faire ? 10 -- Soit... Soit... 11 -- Boîtes et Flêches 12 -- Le prochain Copil 13 -- La Faille 14 -- Poussière 15 -- L'hypothèse et la Règle 16 - Déplacements 17 -- Jouer et ranger 18 -- Arrangements 19 -- Mise au point 20 -- Expérimentation 21 -- Échantillons 22 -- Non-conclusions 23 -- Non-décisions