Ressources :
De la difficulté à créer une barre rouge
X — J’ai corrigé le bug que nous avions identifié : il y avait juste une ligne à changer.
Moi — Alors c’est bon, on peut désormais ajouter ton correctif dans notre dépôt de code source…
X — Pas tout à fait, je n’ai pas encore réussi à faire le test unitaire correspondant.
Moi — Tu veux dire qu’il n’y a pas encore la barre rouge qui se transformerait en barre verte avec le correctif.
X — Oui, c’est ça. Je me disais que vue la trivialité du correctif, on pourrait peut-être s’en passer.
Moi — Mais tu sais pourtant que je vais insister, n’est-ce pas ?
X, rigolant — On ne sait jamais, sur un malentendu…
Moi — Je te propose plutôt d’explorer tout ça ensemble et en détails.
X, avec l’index pointé sur son écran — Regarde c’est là, il suffit de changer précisément ce paramètre : j’avais oublié de le modifier en faisant un copier-coller.
Moi — Et si on regardait autour de cette ligne pour bien comprendre le contexte qui déclenche l’erreur.
X — Je commence à sentir ce que tu veux me montrer : il y a cette variable - l’utilisateur authentifié - qui peut changer radicalement le contexte d’exécution de la méthode.
Moi — C’est peut-être elle qui te bloquait dans ton test unitaire. Est-ce qu’on pourrait le regarder ensemble ?
X — Ben justement, déjà que je m’emmêlais les pinceaux entre le paramètre du code, ceux des tests, celui qui doit déclencher la barre rouge et celui qui déclenchera la verte, je me sens encore plus perdu avec cette nouvelle variable dont il faudrait tenir compte. D’autant plus que je ne l’ai pas encore croisée dans mes projets « mobile ».
Moi — Effectivement entre l’application iOs à laquelle tu participes activement et l’application web que tu re-découvres via ce bug, il y a un gouffre.
X — Et c’est bien dans ce gouffre précisément que je suis actuellement. C’est rageant de s’y sentir piégé alors que - et permets-moi d’insister - le correctif est ultra-simple.
Moi — Mais on perdrait une occasion incroyable de tous progresser au passage. Le logiciel à cause d’un cas qui ne serait pas couvert par un test unitaire, toi à cause d’un défaut de connaissances sur le contexte général d’une session authentifiée dans Opentime, et moi à cause d’un point aveugle sur les gestes indispensables du développeur qui arrive chez No Parking.
X — J’étais loin d’imaginer que cela pourrait avoir un impact sur ton boulot de manager !
Moi — Si je peux faire monter en compétence un débutant plus vite, il fera du meilleur boulot plus rapidement : c’est évident. Mais si en plus je peux supprimer la difficulté qu’il y a à initialiser le contexte de tous les tests de ce type, alors c’est potentiellement tous les développeurs de la boîte qui en profiteront. Y compris les plus anciens qui ont oublié depuis longtemps que ce n’était pas si simple et qui ont appris à faire avec…
X, paniqué — Tu veux me faire modifier tous les tests avec cette « difficulté » dans tout le code d’Opentime ?
Moi — Pas forcément, on va d’abord commencer par apprendre et appliquer le standard. Regardons d’abord comment ce type d’initialisation est réalisée actuellement. Il sera toujours temps ensuite de modifier ce standard si le potentiel d’amélioration est intéressant.
Quelle boussole pour quelle stratégie ?
X — J’ai l’impression que les praticiens Lean n’aiment pas trop les plans d’action. C’est pourtant le b-à-ba de la stratégie : d’abord définir les objectifs puis appliquer les bonnes pratiques pour y arriver.
Moi — Parce que tu crois qu’on peut « y arriver » ?
X — Si les objectifs sont clairs, heureusement qu’on peut imaginer « y arriver » ! Sinon on ne fait rien.
Moi — Les objectifs de la maison Toyota aussi sont très clairs : satisfaire chaque client à travers les prismes « sécurité, qualité, délai & coût ». Et pourtant on est bien d’accord qu’ils sont hors d’atteinte.
X — À ce niveau-là, c’est clair : on sait tous que le « zéro défaut » n’est qu’une chimère inaccessible.
Moi — On sait aussi que c’est un challenge qu’on ne peut pas ignorer : aucun client ne souhaite un produit ou un service qui se dégraderait. Il n’y a que les financiers à courte vue pour y voir un quelconque intérêt.
X — Et pourtant ne dit-on pas « move fast and break things » dans la tech ?
Moi — C’est surtout la stratégie des fonds d’investissement, prêts à sacrifier 99% des boîtes de leur portfolio pour qu’un projet cartonne et débouche sur des rendements stratosphériques, propres à effacer toutes les pertes.
X — Mais ça marche !
Moi — Au prix d’un hasard optimiste et d’un incroyable gaspillage quand même.
X — J’imagine que tu penses la même chose des « transformations » dans les grands groupes.
Moi — Tu parles de ces plans à 18 mois ou 3 ans, pour arriver à X% de salariés en moins et Y% de CA grâce à des formules dans un tableur Excel et de jolies transitions sur une présentation en format paysage ?
X — Je sens surtout poindre une caricature de quelqu’un qui ne les a pas vécu de l’intérieur : on parle de monstres organisationnelles de plusieurs milliers de personnes, compliqués à manoeuvrer et longs à la détente. Si tu n’as pas un plan précis en tête, tu vas te casser les dents.
Moi — Fondamentalement, le Lean prend le contre-pied total : il cherche à créer et à entretenir le mouvement. Pas à atteindre un état idéal, fixe et stable, encore moins par une grande transformation big-bang. Le pari fondamental qu’il fait est double. D’abord qu’on ne peut pas maitriser l’univers extérieur. Par exemple, et sauf avantage indu, il y a un prix de marché pour tous les achats, valables pour tous les concurrents : il faut faire avec. Et ensuite qu’il faut de la stabilité interne pour répondre à ces changements externes.
X — On n’est pas si loin du « moat », ce fossé infranchissable qui protégera l’entreprise des aléas et de la concurrence : ne s’agit-il pas du graal pour n’importe quel business ?
Moi — Au prix d’être totalement submergé le jour où la digue cède…
X — Mais n’est-ce pas la même contradiction quand tu évoques une quête de stabilité dans un monde volatil ?
Moi — Les plus belles boîtes Lean que j’ai eu l’occasion de visiter avaient toutes un point commun : si tu y retournes un mois plus tard, il y a déjà des choses qui ont changé. L’esprit Kaizen est visible : on cherche à améliorer le travail (à la fois les produits et les outils de production) en permanence, par petites touches réfléchies. Et je peux te garantir que c’est loin du plan d’action. Quand tu le pratiques, ça devient même assez fun : pouvoir suivre ses intuitions avec une bonne boussole, c’est assez exaltant. Et les outils du Lean te fournissent cette boussole, à la fois précise et radicale. Reste à apprendre à la lire.
Dépiler les andons
Moi — Je vois que l’andon sur un de tes kanbans s’est allumé, est-ce qu’on peut regarder ensemble ce qui se passe ?
X — Mais je pensais que pour déclencher l’andon, il fallait appuyer sur le bouton orange dans notre interface.
Moi — Le déclenchement manuel est effectivement possible, mais il y a aussi un déclenchement automatique : quand on n’arrive pas à suivre le takt ou quand on passe trop de temps sur un kanban, par exemple. C’est ce dernier cas qui vaut ma présence à tes côtés.
X — Pourtant j’ai à peine commencé hier matin.
Moi — Pour se faciliter le lissage en interne, on a décidé arbitrairement qu’un kanban devait être faisable en moins de 24h - soit 7 ou 8h de travail consécutif. Si tu l’as commencé en fin de matinée, c’est donc normal que l’andon se déclenche aujourd’hui en début d’après-midi.
X, sceptique — Bon, d’accord…
Moi — Alors que raconte ce kanban ?
X — Je ne vais pas réussir à le terminer d’ici ce soir : il est plus complexe que d’habitude et comme L. n’est pas là, je n’ai pas pû lui demander de l’aide comme pour les kanbans précédents. Bref, je pédale un peu dans la semoule et je ne suis toujours pas certain de savoir comment le traiter en fait.
Moi — Pourtant quand L. est absente, il y a bien d’autres personnes qui vérifient tes commits…
X — Bien sûr mais j’ai toujours peur de les déranger avec mes petits problèmes de démarrage, surtout que ça fait désormais plus d’un mois que je suis dans l’équipe.
Moi — Je vois. Je comprends mieux pourquoi mon sensei insistait sur cette chaîne d’aide : ce déclenchement automatique me fait bien plaisir !
X, interloqué — Tu parles de plaisir ?
Moi — Bien sûr ! Je suis content de savoir qu’on devrait pouvoir t’éviter au moins deux jours supplémentaires de pédalage dans la semoule. Il a eu raison de me montrer une vidéo avec un andon automatique sur l’alimentation en pièces d’une petite machine industrielle.
X — Et moi qui pensais que tu serais contrarié.
Moi — Bien au contraire, cela met en lumière un point que je ne t’ai pas encore expliqué clairement.
X — Comment réaliser cette tâche ?
Moi — Même pas… Plutôt comment se donner le temps d’y arriver. Tu le sais déjà, chaque kanban doit être faisable en moins de 24h. Mais dès que tu découvres que tu n’y arriveras pas, tu as la possibilité de modifier le libellé du kanban avec la mention « exploration » : une fois que tu auras fini ton exploration (toujours ces fameux 24h maximum), tu auras appris des choses. Soit que ce n’était pas si difficile, tu peux alors valider le kanban normalement; soit que ce sera effectivement plus complexe que prévu, tu devras alors créer d’autres kanbans - peut-être 1, 2 ou 3 - pour arriver au bout. Des kanbans qui viendront s’ajouter à ceux qui étaient déjà pré-positionnés pour être lancés dans les jours à venir : une nouvelle phase de lissage se chargera d’équilibrer le tout en fonction des contraintes connues des clients et des collègues.
X — Est-ce que je peux en profiter quand même pour te demander de l’aide sur ce kanban en particulier ? À ton air amusé, je pense que tu sais pertinemment comment en venir à bout.
Moi, pointant un ligne sur son écran — Tu pourrais en effet créer une backtrace sur cette variable puis vérifier si la pile d’appel est bien celle que tu as en tête. Et au passage, tu devrais bientôt apprendre à repérer les interceptions d’un plugin dans le code d’Opentime… Et leurs conséquences.
