Aussi aux lumières allumées dans les salles de réunion vides, aux ordinateurs laissés allumés la nuit pour ne pas avoir à attendre les 10mn nécessaires au démarrage du PC, aux appareils laissés en veille, aux voitures utilisées pour prendre le pain à 800m. Parallèlement, nous n'avons jamais assez de ressources, qu'elles soient électriques ou pétrolières.

Enfin à Xebia, qui n'avait pas peur de la crise en 2009, pensant même qu'elle favoriserait l'essor des méthodes agiles.

Le lien entre tout cela n'est peut être pas flagrant, et pourtant il m'interpelle. C'est la notion de ressources : si elle est gratuite, nous ne cherchons pas à bien l'utiliser car nous croyons qu'elle sera toujours là; si elle est payante, on y prête plus d'attention et les décisions prises sont plus censées.

Rien n'est gratuit

Il manque pourtant des facteurs dans le premier scénario :

  1. ce n'est pas gratuit pour tout le monde
  2. et peut être même pas pour nous, la facture peut arriver plus tard

C'est un peu le problème des formules à volonté. Les ressources "gratuites" (ou non payé par nous....) peuvent parfois nous faire faire l'économie du bon sens. Ce n'est pas parce qu'on peut faire quelque chose qu'il faut le faire. Si je mange dix assiettes de frites, juste parce que c'est "à volonté", jusqu'en avoir mal au ventre, ce n'est juste pas très malin. Si en plus, la nourriture non consommée est en fait donnée aux resto du coeur, on se dit que ça ne valait décidément pas le coup. Même si ce n'est pas nous qui réglons la facture, il y a toujours un cout pour quelqu'un. Néanmoins, il faut bien voir pourquoi on fait les choses. Si notre but est de s'exploser le ventre, pourquoi pas. :D

Sur les énergies (c'est ma minute green), j'ai vu un reportage sur les pompes à chaleur et éoliennes dernièrement. Tout à la fin, l'une des conclusions était : avant de chercher à augmenter vos ressources d'énergies, il vaut mieux faire un devis sur l'isolation car la plupart des maisons individuelles sont très très mal isolées. C'est beau non? J'ajouterais : "quand y en a plus, y en a pas encore". Quand il y a un problème, il vaut mieux commencer à se demander pourquoi il est là plutôt que mettre encore et encore des patchs. On peut aller chez le kiné tous les deux ans pour son dos, mais pourquoi avons nous régulièrement mal? Des mauvaises habitudes, un surpoids? On peut aussi ajouter des gens sur un projet qui n'avance pas assez vite (sauf qu'il faut du temps pour que l'équipe se synchronise avec eux....). On peut chercher du pétrole encore et encore et des ressources magiques mais c'est aussi notre mode de consommation qui doit être revu, car autrement, nous n'en aurons jamais assez. C'est plus facile de voir des causes extérieures et appliquer des solutions extérieures ("pas assez de ressources") que de se voir responsables (même un peu). La bonne nouvelle, c'est que c'est plus simple de changer les causes internes qu'externes, même si ça fait plus peur.

Quant au projet trop agile du pote, il n'y a pas vraiment de solution magique, mais c'est marrant de voir une personne regretter le waterfall. En principe, tout le monde devrait être à peu prêt satisfait à la fin de l'itération car le produit est potentiellement livrable. S'il faut recommencer, on peut se dire que ce qui a été fait n'a pas été fait pour rien, vu qu'il a permis de voir que ce n'est pas cela qu'on souhaitait :D Le principe de penser simple devrait aussi limiter l'investissement apporté dans ces développements "jetables". Après, je crois que c'est un peu ça d'être développeur, on fait, on jette, on recommence, et au bout d'un moment on est super contents du résultat, que ce soit itération après itération ou refactoring après refactoring. Par contre, ce n'est pas une raison pour en abuser, et je crois aussi que la MOA devrait essayer de réfléchir un peu plus loin et un peu plus global, sans trop rentrer dans le détail. Le fait qu'elle use trop du "je peux changer d'avis tout le temps" a quand même finalement un cout caché sur le moral des développeurs. L'essentiel étant de communiquer dès qu'on peut, de faire participer tout le monde, que le développeur ne vienne pas en trainant des pieds au planning game en se demandant ce qu'il va encore devoir refaire.

Ca doit se savoir

J'en viens à me dire que vu qu'on à du mal à trouver les choses gratuites appétissantes et à reconnaître leur ephémérité, il faut les supprimer. En gros : mettre en évidence leur coût, les rendre visibles. Cela permettrait de limiter le gâchis et d'optimiser les ressources.

C'est ce que faisait Julien au sujet de la dette technique des projets, pour rendre visible le travail des équipes à ce sujet. En conséquence, la MOA ne pense pas que l'équipe ne fait rien quand elle ne travaille pas sur de nouvelles fonctionnalités, et on visualise bien le coût d'un développement dit rapide.

Mais quand meême... Déjà pour se rendre compte qu'on abuse de quelque chose, ce n'est pas évident, alors de chercher une solution, c'est vraiment pas gagné. Il y a déjà suffisamment de problèmes à traiter, on ne va pas en chercher de nouveaux. Mauvais argument : ce n'est pas parce qu'il est moins visible qu'il est moins important à traiter (surtout si la solution ne coute en fait pas chère).

En fait, je trouve qu'on manque de consultants dans les équipes (non non, je ne dis pas ça en tant que consultante!). Enfin, plutôt d'oeil extérieur, de partie non prenante. Un regard neuf qui mette en évidence nos mauvaises habitudes. A défaut de pouvoir se payer un coach, ou des coachs tournants, ça pourrait être pas mal qu'une personne d'une autre équipe, voire d'un autre service (pour qu'il n'y ait pas de "rivalité") vienne jouer le rôle d'auditeur de gâchis. Je me demande ce que cela pourrait donner, mais ça existe peut-être déjà? Un jour par an, on devient auditeur à la compta, ça serait coooool ! Bon, j'admets que ça peut être vu comme du gaspillage de développeur :D

Source de l'image : forumvietnam.fr