Bruno:
Dans Gran Turismo, quand tu passes les vitesses pile au bon moment, que les pneus collent à la piste et que ton bolide file à 300 sans trembler, t'as quand même un petit frisson, tout est parfaitement huilé, chaque pièce fait son taf. Mais dans nos usines logicielles, c'est souvent plus Mario Kart que Formule 1. Entre les carapaces rouges, les comites foireux et les délais qui partent en drift, on est loin du circuit complètement maîtrisé. Mais alors, comment rendre nos usines aussi prédictibles qu'un tour de piste ? Peut-on réellement réduire l'attente et fiabiliser les livraisons sans tomber dans du taylorisme logiciel ? Et surtout, comment éviter que notre belle chaîne de dev devienne une usine à gaz ? Pour répondre à ces questions de précision mécanique, je ne reçois pas Enzo Ferrari, mais il s'y connaît en usinage. Geoffrey, bonjour.
Geoffrey:
Bonjour.
Bruno:
Alors Geoffrey, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Geoffrey:
Alors Geoffrey Bérard, je suis principal ingénieur chez Les Furets. Je travaille chez Les Furets depuis 13 ans. et en gros mon rôle c'est de m'assurer que les gens se posent bien toutes les questions avant de prendre leurs décisions sur qu'est-ce qu'on veut faire et aussi comment on veut le faire d'où la question de prédictibilité de notre process de création de valeur.
Bruno:
Et alors se poser les questions sur qu'est-ce qu'on veut faire est-ce que ça veut dire que tu vas t'intéresser uniquement à la feature qui va être produite.
Geoffrey:
? Non moi l'idée c'est de me focaliser déjà sur le problème qu'on veut résoudre plus que sur la feature elle-même pour être sûr de bien comprendre, tous les tenants et aboutissants et vraiment avoir une vision 360 du problème pour essayer d'envisager la meilleure solution ou à défaut de la meilleure la solution qui va nous apporter une valeur ajoutée le plus vite possible. Parce que souvent aujourd'hui on a envie d'être agile, on a envie d'être rapide surtout dans un monde comme le web où les choses évoluent vite donc on a envie d'avoir un temps d'itération qui est relativement court et c'est pas juste une volonté qu'on a, c'est une idée à bien avoir au coeur de notre prise de décision c'est qu'aller vite c'est un choix c'est pas seulement une conséquence ou une volonté une fois qu'on a pris la décision dans la direction où on voulait aller.
Bruno:
Mais donc est-ce que le comment est du coup moins important que le pourquoi ?
Geoffrey:
Pour moi, les deux sont aussi importants l'un que l'autre. Le but du pourquoi, c'est justement d'essayer de savoir quel problème de nos utilisateurs on a envie de résoudre. Parce que comme dans toute démarche, si on n'a pas de valeur à ajouter, ça ne sert pas à grand-chose de se lancer. Et le comment va plutôt nous permettre de livrer les choses dans les conditions qu'on a décidées ou dans les conditions les plus pérennes pour l'équipe, pour l'utilisateur. Parce qu'un utilisateur ne va pas avoir envie d'attendre six ans pour avoir sa feature. Mais on n'a pas envie de cramer l'équipe. Donc le comment, c'est plutôt la question de se focaliser une fois qu'on sait où on veut aller, de trouver comment bien aligner les planètes pour que tout le monde y trouve son compte. À la fois les équipes qui vont bosser sur le projet, les investisseurs qui vont le payer et les utilisateurs qui derrière vont pouvoir en profiter.
Bruno:
Quand on parle d'usine logicielle, il y a quand même ce mot usine qui est quand même assez fort. Où il y a quand même la notion de produire des choses de manière très uniforme et sur un rythme hyper régulier alors on a déjà parlé d'usine logicielle, avec Dimitri Bailly qu'on a reçu il y a longtemps sur ce micro mais qui est revenu il y a moins longtemps pour faire le refacto de son épisode on pourra mettre les liens en description bien évidemment donc qui était aussi chez LF que tu as connue d'ailleurs chez LF, comment est-ce qu'aujourd'hui au-delà de tout ce qu'a pu nous raconter Dimitri il y a fort longtemps maintenant, comment est-ce que toi tu t'assures qu'on puisse justement délivrer de la valeur de manière régulière et très uniforme quelle que soit au final la fonctionnalité, la features ou l'équipe qui va la produire.
Geoffrey:
Alors c'est vrai que le terme usine peut être assez alors je ne vais pas dire péjoratif mais peut être assez réducteur parce qu'effectivement une usine aujourd'hui c'est quelque chose qui va produire à la chaîne les mêmes éléments et on sait qu'aujourd'hui, on produit des choses qui sont différentes. On produit des nouvelles features, des nouvelles fonctionnalités. Par contre, là où on a réellement besoin d'un système qui est similaire à une usine, ça va être sur toute l'automatisation qui va entre le moment où on écrit le code ou le moment où on produit des éléments et le moment où on l'envoie en production en l'ayant testé, validé, déployé, en ayant fait tout un process d'automatisation qui nous permet de nous garantir que le système correspond à nos attentes. Et donc ça, c'est réellement une usine. on a une entrée et la sortie va être toujours la même et autour de ça il y a comment est-ce qu'on on anime et on occupe les équipes pour pouvoir en apporter le plus de valeur et l'utiliser au mieux, et du coup je veux bien revenir sur ta question en fait ce.
Bruno:
Que t'évoquais m'amène une autre question c'est que tu dis que l'idée c'est de mettre en place un ensemble de systèmes qui nous permettent de s'assurer que ce qu'on va pousser en prod correspond à nos attentes, la difficulté dans notre métier c'est comme tu le dis, c'est qu'on produit pas le même élément en boucle, on fait des éléments qui sont différents à chaque fois, donc en fait nos attentes changent à chaque fois. Cette notion d'usine logicielle, t'es obligé de l'adapter à chaque release au final ?
Geoffrey:
Sur la partie qu'on va automatiser, c'est vraiment ce qui va être la même chose, quoi qu'il arrive. Dans tous les cas, j'ai besoin de déployer sur un environnement de staging, de pré-prod, pour vérifier que le déploiement se passe bien, pour vérifier que je respecte tous mes standards, que tous mes tests soient au vert, quels que soient les tests eux-mêmes. Cette partie-là, elle est vraiment répétitive et totalement automatisable. Ce qu'il est moins c'est qu'est-ce que je teste qu'est-ce que je fais, c'est quoi le code que je vais mettre dans ma boîte et que je vais mettre sur mon banc de test et que je vais tester dans tous les use case pour vérifier que ça fonctionne et c'est cette partie là qui elle change à chaque fois et cette partie là, elle est un peu en dehors de notre, système de factory automatique elle est à la main des équipes et elle dépend réellement du besoin de l'utilisateur et c'est elle qui change à chaque fois et donc c'est elle qui va apporter de la variabilité. Et donc, malgré ça, il faut qu'on arrive à avoir un système qui va être prédictif. Et ça va dépendre de principalement deux choses. La première chose, c'est la capacité des équipes à estimer. Et comme je l'ai dit, autant mettre mon système et lui demander de jouer tous les tests automatiquement en moins de 15 minutes chez nous, je sais que je vais avoir ma réponse. Par contre, savoir par rapport à ma nouvelle fonctionnalité, au nouveau besoin de l'utilisateur que je vais vouloir adresser, quel est le temps nécessaire à écrire le code pour répondre à ce besoin, ça c'est plus compliqués. Aujourd'hui, le fait est que sur l'estimation, on a énormément de problématiques parce que, que ce soit les développeurs, les product owners, les personnes du métier comme les personnes de la tech, quand on pose cette question-là, ils se focalisent uniquement sur l'élément qu'ils doivent produire. On me demande de produire une feature, on me demande de faire une statue, je vais me focaliser uniquement sur la statue. On me demande de livrer un élément, je vais me focaliser uniquement sur la taille du paquet que je vais devoir livrer. Là où aujourd'hui si on veut vraiment être efficace sur l'estimation il faut prendre un vrai pas de recul et donc prendre le temps d'avoir ce pas de recul et de réfléchir un peu out of the box. Pour se demander est-ce que le seul élément important pour l'estimation c'est la feature que je dois livrer, et la réponse est non dans la majorité des cas quand on regarde beaucoup d'équipes agiles qui fonctionnent sur des méthodes comme Kanban on se rend compte que dans la plupart des cas quelle que soit la complexité, le temps d'attente est relativement le même parce que la majorité du temps nécessaire à livrer c'est de l'attente, de la synchronisation entre équipes de la communication, c'est important mais c'est pas la construction réelle, et dans les faits, aujourd'hui si quelqu'un me demande, c'est un exemple que je prends souvent, mais si quelqu'un me demande combien de temps il me faut pour livrer un paquet à Marseille, je vais pas du tout me focaliser sur la taille du paquet je vais d'abord me focaliser sur le moment où on va avoir besoin de le livrer parce que si je dois prendre la route, ma réponse sera pas du tout la même si je pars le 15 août, ou si je pars le 25 janvier et donc c'est hyper important de connaître bien le contexte et au final l'estimation doit dépendre autant de ce qu'on va me demander de faire au même moment, que du sujet que je dois livrer en soi. C'est pour ça qu'il y a certaines démarches agiles, typiquement le One Piece Flow, qui vise à dire, pour mettre ça de côté, parce que c'est quelque chose qui est difficile, c'est vraiment un système complexe, on va se focaliser uniquement sur un seul élément. Effectivement, si vous avez un système autoroutier et que vous avez uniquement une livraison à faire à un instant T, c'est sûr qu'il n'y aura aucun problème et qu'on sera toujours dans les meilleures conditions. Après, ça a un coût. Est-ce qu'on a envie de maintenir tout le système autoroutier français juste pour un camion de livraison ? Je ne suis pas sûr. Et donc, le premier point, c'est ça, c'est estimer mieux. Et le deuxième point, c'est prendre les décisions d'organisation qui vont nous garantir d'être prédictibles. Il ne suffit pas de se dire, j'aime bien la prédictibilité, donc je la veux. Il faut s'organiser pour l'avoir. Et donc, c'est hyper important de l'avoir en tête au moment où on priorise. Si j'ai envie de prioriser à la dernière minute parce qu'on vient de me donner un nouveau sujet hier qui est hyper intéressant, très bien, on peut le faire si c'est hyper important. Par contre, forcément, ça va impacter la prédictibilité parce que des sujets qui sont là depuis plus longtemps vont devoir attendre. Et donc, quand je vais faire la mesure du temps nécessaire pour qu'ils sortent, ça va être un peu plus long que la réalité. Donc, si on veut absolument de la prédictibilité, ça va être au détriment d'autres éléments qui peuvent être intéressants aussi, comme la réactivité ou l'agilité au sens où j'ai envie de pouvoir changer d'avis à la dernière minute. Et donc, si on a envie d'avoir un système prédictible, ça demande d'être meilleur sur l'estimation et de prendre plus de recul et d'avoir une idée du contexte global quand on estime. Et la deuxième chose, c'est d'être prêt à assumer des choix de priorisation qui nous permettront d'être plus prédictibles.
Bruno:
J'aime beaucoup ton analogie sur les voitures. Tu me l'avais déjà dit en m'expliquant que le temps de trajet est plus dépendant du nombre de voitures sur la route que de la taille de mon paquet en soi. Et effectivement, dans un contexte de projet, c'est vrai que c'est très vrai. Ma capacité à livrer un projet est quand même plus dû aux autres projets que j'ai sur mon escarsal à un instant T qu'au projet en tant que tel. Mais ce que tu sembles dire, c'est que dans cette notion de prédictabilité d'un projet, ce que tu mets surtout, c'est la notion d'estimer le... Le temps que ça va te prendre de gérer un projet et au final, ta gestion de ton flot ou de ton flux de projet. C'est-à-dire que pour toi, la notion de complexité, de préparation, de s'assurer que tu respectes des bonnes pratiques, tout ça, pour toi, c'est anecdotique dans cette notion de prédictabilité ?
Geoffrey:
Alors, c'est pas anecdotique. C'est hyper important et c'est le cœur du problème, mais c'est quelque chose qui est beaucoup mieux maîtrisée par les équipes. Aujourd'hui, on a des équipes, que ce soit au niveau de la préparation des projets, de l'écriture des specs, de l'écriture du code, qui ont le nez dans le guidon et qui se focalisent uniquement là-dessus. Et ça, ils le font très bien. Ce qui pose problème et ce qui fait que des fois, des projets débordent, ce n'est pas, la plupart du temps, la capacité des devs d'écrire. C'est, on ne se rend pas compte que quelque chose qui semble être un détail, petit côté effet papillon qui arrive sur le côté, va perturber tout ce système-là. Et donc, on gagnera plus dans le système actuel à éviter justement ces effets de bord non anticipés en protégeant au mieux l'équipe pour qu'elle puisse se focaliser sur son sujet mais aujourd'hui si on. Enferme une équipe dans une pièce et qu'on leur demande de bosser, ça va se passer beaucoup mieux que si on les met dans un contexte d'entreprise aujourd'hui où il va y avoir une urgence, ils vont devoir répondre à un mail parce qu'il y a un investisseur qui pose une question et on va vouloir lui répondre, rapidement pour envoyer une bonne image c'est tous ces éléments là qui vont venir perturber notre mode de fonctionnement et aujourd'hui quand on estime, quand on projette sur une nouvelle feature ils sont complètement en dehors de la photo donc forcément il y a la photo idéale du projet qu'on veut et il y a l'environnement réel dans lequel il va être mis au jour et c'est cette différence là qui va apporter beaucoup de retard souvent et d'échanges inutiles et de nécessité de repasser sur le sujet ou de poser le sujet le temps d'aller faire autre chose et de revenir et donc aujourd'hui c'est là dessus qu'il faut avoir le focus parce que c'est un peu l'angle mort ouais.
Bruno:
Moi, pourtant, dans mon expérience, j'ai l'impression que le plus gros impact sur les délais de livraison, sur les estimations, va plus se jouer sur des éléments qu'on n'a pas anticipés. Pas dans le sens où tu as un élément extérieur qui vient de parasiter parce que tu as un nouveau projet qui vient popper ou une réunion qui arrive ou des gens qui te dérangent, mais c'est qu'à mesure que tu avances dans la réalisation de ton projet, tu découvres qu'en fait il y a un élément qu'il faut que tu modifies, qui est plus difficile à modifier que ce que t'imaginais, parce que soit en fait il faut que tu ailles plus loin ou parce que tu tombes sur un truc qui pue et en fait il faut que tu le corriges tu vois que t'es plus impacté par des choses qu'on n'a pas su sizer à la bonne taille que des éléments extérieurs qui viennent te déranger.
Geoffrey:
Alors effectivement ça c'est des choses qui sont très coûteuses et en fonction de alors c'est pas tant une question de magie de maturité mais d'utilisation de l'agilité ou des principes, ça peut devenir beaucoup moins douloureux typiquement si on fait en sorte que toutes les compétences nécessaires à mener un projet à bien fassent partie de l'équipe qui bosse dessus, Donc vraiment équipe au sens squad, au sens délivrerie. Ces problématiques-là vont pouvoir être adressées assez rapidement pour pouvoir éviter ou minimiser l'impact négatif de ce changement d'avis ou nécessiter de revoir quelque chose parce qu'on n'avait pas tout anticipé. C'est vrai qu'à partir du moment où ces questionnements qui arrivent et étant donné qu'on fait jamais les mêmes features, ce serait illusoire de penser qu'on peut les éviter totalement ou alors le temps de préparation des projets deviendrait colossal, en comparaison, donc l'idée c'est tant que ces questionnements sont à cheval sur plusieurs équipes là on est dans un système qui va être compliqué parce que les équipes ne sont pas forcément disponibles de manière instantanée les unes pour les autres, même si elles le souhaitent, ce n'est pas toujours le cas. Donc, tant que ces questions et que ces problématiques sont cross-équipe, oui, là, ça va générer du délai. Si on arrive à en faire en sorte que toutes ces questions soient au sein même de l'équipe, généralement, ça se résout naturellement et de manière assez fluide.
Bruno:
Mais sauf que tu ne peux pas avoir une équipe de 200 personnes.
Geoffrey:
Non.
Bruno:
Il y a quand même un moment où tu es obligé de découper. Donc, tu ne peux pas avoir, en fait, une seule équipe. Enfin, c'est très rare les contextes où tu as une seule équipe qui va gérer toute la... qui va avoir une vision suffisamment globale pour pouvoir adresser toutes les problématiques ?
Geoffrey:
C'est la question du découpage. Effectivement, l'idée, c'est pas forcément de... Parce qu'il y a des projets qui ont une ampleur telle que, de tous les cas, il n'y aura pas qu'une seule équipe qui va bosser dessus. Le tout, c'est d'arriver à isoler le projet, à le découper en sujets qui peuvent être traités de manière autonome. C'est pas toujours facile, c'est pas toujours possible, mais quand c'est possible, ça va générer... Enfin, ça va faciliter énormément les choses et fluidifier le flux de... le process de délivrerie et de création de valeur. Et tous les éléments qui ne cochent pas ces cases-là parce qu'il y en a et il ne faut pas penser qu'on va pouvoir les éviter coûte que coûte. Il y en a, il faut les adresser. Il faut juste avoir beaucoup plus d'attention et peut-être laisser plus d'espace pour les gens, pour pouvoir les faire passer de manière, clean, sans doute là.
Bruno:
Mais tu peux pas juste considérer que, ok, là on a dit que tel projet ça va nous prendre X jours, on sait qu'on a une capacité ou non à voir dans les projets des choses qui vont être plus compliquées à faire que ce qu'on imaginait, donc si on nous dit que ça prend X jours, on va dire que ça prend X plus Y parce qu'en fait on a notre, enfin X plus A parce qu'on a notre constante notre constante où on sait qu'il nous faut X% de temps en plus pour chaque projet. Tu penses que c'est aussi mathématique que ça ?
Geoffrey:
Non, ce n'est pas mathématique et dans tous les cas il faut s'adapter. Le tout c'est d'essayer et c'est là l'intérêt de l'approche agile des équipes qui visent à chercher l'amélioration continue. C'est de réussir à détecter les sources de bruit ou les sources de rework ou les sources de perte de temps et de trouver des manières de les adresser. Donc non, ce n'est pas du tout mathématique. Mais de ce que je vois aujourd'hui dans l'organisation chez les Furets et dans d'autres boîtes, cette source-là va plus souvent venir du contexte dans lequel l'équipe est quand elle doit livrer le projet que du projet lui-même. Il y en a dans le projet et c'est indéniable et il y en aura toujours le tout c'est que ces éléments là sont souvent beaucoup mieux adressés beaucoup plus faciles parce que les équipes sont plus l'habitude de ce genre de gymnastique il y a un rebondissement sur notre besoin ou il y a une contrainte en plus qui vient de se rajouter, il y a quelqu'un qui débarque sur le projet et il va falloir changer quelques lignes les équipes ont l'habitude et savent absorber ce genre de choses, pour moi là où il y a le plus de gains ou là où il y a le plus de problématiques qui pop sans qu'on les anticipe et sans qu'on ait réellement l'habitude de les gérer c'est vraiment sur l'environnement qu'il y a autour.
Bruno:
Donc, c'est toutes les perturbations côté autre que la tech, en fait, ça que tu...
Geoffrey:
Autre que la tech, des fois, technique aussi. Mine de rien, si j'ai un projet qui est censé prendre quelques semaines et qu'en plein milieu, je me retrouve avec une énorme fuite de données ou un ransomware, forcément, les équipes techniques vont être sollicitées et forcément, ça va impacter le rendu du projet. Donc, c'est sûr que sur des éléments de cette ampleur, on s'en doute, mais sur d'autres éléments, les personnes qui les déclenchent et qui ont toute la légitimité de le déclencher pour des vraies raisons, ne se rendent pas forcément compte de l'impact que ça va avoir sur le système en soi. Il faut vraiment voir ça et c'est pour ça que l'analogie avec l'autoroute marche sur pas mal d'aspects. On peut très bien se dire que sur toutes les autoroutes de France, on va libérer une voie pour les ambulances. Comme ça, s'il y a un accident, on sait que de manière sécurisée, elles vont pouvoir passer dans les meilleurs délais et ce sera au mieux pour les personnes qui seront dans l'ambulance ou pour les pompiers qui auront besoin d'intervenir. Le fait est que cette décision-là, elle va impacter tous les autres véhicules, parce qu'au lieu de passer sur trois voies, ils passent sur deux voies, ou au lieu de deux voies, ils vont passer sur une voie. Donc ça va impacter tout le reste du trafic. Donc il faut le savoir et il faut le mesurer. Et après, on peut très bien se dire qu'on veut un système où toutes les voies sont occupées, mais si on a besoin de faire passer une ambulance, on fait en sorte qu'il y ait une voie qui se libère. Mais ça veut dire qu'il faut avoir beaucoup plus d'attention parce que si c'est embouteillé la voie elle va pas se libérer comme par magie donc il faut être beaucoup plus attentif sur comment est-ce qu'on remplit et comment est-ce qu'on alimente notre voie et notre flux.
Bruno:
La gestion des embouteillages est souvent utilisée pour illustrer l'effet rebond, on voit dans les chiffres qu'en fait le taux d'embouteillage d'une route reste à peu près constant que tu rajoutes une voie ou tu retires une voie c'est à peu près pareil, est-ce que si on reprend cette analogie de la fast track sur les projets parce que c'est ce que tu décris en fait c'est que tu laisses une capacité, à pouvoir, traiter des projets de manière rapide si jamais hip hop, est-ce que du coup dans cette même analogie en fait le taux d'occupation de l'équipe reste au final quoi qu'il arrive, si t'avais une équipe qui était surchargée avant ou qui était sous-chargée avant, si tu rajoutes cette fast track en fait tu changes pas leur taux d'occupation parce que en fait le temps alloué, reste chargé à la même proportion que ce qu'il était avant. Et que du coup, tu ne fais que rajouter, une... Une voix de plus qui va ramener du projet en plus ?
Geoffrey:
Alors, la chose, c'est que pour rajouter une fast track ou pour rajouter une voix en plus, il faut forcément rajouter des capacités dans l'équipe, donc rajouter des gens. Et aujourd'hui, on sait que quand on a un embouteillage en termes de delivery, en termes de feature, rajouter du monde, ça n'aura pas d'impact positif avant plusieurs mois ou plusieurs semaines. Et quand on rajoute une voix dans une équipe qui reste ISO en termes de delivery, on la rajoute au détriment du reste du delivery, et certes on va augmenter la saturation sur les autres voies mais on va avoir une voie qu'on va contrôler beaucoup plus le tout c'est comment équilibrer c'est toujours une question de positionner le curseur au bon endroit, comment est-ce qu'on va équilibrer la contrainte pour gagner les avantages d'avoir cette fast track, sans détériorer totalement ce qui n'est pas dans la fast track, parce que sinon on va rentrer dans un cercle vicieux où on va essayer de tout faire rentrer par la fast track et au final elle va se retrouver aussi embouteillé que le reste et le reste sera vide. Alors je sais pas s'il y a déjà eu des cas où au final la fast track était embouteillée et le process standard lui devenait fluide parce qu'on l'avait tellement vidé qu'il devenait fluide mais c'est là qu'il faut essayer de bien équilibrer. Donc on a déjà essayé dans certaines équipes. Il y a une équipe où on a donné des jokers au project owner en leur disant il y a une fast track, on a un process de délivrerie sur lesquels on va vous garantir que, là où on perdait du temps c'était des temps d'attente le ticket est terminé on attend que quelqu'un passe pour faire de la code review puis après on attend que quelqu'un passe pour faire la validation ou ce genre d'étape, et bien il y a certains tickets sur lesquels on va s'engager pour qu'il n'y ait pas de temps d'attente dès que le ticket aura besoin d'être validé si quelqu'un doit arrêter de faire ce qu'il fait pour aller le valider il le fera. Donc là, on voit bien l'impact transverse que ça va avoir sur d'autres sujets qui n'ont rien demandé. Mais c'était une volonté de le faire pour permettre à certains sujets d'aller plus vite. Et l'équilibre que l'équipe avait trouvé, c'était de dire, on peut vous le garantir, mais vous avez le droit à trois tickets à un instant T. Et si vous voulez en rajouter un autre, vous êtes obligé d'attendre qu'il y en ait un qui se libère. Donc c'était un peu un Kanban dans le Kanban. Parce que le but de Kanban, c'est de limiter les... Au moins au niveau industriel, au niveau de Toyota, c'est de limiter les cartes c'est de ne pas commencer une nouvelle voiture tant qu'on n'a pas libéré la carte qui est associée à une voiture. Et on avait ça à l'intérieur, on en avait un spécifique pour notre fast track. Et on s'était mis en... Au final, on avait convergé vers un système qui était beaucoup plus vertueux. C'est que plutôt que de générer une frustration en se disant « Ben mince, j'ai utilisé mes trois jokers et là j'ai une urgence, qu'est-ce que je fais ? » Eh ben, les product owners gardaient un joker en se disant « Ben, j'en ai un comme ça. Si demain, j'ai vraiment une urgence, si j'ai un incident, ben je l'utilise. Et au final, je n'ai même pas besoin de paniquer et de me mettre dans un mode branle-bas de combat où tout va être posé pour pouvoir régler l'incident. On savait que naturellement, notre process nous permettait d'absorber une gestion d'incident le plus vite possible sans pénaliser le reste. Ou du moins, en pénalisant le reste de la même manière qu'on le pénalise tout le reste du temps en décidant d'avoir une fast-track. Là où ce qu'on a du mal à mesurer c'est quand on était dans un mode incident. Où on avait vraiment une ambulance à faire passer on le faisait parce qu'il faut qu'on gère nos incidents et qu'on règle nos problématiques. Mais au moment où on le faisait on ne savait pas l'impact que ça allait avoir sur nos projets, là où en gérant notre fast track de cette manière nos projets continuaient à être traités de la même manière et nos estimations restaient bonnes et nos projections restaient bonnes mais on avait quand même une capacité à traiter très vite certains sujets quand on en avait besoin, Donc, dans le meilleur des cas, c'était juste des projets qu'on avait envie de livrer un peu plus vite. Et quand on avait des incidents ou un expédite, il passait par cette ligne-là aussi, parce qu'on faisait en sorte de garder de la place pour lui.
Bruno:
Ok. Je comprends l'intérêt de cette notion de fast track quand tu es dans un environnement, on va dire waterfall ou cambant, où tu as besoin, effectivement, parfois, du coup, de pouvoir bypasser tout ce qui peut être déjà dans une file d'attente. Mais si tu es dans une méthodologie Scrum, du coup, tu fonctionnes par sprint, rien ne t'empêche d'un coup changer complètement le paradigme d'un sprint à l'autre et du coup de passer justement sur cette notion de fast track ?
Geoffrey:
La fast track dans un sprint je ne sais pas trop l'impact que ça peut avoir à part sur la partie théorique je n'ai pas trop creusé la partie Scrum, mais idéalement si on veut que Scrum fonctionne il faut respecter la contrainte et la contrainte c'est le sprint donc une fois que le sprint a commencé on n'y touche plus Ce que je veux dire.
Bruno:
C'est que dans un contexte de sprint rien ne t'empêche de faire ton sprint et quand tu l'as terminé plutôt que de faire ton nouveau sprint qui est la continuité du sprint d'avant, tu peux justement avoir cette notion de fast track où en fait tu changes complètement ton backlog, tu mets en top, des trucs nouveaux qui vont du coup...
Geoffrey:
Mais ça veut dire que la réactivité elle est à un sprint et quand il y a un incident tu peux pas te permettre d'attendre la fin du sprint pour pouvoir l'adresser, Bah généralement l'analogie qu'on fait...
Bruno:
Après le contenu d'incident c'est un peu différent l'incident en tant que tel te nécessite de, entre guillemets, lever le crayon et on corrige le problème ?
Geoffrey:
Le tout, c'est le coût de lever le crayon. C'est qu'on a besoin de le faire, donc on le fait, mais ça va avoir un coût parce que, mettons qu'il y a un incident et qu'il faille une semaine pour le résoudre parce que c'est un incident complexe, si ton sprint, il fait deux semaines, ça va l'impacter énormément. Donc, il faut essayer de faire en sorte qu'un incident soit un no-brainer dans le process de délivrer, qu'on puisse l'absorber sans impacter le reste négativement parce que, si on le fait, on va forcément nuire à la prédictibilité du système.
Bruno:
Ou on peut aussi essayer de faire en sorte qu'il y ait moins d'incidents. Quand on parle de fiabiliser l'usine logicielle, moi, c'est surtout ça que j'avais en tête. C'est comment tu fais pour que tu aies zéro incident en prod ? On est d'accord que ça a peu de chance d'arriver, mais c'est un peu ton objectif.
Geoffrey:
Oui, l'objectif, c'est de ne pas avoir d'incidents. Après, il faut prévoir un process de délivrer qui permettra de les gérer, même si on n'en a pas. Parce que si on en a un, il faut qu'on soit en mesure de pouvoir apporter une réponse rapidement. Et même si on essaie de faire en sorte qu'ils servent jamais, c'est un peu comme les défibrillateurs qu'on installe dans tous les immeubles on espère qu'ils serviront jamais mais on préfère qu'ils soient là et bah c'est la même chose, la différence c'est que, ou non c'est à peu près la même chose c'est qu'un défibrillateur une fois qu'il a été utilisé on va pas pouvoir le réutiliser tout de suite à vérifier, j'ai jamais fait le test mais si je ne m'abuse, la batterie n'est pas éternelle normalement et c'est de mettre des batteries c'est pas des batteries atomiques des piles atomiques donc j'imagine qu'au moment il va falloir les changer il faut qu'on essaie au maximum d'éviter, enfin il faut qu'on essaie au maximum de sortir d'un système dans lequel, on a un coût hyper élevé à gérer ce genre d'urgence il faut faire en sorte que on puisse les gérer de manière naturelle sans déstabiliser tout le reste, sans nécessiter derrière d'avoir un technicien qui va venir pour changer soit la batterie ou soit changer tout le mécanique, parce que oui on peut le faire mais ce sera plus coûteux qu'un système qui est capable d'absorber ça sans qu'on ressente. Nécessairement derrière un besoin d'investissement particulier, De la même manière, au tout début, chez les Furets, et ça, Dimitri en avait parlé quand il était dans le podcast, on livrait une fois par mois. C'était le cas quand je suis arrivé chez les Furets. Et une des premières questions qu'il a posées en arrivant, c'est « mais quand vous avez un incident, vous attendez le mois suivant ou votre process de release ? » Et on lui a dit « bah non, on arrête tout et on fait en sorte de pouvoir livrer le lendemain ou le jour même. » Et là, il nous a posé une question qui nous a un peu secoué, c'est « si vous êtes en capacité de livrer le jour même, pourquoi est-ce que vous n'utilisez pas cette capacité-là tout le temps ? Et si un jour vous avez un incident à gérer et que vous avez une urgence, vous utilisez le même process et ça vous évite d'avoir automatisé deux process de délivrer. Parce que du coup, à l'époque, on en avait un pour partir vite pour les incidents et un qui nous permettait de livrer tous les mois. Donc voilà, l'idée, c'est de se dire qu'une solution qui nous permet de gérer la pire situation, si on peut la généraliser pour qu'elle puisse nous aider, à traiter tous les sujets, autant uniformiser et utiliser une solution pour tout et donc c'est la même chose sur le delivery, c'est plutôt que de se dire qu'on a un process de delivery et qu'on accepte de tout bousculer le jour où on a un incident parce qu'on veut traiter l'urgence. On est dans un moment de panique et on a besoin de trouver une solution autant imaginer un système qui nous permet de traiter et le process standard et ces éléments là mais de manière naturelle sans avoir besoin de poser le crayon ou de tout arrêter et de changer drastiquement notre manière de fonctionner.
Bruno:
Mais du coup ce que tu expliquais tout à l'heure avec le principe de cette fast track sur certaines équipes pour faire délivrer des projets rapidement du coup on pourrait, te poser la même question si tu as une capacité à délivrer des projets rapidement pourquoi tu ne l'appliques pas à tous tes projets et en fait la nécessité de ta fast track c'est justement, de garder un truc disponible pour que le jour où tu as besoin d'aller plus vite tu es capable d'aller plus vite donc ça a du sens d'avoir deux modes de délivrer parce que t'en as besoin qu'il y en ait un qui aille plus vite que l'autre.
Geoffrey:
En fait c'est le même mode de délivrer mais avec des priorités différentes, il y en a un qui va être plus prioritaire que l'autre mais le process dans les équipes était exactement le même, les étapes étaient les mêmes, c'est juste qu'il y avait plus d'attention pour faire en sorte que ceux qui étaient dans la fast track n'attendent pas donc c'était une subtilité dans le process mais globalement les deux process les deux vitesses de délivrer étaient les mêmes et on ne pouvait pas garantir une fast track si on n'avait pas la majorité des sujets qui passaient dans le process standard Mais du coup.
Bruno:
Dans ton déploiement, dans ta mise en prod ? Si c'est normal d'avoir deux fonctionnements différents sur tes projets, ça peut être normal d'avoir deux fonctionnements différents sur ta mise en prod ?
Geoffrey:
Alors, à l'époque où on faisait ça, dans la mise en prod, tous les sujets étaient traités de la même manière. Dans la mesure où on mettait en prod tous les jours, parce qu'on est passé d'une mise en prod par mois à une mise en prod par jour. Dans la mesure où on met en prod tous les jours, voire plusieurs fois par jour quand c'était nécessaire. Quand on avait un sujet qui nécessitait d'être mis en prod rapidement, il pouvait être mis en prod le jour même si le dev était fini. En gros notre process de mise en prod il prenait tout ce qui était prêt et il le livrait et donc ce que changeait notre fast track c'était le temps entre le moment où on nous demande de traiter le sujet et le moment où le sujet est flagué comme prêt à partir mais une fois qu'il est prêt il part, donc notre process de mise en prod n'était pas différent pour les éléments de la fast track et pour les éléments du process habituel tu.
Bruno:
Disais tout à l'heure que quand Dimitri est arrivé il vous a dit vous délivrez tous.
Geoffrey:
Les mois si.
Bruno:
Vous pouvez délivrer tous les jours pourquoi pas délivrer tous les jours sur tous les trucs mais en fait si sur la fast track c'est logique d'avoir deux process différents pourquoi est-ce que c'est pas logique sur tes releases d'avoir une release différente en mode normal et une release en mode incident.
Geoffrey:
Alors.
Bruno:
Tu vois ce que je veux dire ou.
Geoffrey:
Pas ? oui oui je vois, au bout du moment je pense voir tu me diras à l'époque ce qui différenciait c'est qu'on avait des process automatiques techniques de releases différentes, qu'on a mergé en un seul, là où sur la fast track c'est vraiment une meilleure allocation de la disponibilité de l'équipe, à l'époque ce qu'on faisait c'est que quand il y avait une... qui.
Bruno:
Est du coup adapté à un contexte d'urgence donc ça peut être pareil sur ta release tu vois j'essaie de voir pourquoi est-ce que t'as un contexte où t'acceptes d'avoir deux process et un autre contexte où tu considères que autant en avoir qu'un seul.
Geoffrey:
Ah alors du coup je pense avoir compris. Effectivement l'idée c'est idéalement on a envie d'utiliser d'avoir une seule solution pour résoudre un problème et donc on a une version, qui est prête à partir en prod j'ai envie d'avoir une seule solution qui permet de l'envoyer en prod et pas 5 en fonction de différents cas et on avait exactement la même chose pour le delivery donc là sur la partie fast track on est vraiment entre le besoin et le moment où le code est prêt, et à la base L'équipe avait un fonctionnement unique qui était, on prend le ticket, on demande une priorisation, on prend le plus prioritaire et on avance. Mais on s'est rendu compte que cette solution-là, qui était donc la plus simple, n'était pas suffisante parce qu'il y a des sujets qui sont d'urgence et on avait besoin de les traiter. Donc, on a commencé à rajouter de l'expédite. On avait une ligne expédite qui était tout le temps vide, mais quand on avait une urgence ou quand on avait un incident, on arrêtait tout et on le faisait passer. Mais on s'est rendu compte que ça détériorait énormément le délivrerie de tous les autres sujets. Et donc la démarche de l'équipe à l'époque pendant les rétros et pendant les échanges ça a été de se demander est-ce qu'on peut essayer de garantir ce délivré rapide si nécessaire en impactant le moins possible le reste et donc c'est là que la solution, uniforme, enfin unique de traitement des tickets est arrivée à ses limites et que l'équipe a envisagé cette solution à deux vitesses et donc elle a accepté de maintenir, parce que c'est un effort supplémentaire un système à deux vitesses. Pour avoir ce côté j'arrive à être plus rapide sur les sujets importants et après ils l'ont étendu en se disant si j'arrive à le faire sur les expédites je peux peut-être le faire sur un peu plus de sujets et après le tout ça a été de trouver à quel point on pouvait, garantir cette vitesse supplémentaire mais donc à la base c'était pas la volonté, si ça a été mis en place c'était vraiment parce qu'il y avait un besoin de traiter certains sujets plus vite sans impacter le reste Ok.
Bruno:
Donc pour toi sur cette notion de fiabilisation de l'usine logicielle on a parlé effectivement de l'avant comment c'est à coder, on a parlé un peu de l'après, est-ce qu'il y a des choses qu'on peut faire sur le moment où on écrit du code ?
Geoffrey:
Au moment où on écrit du code, oui si on veut être prédictible et si on a envie, surtout ce qu'on cherche, et c'est le manifeste agile qui nous dit mais d'apporter de la valeur à l'utilisateur le plus vite possible ou dans un délai cohérent par rapport à la valeur qu'on est en train d'ajouter il faut faire en sorte que. Quand le dev est en train de bosser, il ne perd pas son temps. Et donc, ne pas perdre son temps, forcément, ça veut dire qu'il faut qu'il ait des outils pour coder, qu'il soit adapté en termes d'IDE, en termes d'outillage, en termes de CICD, il faut avoir des outils qui sont adaptés. Et il faut à la fois qu'il ait un maximum de choses pour lui faciliter le travail. Donc, il ne faut pas imaginer un dev tout seul dans sa cave en train de bricoler avec ce qui tombe sous la main pour essayer de fabriquer quelque chose. Non, il faut le mettre dans un environnement dans lequel les outils sont bien rangés, les ressources dont il a besoin sont accessibles. Il faut le mettre dans un dans un parc, enfin un parc, au sens dans une aire de jeu où il va pouvoir travailler le plus efficacement possible en prenant le moindre risque possible. Et donc, ça veut dire qu'il faut que son environnement soit réellement pensé pour lui. Pas individuellement, mais construire un environnement dans lequel, s'il veut déployer, il va pouvoir le faire facilement, qu'il n'ait pas besoin de se battre avec la CICD pour déployer. S'il a besoin de lancer des tests, qu'il puisse avoir un feedback rapide, donc ça va dépendre de lui, parce que la durée d'exécution des tests dépend des tests qu'il écrit, mais ça va aussi dépendre de l'environnement technique qu'on lui propose autour. La CI, les environnements de test, il faut faire en sorte qu'ils aient des environnements, idéalement disponibles en quelques minutes, s'ils ont envie de tester quelque chose, ou d'échanger avec quelqu'un du métier. Donc l'idée, c'est de réduire toutes les barrières. Mais il faut être attentif quand on cherche à réduire toutes les barrières, parce qu'il faut que les devs ou les ingés restent au maximum autonomes sur cet environnement-là, alors que ce n'est pas du tout leur cœur de métier. Gérer des environnements, gérer de l'infrastructure, ce n'est pas le métier d'un développeur full stack, d'un développeur front, d'un développeur back ou d'un data analyst. Par contre, s'il doit dépendre d'une équipe qui gère l'infrastructure à sa place, dès qu'il y a quelque chose qui ne va pas se passer idéalement, dès qu'il va vouloir un environnement mais qui ne sera pas dispo, il va devoir attendre. Il va devoir demander et donc là forcément, on va lui faire perdre du temps. Donc c'est hyper important de créer un environnement sur mesure par rapport aux besoins des équipes, mais de les rendre autonomes dessus. Donc, c'est là que des approches comme sur la partie infrastructure, l'infrastructure as a product, faire en sorte que de mettre des solutions sur étagère et de les documenter et d'accompagner les équipes pour les mettre en place et les utiliser va avoir un vrai impact sur le delivery parce que le jour où un déploiement ne marche pas, le dev aura plus de facilité à soulever le capot ou à faire ce qui est nécessaire pour se débloquer lui-même et avancer. Même si pareil idéalement on veut faire en sorte qu'il ait la solution la plus stable donc l'idée c'est ça, c'est de les mettre dans une aire de jeu dans laquelle ils vont pouvoir s'épanouir travailler le plus efficacement possible en essayant de les abstraire de toutes les problématiques qui ne les concernent pas pour qu'ils se focalisent sur une chose écrire le code qui va apporter de la valeur métier et pas, écrire le contexte dans lequel on pourra mettre du code qui apportera la valeur métier et donc ce contexte là il faut réussir à le créer avec ou pour eux et à les rendre autonomes dessus. Pour qu'ils puissent le faire évoluer par rapport à leurs besoins. Parce que c'est idéaliste de se dire qu'on va imaginer ce dont ils ont besoin et le préparer pour eux et après ils n'auront plus qu'à aller dedans. Ce n'est pas une aire de jeu pour enfants. Là, l'idée, c'est de construire quelque chose et de leur mettre sur étagère tout ce qu'ils ont besoin pour pouvoir faire évoluer leur propre système. Une espèce de Minecraft pour développeurs où on leur garantit qu'ils vont avoir accès à ce dont ils ont besoin pour pouvoir bosser. Et donc, ça vaut pour leur environnement de travail pour écrire le code. Ça vaut pour les contextes, les environnements d'exécution, de showcase, staging, pré-production avant d'aller en production et sur tous les outils qui vont leur permettre de se focaliser encore une fois sur la création de valeur pour nos utilisateurs.
Bruno:
Je suis sceptique sur quelques aspects sur ce que tu viens d'évoquer. J'aime bien l'idée du parc. Je suis moins fan du côté un peu infantilisant que ça peut représenter. J'adore la notion d'autonomie, mais le problème dans ce que tu décris, c'est qu'il y a un côté complètement isolationniste du contexte. C'est-à-dire qu'à part quelques cas où effectivement tu devs en étant tout seul dans ton équipe et qu'il n'y a que toi qui fais ton truc, fine. Mais dans la mage, tu as des cas, en fait, tu ne devs pas tout seul. Tu fais partie d'une équipe qui, parfois, elle-même, fait partie d'un conglomérat d'équipe. Et donc, en fait, ton travail, ce que tu produis, va impacter le travail des autres. Je prends un exemple tout bête. Tu disais tout à l'heure, il faut qu'il ait une série CD qui soit à disposition. Il ne faut pas qu'il soit embêté par ces tests et compagnie. Si moi, je pousse en prod quelque chose et que je ne mets aucun test dedans, je suis emmerdé par aucun test. Et en fait, mon passage en prod se passe entre guillemets très bien. En revanche, mes petits camarades derrière qui vont aller reprendre mon code, peut-être que du coup, ils vont déclencher des problèmes, des effets de bord, des bugs, parce qu'en fait, mon code n'est pas testé. Enfin bref, on connaît tous les problèmes que ça peut engendrer. Donc tu vois, dans cette image que tu as de l'autonomie, le problème, c'est que justement, le dev... De manière très intrinsèque, n'est pas un métier solitaire, en tout cas très rarement, et on ne deve pas en toute autonomie.
Geoffrey:
Oui, alors oui, effectivement, là, je me suis focalisé uniquement sur la partie outillage, mais derrière, il y a une question de standard, c'est qu'effectivement, ce qu'on produit, on va le réinjecter dans un système qui est assumé par d'autres personnes que nous-mêmes, et donc, le test, c'est une bonne chose. C'est le rôle, notre rôle c'est de mettre en place un environnement dans lequel on pourra exécuter des tests avoir des feedbacks rapides et si besoin déployer des environnements pour pouvoir tester dessus la responsabilité du dev. Elle est aussi importante, c'est que derrière il va falloir définir un certain nombre de standards, alors on peut parler de couverture de test on peut parler de documentation on peut parler d'un certain nombre de choses c'est qu'il y a aussi une partie du contrat qui doit être respectée par l'équipe mais c'est mettre l'équipe dans une situation dans laquelle elle va se focaliser sur, encore une fois, développer la feature et pas faire tourner le serveur qui va héberger la feature, il faut lui faciliter l'accès au serveur dont elle aura besoin, mais derrière on s'attend pas juste à ce qu'elle l'utilise comme elle le souhaite et après on regarde ce qui se passe il y a un certain nombre d'attendus en retour. Certes on va leur donner sur étagère des solutions, mais il faut derrière qu'ils nous garantissent de les utiliser correctement de les monitorer de brancher des alertes pour qu'on se rende compte si leur service est tombé donc il y a tout un ensemble de contraintes qui sont aussi un contrat qui sont censés respecter, derrière pour pouvoir rendre quelque chose le tout c'est qu'ils puissent bosser en autonomie dessus au maximum et si besoin on leur rajoute les capacités dont ils ont besoin en allant chercher des expertises ailleurs et en mettant des personnes transverses ou en lead sur certains sujets mais on leur donne les compétences dont ils ont besoin pour travailler mais derrière en étant hyper exigeant et en standardisant le rendu et les attentes autour du rendu et pas seulement sur le code on vous permet de tester le code facilement, En retour, on s'attend à ce que le code soit testé. Et s'il n'est pas testé, on ne l'acceptera pas et on ne le livrera pas.
Bruno:
C'est ça que je trouve intéressant dans ce concept, surtout dans le choix du mot. On parle d'usine judiciaire. On compare au taylorisme, on compare à ce qui se passe dans les entrepôts Amazon. En fait, on a essayé de simplifier au maximum le geste ou l'opération qui est faite par chaque opérateur de manière à éviter les erreurs accompagnées. Donc en fait, chaque individu est réduit à un geste extrêmement simple, où tous les gestes se font à la chaîne, et c'est ce qui fait la globalité. Nous, clairement, en tant que dev, on ne peut pas arriver à cette simplification-là de notre métier. Et donc, ce qui est particulier, c'est que dans une usine, tu peux mettre en place un ensemble de tests qui sont conçus de manière très globale, et qui vont te permettre de valider que ce qui sort est valide et tu l'envoies chez le client. Parce qu'en fait si t'as eu sur un produit le tampon CE qui te permet de vendre ton produit dans la communauté européenne. Ça vaut pour tous les produits qui sortent derrière en fait, à peu de choses près là où nous effectivement dans le monde de l'aide on peut pas avoir cette approche là et en fait ce que tu décris est hyper intéressant parce que ça veut dire que t'es obligé, d'embarquer chacun des individus dans une propre démarche. En fait, chaque individu peut complètement s'empêcher de ta chaîne de montage. Tu peux avoir un dev ou un développeur ou une développeuse de ton équipe qui va lui décider de ne faire aucun test et qui met du coup à mal toute cette notion de fiabilité ou de prédictabilité de ton usine logicielle. Parce qu'en fait, ça repose sur chaque individu et autant responsable que son voisin. Donc, c'est pas juste un truc que tu peux définir toi en tant que principal ingénieur. il faut que tu arrives à emmener les gens avec toi dans cette démarche là Effectivement.
Geoffrey:
Après il y a aussi une vraie différence et il y a deux mondes qui se confrontent quand on développe des fonctionnalités et quand on ajoute quand on veut rajouter de la feature et apporter de la valeur à nos utilisateurs c'est effectivement il y a la partie usine logicielle, mais c'est une usine dans laquelle on va construire de l'artisanat et les personnes qui vont travailler vont plus ressembler à des artisans, qu'à des personnes qui travaillent à la chaîne la partie usine c'est une fois que j'ai mon code le code il faut le compiler il faut lancer des tests il faut le packager il faut le déployer sur des environnements qui ont été installés qui ont été configurés sur lesquels on a mis toutes les librairies ça c'est quelque chose si on demandait au dev de le faire en 2025 déjà on aurait du mal à recruter je pense, et ce serait une perte de temps parce qu'au final on se retrouverait au ratio. Entre le temps alloué par les équipes de dev à produire de la valeur pour nos utilisateurs et le temps alloué à faire en sorte que ce soit possible, similaire au ratio d'une fusée la charge entre la charge utile d'une fusée et le poids réel de la fusée avec tout le carburant et donc ce qu'on cherche à faire c'est avoir un ratio qui est beaucoup plus cohérent et beaucoup plus optimal faire en sorte que 80% du temps qu'un dev passe ce soit pour la charge utile et pas pour gérer donc la partie qui pour moi est. Industrialisée qui est l'usine logicielle c'est vraiment comment une fois que j'ai fait mon produit... Je vais pouvoir automatiquement le mettre dans une boîte à taille adaptée, gérer automatiquement la livraison, gérer les livreurs, faire en sorte que toute cette partie-là soit automatisée. Et c'est là qu'il y a une partie usine qui est hyper répétable parce que les actions restent les mêmes. Et en amont de ça, on va avoir des développeurs qui eux vont vraiment faire du sur-mesure, on leur apporte une nouvelle problématique, et eux ils vont avoir besoin de construire une solution et donc la solution, ils ne savent pas encore ce que ça va être, donc on leur met un bloc de marbre on leur met un établi avec plein d'outils différents et c'est à eux de choisir quel outil utiliser par rapport à la statue qu'on leur a demandé de tailler, et donc là c'est une partie qui est vraiment artisanale, mais une fois que la statue est faite ils la donnent et là on a un système qui est hauteurment automatique et qui est industriel et similaire à ce que peuvent faire toutes les usines, tu parlais de taylorisme toutes les usines de traitement avec la partie répétition de une fois que j'ai mon colis comment est-ce que je m'assure qu'il arrive à bon port dans des bonnes conditions sans être cassé et la question c'est l'interface entre les deux. Si je me contente de dire fais ton taf et après mets-le sur un tapis roulant et puis après ça va partir, effectivement je suis dépendant alors après je peux aussi choisir de faire confiance aux gens et d'être plus attentif au recrutement mais je suis dépendant de la bonne volonté des gens et de l'implication et donc ça va dépendre de toute l'équipe et plus je vais grossir, plus ça va être hétérogène. Parce que certaines personnes vont être hyper attentifs à un détail et d'autres à un autre. Ça ne veut pas dire qu'il y en a un qui est meilleur que l'autre, mais on ne va pas avoir d'homogénéité. Et quand on écrit du code, on a envie d'être homogène parce que j'ai envie de pouvoir prendre n'importe quel dev et de le mettre sur n'importe quel sujet si un jour j'en ai le besoin, en cas d'urgence ou je sais quoi, et que le développeur soit à l'aise et efficace pour avancer. Et donc, cette question, c'est comment est-ce qu'on gère cette interface-là ? Alors, ça peut se faire de plein de manières. On peut, par exemple, définir un definition of ready ou un definition of done en se disant, une fois que tu as effectivement trouvé une solution, implémenté une solution qui répond à un problème. Qu'est-ce que tu dois me donner avec ou en plus qui me garantira que si je le livre, ça va bien se passer ? Donc, ça peut être, est-ce que tu as écrit des tests ? Est-ce que les tests passent ? Est-ce que quelqu'un d'autre est revenu lire ton code et est d'accord avec toi ? Est-ce que la personne qui t'a demandé la feature a revu le résultat et est aussi d'accord avec toi ? Est-ce que ton code, il est documenté ? Est-ce qu'il est comité au bon endroit ? Est-ce que tu respectes les linter ? Et donc, c'est vraiment toute cette définition de definition of done entre le moment où on fait du sur-mesure, encore une fois, idéalement avec des solutions qui sont sur étagère pour ne pas perdre de temps, et le moment où on intègre tout et là tout devient automatique, au niveau de la livraison mais tout ce qui est en amont, tout ce qui est conception, idéation, résolution du besoin je ne la mettrais pas dans l'usine logicielle parce que là pour le coup on n'est pas sur une usine.
Bruno:
Mais c'est cette image que tu prends du sculpteur à qui on donne un bloc de marbre et il fait sa statue, il y a un côté effectivement très artisanal mais aussi très artistique, et tout ce que tu mets dans la definition of done on est très loin de l'artisanal, on est très loin du côté artistique en fait ma question c'est comment parce que, je pense pas te trahir de secret mais je pense que la majorité des développeurs et développeuses ce qu'on préfère dans notre métier c'est cette partie artistique c'est comment je fais pour réussir à répondre à apporter de la valeur, à mon client ou à la personne qui me demande la future comment je fais pour répondre à un problème pour apporter une solution, Tout le reste, après, il y a un côté justement très usine, très automatique, beaucoup moins intéressant. Donc ma question, qui sera peut-être du coup ma dernière question, c'est comment est-ce que tu fais pour embarquer les gens dans cette démarche-là et faire en sorte que tu n'es pas un artiste fou, un dali qui vienne te faire des trucs magnifiques, mais qui ne fait que ça et qui, petit à petit, fait des trucs qui te font péter l'ensemble.
Geoffrey:
C'est la partie la plus difficile, c'est standardiser le style, parce qu'on n'a pas envie de brider les gens, parce qu'on a envie que la créativité ait un vrai intérêt, trouver des manières différentes de répondre à des problématiques, mais on a envie d'avoir une certaine uniformité. Et ça pour moi c'est pas au delivery de l'assurer parce qu'encore une fois le but du delivery c'est de livrer de la valeur, c'est plus des pratiques à mettre en place de manière transverse entre les équipes pour essayer de standardiser ça en mettant en place que ce soit des tribes ou des communautés transverses pour que les gens justement montrent leurs approches et essaient de créer un langage commun, je parle pas au sens langage informatique mais je parle de pratique et de style pour essayer d'avoir un... Quand on regarde les façades de Paris, elles sont toutes différentes, mais elles respectent un certain nombre de guidelines qui fait que globalement, Paris est une ville homogène. Au niveau de l'urbanisme, c'est homogène, mais chaque bâtiment va être différent, avec des tailles différentes. Mais il y a un certain nombre de choses qui ont été standardisées. La différence, c'est que dans un cas, ça a été imposé par un préfet. Là, ce qu'on veut, c'est que l'équipe s'organise spontanément ou en la guidant et en essayant de donner des guidelines, mais trouve l'équilibre qui lui convient le mieux. Mais ça se fait indépendamment du delivery. Au moment où la personne est en train de sculpter son bloc de marbre, c'est déjà trop tard. Il faut déjà qu'il ait standardisé ses pratiques avec ses collègues pour essayer d'avoir quelque chose qui est cohérent pour éviter d'avoir une statue de type grec et une statue de type, contemporaine l'une à côté de l'autre dans quelque chose, dans un immeuble qu'on a envie d'être homogène.
Bruno:
Et effectivement, quand on a commencé à tailler dans le marbre, c'est trop tard.
Geoffrey:
Et une fois qu'on a commencé à tailler, oui, effectivement, c'est trop tard.
Bruno:
Merci beaucoup, Geoffrey, pour cette discussion. J'aurais deux dernières questions pour toi, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu saurais partager avec l'ensemble des auditeuristes ?
Geoffrey:
Alors oui, qui n'a rien à voir avec le sujet ou avec ma spécialité, mais un petit point que je viens de remonter à l'instant, c'est une chaîne YouTube qui est assez connue maintenant, qui s'appelle Fouloscopie. De Mehdi Moussaïd et donc comme son nom l'indique il étudie le comportement des foules mais ses vidéos ont une approche assez intéressante sur, sur la vision qu'une foule peut apporter sur certains concepts, par exemple sur la connaissance, est-ce que la majorité a toujours raison, sur la créativité est-ce qu'on peut faire en sorte qu'une foule arrive à créer quelque chose de nouveau et de différent que chaque individu sur l'auto-organisation justement donc j'en parlais à l'instant sur comment est-ce qu'on fait en sorte qu'une équipe, arrive à définir ses propres standards spontanément. Et donc, voilà, je trouve que ça a fait sortir un peu de mes habitudes de tech pur. C'est hyper intéressant sur l'approche collective de répondre à certaines problématiques et à certains questionnements.
Bruno:
C'est une super chaîne. Je recommande aussi pleinement cette chaîne.
Geoffrey:
Son livre est intéressant aussi.
Bruno:
Et dernière question, la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation ?
Geoffrey:
Je dirais espace dans le code mais tabulation pour écrire donc c'est juste une question de conversion, encore une fois c'est il y a ce que j'ai envie de faire, j'ai envie d'appuyer une fois sur tab il y a ce que je veux dans le code, un espace et la magie entre les deux, je veux que ce soit un outil qui le fasse à ma place donc tout à l'heure on parlait d'usine logicielle mais là en l'occurrence ça va être l'IDE qui doit faire le reste du chemin.
Bruno:
Top, merci beaucoup Geoffrey.
Geoffrey:
Merci.
Bruno:
Et merci à tous d'avoir suivi cet épisode voilà j'espère qu'on vous a donné quelques clés pour effectivement fiabiliser votre usine logicielle donc ça parle beaucoup d'outils, de process mais aussi d'humains, c'est comment est-ce qu'on fait pour embarquer les gens dans ces sujets là parce que c'est la responsabilité de tous de faire en sorte que toutes les mises en prod et tous les projets se passent dans les meilleures conditions, et comme toujours moi je vous remercie de partager ce podcast autour de vous, n'hésitez pas à aller checker le Patreon si vous voulez soutenir ce podcast je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.
