Métro Boulot Dodo

Signal sonore de fermeture des portes

– Ah salut ! Tu prends la ligne 7 toi aussi ? Alors c’est pour bientôt la mise en prod’ ?
– M’en parle pas, c’est dans 10 jours.
– Dis donc je vois passer une tonne de mails sur le projet..
– Oui, on n’a pas accès au bug tracker du client donc il nous envoie les bug reports par mail.
– Mince, ça en fait un paquet!
– Tout est relatif. Il y a surtout des demandes d’évolutions. Heureusement, Hubert monte au créneau pour renégocier ça avec le client.

– Mais les bugs intitulés « null pointer exception », ce ne sont pas des demandes d’évolutions, si ?
– Non. Ca vient de la couche contrôleur; c’est juste des petits détails de fonctionnement.
– Vous n’avez pas de tests unitaires sur la couche contrôleur ?
– On devrait, mais non. Michel dit qu’il en fait jamais sur cette partie de l’appli. Trop compliqué.
– Vous avez un standard là-dessus ?
– On est pas tous d’accord, en fait. Mais surtout, là, on n’a pas le temps d’écrire ces tests.
– Combien de temps ça prendrait de tester la couche contrôleur de chaque écran ?
– Aucune idée; je dirais, pas mal de temps.
– Combien de temps avez-vous passé sur la correction de bugs jusqu’ici ?
– Au moins deux semaines, à vue de nez.
– Est-ce que vous rétroanalysez les bugs une fois qu’ils sont corrigés ?
– Il faudrait; mais on n’a pas trop le temps; il faudra qu’on en parle en rétrospective de projet.
– Le temps que vous passez à corriger ces bugs, est-ce qu’il était prévu au planning ?
– Justement, non; c’est pour ça qu’on n’a pas le temps.
– Mais vous le prenez, n’est-ce pas ?
– Qu’est-ce que tu veux dire ?
– Le débogage n’était pas planifié, mais vous prenez quand même du temps pour le faire…
– Et ?
– Le temps de rétroanalyser ou d’écrire des tests, en revanche, vous ne le prenez pas.
– Ce serait abuser, je pense.
– En quoi est-ce moins légitime que du temps pris pour déboguer ?
– On ne peut pas laisser des bugs dans le produit que l’on va livrer. Il faut corriger, quoi.
– Compris. Vous livrez le produit, donc vous corrigez le produit.
– Voilà. Tu ferais quoi, toi qui est si fort ?
– Pour les deux semaines qui viennent, j’ai pas d’idée. Par contre pour le prochain projet..
– Justement, on démarre un autre projet bientôt.
– Eh bien, je planifierais du temps pour écrire des tests, et rétroanalyser les bugs.. Place d’Italie, je sors là.
– C’est très bien, mais ça, il faut le vendre au client!
– Vous aviez vendu du débogage sur celui-ci ?

Signal sonore de fermeture des portes

7 commentaires sur “Métro Boulot Dodo”

  • Excellent ! Et tellement vrai, j'ai eu ce genre de discussion récemment avec les fameux "oui mais ça coute cher" et "il faut le vendre au client" ...
  • Bonjour, Cela me rappelle un petite phrase (que je n'ai pas retrouvé sur le net) d'octave Gélinier : "On n'a jamais le temps de faire, on trouve toujours le temps de refaire !!!"
  • Excellente discussion! Voilà une belle retranscription d'un fatalisme hélas bien ancré. En même temps, mettre en place de nouvelles manières de travailler demandent beaucoup d'énergie et un contexte propice... Il semblerait que les deux manquent dans ce cas!
  • Je me suis souvent retrouvé face à de telles situations et en effet la personne qui aurait besoin de pousser l'agilité un peu plus est un poil réfractaire à le faire. Mais le plus intéressant dans l'histoire est, pour ma part, quelle est l'attitude a adoptée face à une telle situation? Dans la petite histoire une des deux personnes commence à se braquer parce que l'autre le met face aux choix "absurdes" faits pendant le projet. Pour vous quelle serait la meilleur façon de faire adopter de meilleurs pratiques sans brusquer les personnes ignorantes de celles-ci?
  • Bonjour Harold, et merci pour l'intérêt que vous portez à cette conversation. Vous avez raison de souligner la difficulté qu'il y a à adopter de meilleures pratiques dans le contexte d'un projet en retard. Souvent les projets en difficulté nous poussent à des situations comparables au "Zeitnot" dans une partie d'échecs. Il est trop tard pour se poser, prendre du recul, analyser et apprendre. Comme le souligne Jean-Claude, on n'a jamais le temps de bien faire, mais toujours le temps de refaire. Ma meilleure idée serait donc "d'arrêter la pendule" : connaissant les problèmes structurels du projet, acter le retard pris, réfléchir en équipe aux raisons (symptômes et causes profondes) de ce retard, et mettre en place un plan de recouvrement qui incluerait l'apprentissage des pratiques recommandées.
  • Bonjour, @Christophe Thibaut : pour la gestion de projet et le temps, l'utilisation de la chaîne critique ( http://www.chaine-critique.com/fr/Accueil-Chaine-Critique-3.html ) ?
  • J'apporterais quelques bemols pour ma part. Tout d'abord, quand je vend et que je planifie un projet, je provisionne des charges pour le passage des cas de tests et la correction des bugs relevés, ainsi que pour la correction des bugs relevés par le client. Donc la charge de correction de bug est bien vendue et intégrée au plannning. Après bien évidemment, tout dépend de la qualité du code : si il y a 10 bugs par ligne de code, on risque d'exploser la charge prévue et de ne pas tenir le planning. Ensuite, l'intérêt des tests automatiques, bien qu'évident pour les puristes, est à mettre en balance avec le coût qu'il représente et la typologie de projet. D'un côté on a un projet d'entreprise qui va connaitre de multiples évolutions au fil des mois et années et de l'autre une application qui va connaitre une ou deux versions. Le gain apporté par les tests automatiques contre-balance plus ou moins les inconvénients (coût, contraintes de conception, contraintes d'outillage, niveau de compétence requis des développeurs) selon le nombre de versions et d'itérations. 50 jours passés à coder des classes de tests seront rentabilisés dans le temps avec de multiples versions, pas avec une ou deux releases. Je pense ici qu'on peut distinguer l'activité de la SSII qui livre une application à son grand compte et l'oublie et celle d'une équipe interne qui va vivre des années avec un produit. Les priorités ne sont pas les mêmes. Je terminerais par la nécessité de disposer de personnel qualifié et expérimenté pour mettre en place des tests unitaires automatiques, ou au moins du temps nécessaire pour les former et les sensibiliser. Quand un client vous demande de livrer une application pour après-demain, vous ne disposez pas nécessairement des ressources déjà formées, ni du temps ou des ressources pour former les juniors que vous allez devoir employer car ce sont les seules ressources disponibles immédiatement (c'est bien connu, les meilleurs éléments ne sont jamais disponibles car tout le monde se les dispute). Par expérience, demander à des développeurs trop juniors de mettre en place des tests unitaires automatiques aboutit à des dérives de charge surprenantes où on se rend compte qu'on grille davantage de charges à coder et maintenir les tests que le code réellement utile. Le facteur humain est essentiel et doit être pris en compte. On voit bien que la qualité des développeurs est essentielle ce qui nous renvoie, mais c'est un autre débat, à la culture d'entreprise Française qui ne valorise pas ou peu (quand elle ne les méprise pas carrément) les activités techniques, privant les entreprises de l'apport des meilleurs développeurs qui s'orientent vers d'autres activités plus rémunératrices et plus reconnues (consulting, spécialisation pointue ...) En conclusion, je dirais que bien évidemment c'est une bonne pratique mais que comme le dis le dicton populaire "le mieux est parfois l'ennemi du bien".
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha