Dragan Stepanović - Async Code Reviews Are Choking Your Company’s Throughput

[00:00:00] D'accord, bienvenue à tous. Euh, je vais parler d'un sujet légèrement controversé aujourd'hui, qui est les revues de code asynchrones. Et il y a eu beaucoup de discussions sur les revues de code asynchrones récemment, y compris dans l'industrie, comparant les revues de code asynchrones bloquantes et non bloquantes. Ce dont nous allons parler aujourd'hui, ce sont les revues de code asynchrones bloquantes qui sont très répandues dans les équipes avec lesquelles, du moins, j'ai eu l'occasion de travailler. Donc, je m'appelle Dragan Stepanović. Je travaille en tant qu'ingénieur principal senior chez Talabat, qui fait partie du groupe Delivery Hero. Je suis basé à Berlin. Et il y a quelques choses qui m'ont beaucoup intéressé tout au long de ma carrière : la programmation extrême, la théorie des contraintes, le Lean et la pensée systémique. Et ces dernières années, j'essaie de relier les points entre tout cela. Aussi, je me plains sur les réseaux sociaux. Et euh, j'ai vu qu'Alberto venait de se joindre. Mais il y a un fait terrifiant à mon sujet, je mets de la mayonnaise sur ma pizza, alors oui.
[00:01:12] Cool. Donc, euh, Je ne sais pas combien de personnes ont entendu parler de cette citation : 'Personne n'a jamais été viré pour avoir acheté IBM'. Euh, je ne faisais pas partie de l'industrie à l'époque, mais apparemment dans les années 80, IBM avait une énorme part de marché en tant que fournisseur. Et euh, si vous travailliez dans un service d'approvisionnement, vous aviez beaucoup de questions auxquelles répondre si vous ne choisissiez pas IBM. Alors tout le monde a choisi IBM et c'est aussi assez intéressant. Parce que ça vous offre cette protection contre le risque de baisse si quelque chose tourne mal, n'est-ce pas ? Vous avez suivi le troupeau, tout le monde fait la même chose, hé, c'est IBM, qui aurait pu le savoir ? Euh, et puis quand je pense à cette citation, euh, et que je pense aux méthodes de travail que je vois dans les équipes, euh, principalement. Et je suis également curieux de comprendre votre expérience, mais c'est un peu une image que j'ai en tête. Donc, euh, disons que nous avons deux développeurs, Emma et Luka, et ils travaillent individuellement, euh, ils font partie de la même équipe. Et disons qu'il y a un début d'itération, et euh, Emma commence à travailler sur le ticket numéro un, Luka commence à travailler sur le ticket numéro deux. Si nous suivons Emma et son travail, elle euh fait un peu de codage, espérons-le, elle teste, espérons-le, d'une manière de développement basée sur les tests. Euh, et à un moment donné, elle se dit : 'Ok, je crois que j'ai fini, je voudrais inviter mes pairs à me donner un retour'. Alors la façon dont nous faisons cela est que nous soumettons une demande de tirage (pull request) et invitons nos pairs à la revoir. Mais Luka est occupé, il travaille donc sur le ticket numéro deux, il y a un tas d'autres choses en cours, différentes réunions, euh vérifier Slack, les e-mails, revoir d'autres PR, etcetera, n'est-ce pas ? Tant de choses se disputent le temps de Luka.
[00:03:07] Euh, donc Emma sait que Luka ne peut pas répondre immédiatement et elle voulait être une bonne employée. Elle ne veut pas rester les bras croisés, alors elle s'est dit : 'D'accord, euh, pendant que j'attends, je peux commencer à travailler sur autre chose'. Alors Emma prend le ticket numéro trois.
[00:03:24] Puis, euh, un certain temps passe et à un moment donné, Emma se dit : 'Ok, Luka ne répond pas, laisse-moi essayer de rappeler Luka'. Et euh, elle demande à Luka encore une fois de jeter un œil à sa PR. Finalement, Luka revient, demande quelques modifications, ils font des allers-retours, euh, essayant de converger vers la solution qui satisfait les deux. La pull request est approuvée et fusionnée. C'est donc ce qu'on appelle les revues de code asynchrones ou les revues de code asynchrones basées sur les PR. Juste par curiosité, combien de personnes ici travaillent dans des équipes qui suivent ce flux de travail ? Cool, d'accord, la majorité de la salle.
[00:04:03] Euh, et s'il y a une chose que j'aimerais que vous reteniez de cette conférence, c'est que l'asynchrone signifie des délais. C'est par conception, s'il n'y a pas de délais, ce n'est pas asynchrone, n'est-ce pas ? Euh, la raison pour laquelle je parle de ce sujet est en fait que j'ai mené une étude qui a duré plus de trois ans maintenant. Et pour vous donner un peu plus de contexte, euh, quelle en était la raison. C'est que je suis souvent invité par différentes équipes pour aider et accompagner sur différentes méthodes de travail. Et il y a une certaine proportion de managers d'ingénierie et de développeurs qui sont intéressés et curieux par différentes façons de travailler, mais ils ne sont pas vraiment sûrs de leur situation actuelle lorsqu'il s'agit d'une approche basée sur les données pour aider à la direction que nous aimerions prendre. C'est pourquoi j'aime aussi cette citation : 'Rencontrer les gens là où ils sont', ce n'est pas vraiment important où nous en sommes actuellement. Ce qui est important, c'est la direction et aussi la tendance.
[00:05:08] Donc, au cours de l'étude, j'ai analysé maintenant plus de 40 000 pull requests. Et euh, les choses dont je vais parler aujourd'hui sont euh, principalement des comportements systémiques ou des modèles systémiques que j'ai pu observer. Euh, certaines des choses que nous avons observées étaient plutôt intuitives, je m'y attendais un peu, et certaines choses ont été une assez grande surprise pour moi aussi. Je suis donc ici pour partager l'apprentissage et le parcours que j'ai eus avec cette étude. Les équipes qui ont été impliquées sont des équipes de développement de produits typiques, donc pas de logiciels open source. Bien que nous sachions aussi que nous avons adopté toute l'idée des pull requests de la communauté open source dans un contexte complètement différent, mais ce sera peut-être une discussion pour un autre jour.
[00:05:57] Alors, qu'est-ce que j'étais curieux de voir ? Euh, j'étais curieux de comprendre l'engagement, le temps d'attente et la taille. Et les raisons à cela sont aussi que j'avais une intuition, ayant une formation en programmation extrême avec des méthodes de travail très collaboratives, la programmation en binôme et en groupe. J'avais l'intuition d'essayer de comprendre quel est l'engagement que je vois sur les pull requests, en fonction également du temps d'attente, de la latence dans le processus, et aussi de la manière dont cela est lié à la taille. Donc, en ce qui concerne l'engagement, pourquoi étais-je curieux à ce sujet ? Donc, l'une des raisons était qu'il y a ce délai, n'est-ce pas ? L'asynchrone. Et euh une sorte de métaphore que j'avais est que j'ai remarqué que lorsque j'ai aussi un appel téléphonique avec quelqu'un et qu'il y a un délai dans la communication, la communication a tendance à s'éteindre assez rapidement. D'accord, à cause des délais qui en font en quelque sorte partie. Et quand il s'agit de la rétroaction étouffée, ce que j'entends par là, c'est que comparé à une conversation en face à face, en synchrone, euh, donner un feedback sous forme écrite via un outil a tendance à être très différent et d'un genre différent. Et c'est aussi, euh, un peu plus coûteux, non seulement à cause des délais qui en font partie, mais aussi parce que c'est une forme écrite sujette aux erreurs de communication, à l'incapacité de voir les signaux non verbaux, etc. Outre le fait que vous examinez également quelque chose après que la chose ait été principalement faite, euh, vous n'avez donc pas la capacité de corriger le tir. Alors que lorsque vous avez une conversation en face à face, vous pouvez couper le mauvais chemin plus tôt. C'est pourquoi j'appelle aussi cela une rétroaction à faible débit et à latence élevée. Maintenant, passons à la première parcelle coupée. Voici donc l'ensemble de données de 500 pull requests et sur l'axe des X, vous pouvez voir la taille en lignes de code. C'était une métrique proxy principalement pour l'effort qui faisait partie de la construction ou de la création d'une pull request. Et il y a différentes façons de procéder, l'une d'entre elles est aussi de mesurer le temps de contact ou le temps de traitement. Mais ce que j'ai constaté pendant l'étude, c'est que c'est très sujet aux valeurs aberrantes, pour ainsi dire, parce que souvent, il arrive que, vous savez, quand il y a un temps de traitement et que les gens travaillent sur quelque chose, ça ne me fait pas comprendre qu'ils y travaillent tout le temps, il y a beaucoup de pauses, différentes interruptions, etc. La taille était donc une métrique très agréable et simple en guise de proxy pour cela. Et sur l'axe des ordonnées, euh, il y a l'engagement ici, et la définition de l'engagement que j'ai utilisée est le nombre de commentaires non triviaux que je peux voir sur les PR.
[00:08:30] Alors, qu'est-ce qu'un commentaire non trivial ? Un commentaire non trivial est un commentaire qui n'est pas trivial, et puis le commentaire trivial est une définition très simple. Un commentaire qui contient quatre mots ou moins. Maintenant, pourquoi ? Parce que j'ai pu observer, probablement vous aussi, beaucoup de LGTM, 'looks good to me', +1, pouces levés, et ce genre de feedback qui n'apporte pas vraiment de valeur à l'autre partie. Donc, euh, ce que nous pouvons voir de ce nuage de points, pas grand-chose, la plupart des pull requests sont euh, oui, moins de 500 lignes de code et la plupart d'entre elles ont moins de 12 commentaires non triviaux. Mais une chose à laquelle j'ai commencé à réfléchir est que si vous investissez beaucoup de temps à essayer de construire une fonctionnalité et que, je ne sais pas, une semaine passe et que vous recevez deux commentaires, ce n'est pas la même chose que si vous avez un très petit changement, n'est-ce pas, et que vous recevez la même quantité de commentaires. Maintenant, la qualité des commentaires ne faisait pas partie de l'étude, mais il est intéressant de comprendre ce qui se passe si nous essayons de normaliser l'axe Y par la taille, n'est-ce pas ? Donc, les choses à ce moment-là commencent à devenir intéressantes dans le sens où euh, lorsque nous voyons sur l'axe Y l'engagement par taille, puis que nous le traçons par taille, ce que nous voyons est que, euh, et encore une fois, cela était répandu dans tous les ensembles de données que j'ai analysés pour les équipes qui faisaient des revues de code asynchrones, c'est que lorsque nous augmentons la taille de la pull request, l'engagement par taille a tendance à diminuer exponentiellement. D'accord.
[00:10:05] Et je pense qu'il y a une part intuitive à cela, euh, je suis à peu près sûr que beaucoup de gens ont eu l'expérience de pull requests énormes, n'est-ce pas, et juste ça me semble bon, euh, validez-le, approuvez-le et puis espérez que rien ne va casser en production, n'est-ce pas ?
[00:10:19] Euh, mais ce qui est important ici, en ce qui concerne la revue de code en tant que processus pour construire la qualité en intégrant le jugement humain dans le processus, c'est que pour les plus grandes demandes de tirage, nous retardons le processus, de plus nous ne voyons pas, il y a un manque d'engagement, ce qui est une condition préalable pour pouvoir intégrer la qualité, car nous basons le processus sur la capacité à obtenir des retours, n'est-ce pas ? Euh, je ne dis rien sur le côté gauche, donc je ne dis pas que si vous avez beaucoup de commentaires, cela garantit la qualité, pas vraiment, n'est-ce pas ? Mais ce que je dis, c'est que si vous n'avez pas la capacité d'obtenir le feedback et que la qualité est une condition préalable, alors vous n'êtes pas non plus capable d'intégrer la qualité, du moins pas dans la mesure où vous le souhaiteriez. Euh, et c'est la raison pour laquelle j'aime aussi cette citation, je n'ai jamais eu une énorme PR qui ne me semblait pas bonne. Euh, j'ai aussi un t-shirt que je porte lors des conférences. Euh, je ne l'ai pas apporté cette fois. Euh mais je suis aussi euh euh euh sûr que beaucoup de gens rencontrent aussi ce euh comment ça s'appelle ? Phénomène. Que euh, plus la pull request est petite, plus vous voyez d'engagement et vice versa, comme 500 lignes de code, tout va bien, allons-y. Euh, et il y a une raison à cela. Euh, je pense que si je reçois une pull request après avoir travaillé, si quelqu'un a travaillé une semaine, n'est-ce pas, et qu'il y a beaucoup de modifications de code qui ont été introduites. Je ne peux pas faire grand-chose, à ce stade, la chose est déjà faite. Donc, soit il y a de la qualité, soit il n'y en a pas, n'est-ce pas ? Euh, et il y a un manque de capacité à corriger le cap. De plus, euh, si je suis l'auteur et que j'ai investi une semaine dans la construction de cette fonctionnalité et que quelqu'un me dit : 'Hé, 80% de ce que tu as fait, tu as pris le mauvais virage dès le premier jour'. C'est c'est émotionnellement douloureux, n'est-ce pas, à cause du biais des coûts irrécupérables qui entre en jeu et il est alors également difficile de ce côté-là d'essayer de corriger le tir, n'est-ce pas ? Euh, et récemment, je suis tombé sur cette vidéo, je ne suis pas sûr qu'elle se charge.
[00:12:28] Oui. Ou peut-être qu'il va se charger, voyons voir.
[00:12:35] Alors, oui.
[00:12:38] C'est ainsi que je perçois les relecteurs avec une grosse pull request qui essaient d'intégrer la qualité, n'est-ce pas ? Donc à ce moment-là, ça devient un théâtre, plus que d'essayer vraiment de le faire, n'est-ce pas ?
[00:12:49] Euh D'accord, donc le temps d'attente. Le temps d'attente était la partie intéressante pour moi, du moins l'apprentissage que j'ai fait. Euh, et si nous regardons le ticket numéro un dans ce cas, si vous vous concentrez là-dessus. Et j'ai aussi tracé sur la partie inférieure de la diapositive, en bas, le temps de cycle ou le délai, depuis le début du travail sur ce ticket jusqu'à ce qu'il soit euh, publié ou déployé ou fusionné, peu importe, car nous nous concentrons principalement ici sur cette partie. Euh, mais ce que vous voyez, c'est qu'il y a des parties de son temps de cycle où nous passons effectivement du temps à travailler sur cet élément, donc Emma code ou Luka donne des retours, Emma intègre les retours, etc. Mais il y a aussi une part significative du temps où cet élément passe à attendre l'attention de quelqu'un, assis dans une file d'attente, n'est-ce pas ? Et c'est un temps complètement improductif, n'est-ce pas ? Euh, en plus du fait que cela retarde la livraison, n'est-ce pas ? Mais ce que l'on observe dans les équipes qui travaillent individuellement, et il est difficile de trouver une équipe qui travaille individuellement et qui n'a pas de revue de code asynchrone. Le pourcentage de temps d'attente en termes de temps de cycle est énorme. Ainsi, le temps d'attente commence à dominer le temps de cycle et il y a une raison et des maths derrière cela, la théorie des files d'attente et la loi de Little. Je ne vais pas entrer dans les détails, mais ce que vous observez, c'est que la plupart du temps est passé à des éléments qui attendent simplement l'attention de quelqu'un.
[00:14:25] Euh, la façon dont j'ai procédé pour mesurer le temps d'attente, j'ai utilisé une approximation, qui est parfois bonne, parfois moins bonne. Euh, et il est très important, lorsque nous mesurons quelque chose dans un processus de livraison, de comprendre quand les approximations euh ne sont pas suffisantes. Et la façon dont j'ai procédé est que, généralement, dans ce processus, nous développons une fonctionnalité, puis
[00:14:55] on soumet une pull request et à ce moment-là, on invite quelqu'un à donner son avis. Donc le temps d'attente est du début de ce moment, que j'ai capturé de différentes manières, jusqu'à ce que la pull request ait été fusionnée. Maintenant, cette approximation euh a quelques hypothèses que je n'aurai pas le temps de détailler ici, mais l'un des cas où cette hypothèse n'est pas euh vraie ou cette approximation n'est pas vraie est quand je reçois beaucoup de feedback après avoir levé une pull request. Ou beaucoup de commits de suivi, n'est-ce pas, cela me dit qu'il y a déjà eu du remaniement et cela ne devrait pas faire partie du temps d'attente.
[00:15:30] Euh, et ensuite, en regardant certains des résultats typiques que j'ai pu observer, nous avons ici des pull requests. Euh, 500 pull requests, pull requests fusionnées, qui ont pris environ six mois pour passer à travers le système de travail, donc depuis le début de la première pull request jusqu'à ce que la dernière pull request ait été fusionnée. Et pour cette équipe, le temps d'attente cumulé en mois était d'environ 28 mois. Maintenant, ce nombre n'est pas précis, mais l'ordre de grandeur se prête à de très belles conversations, n'est-ce pas ?
[00:16:07] Euh, et la raison pour laquelle je pense qu'il est très important de comprendre quels sont les effets de beaucoup de temps d'attente que l'on observe dans le système de travail, c'est cette analogie ou ce jeu que nous jouions quand nous étions enfants, le jeu du chaud et du froid. Donc, une personne cache un objet, l'autre va le chercher et la personne qui a caché l'objet donne des retours à l'autre personne à intervalles réguliers. Et maintenant imaginez que vous avez deux équipes, une équipe reçoit un feedback après chaque seconde et l'autre équipe reçoit un feedback après chaque minute. Sur laquelle de ces deux équipes, en moyenne, parieriez-vous qu'elle trouvera un objet plus tôt ? N'est-ce pas, donc vous allez à peu près euh, choisir l'équipe qui a une latence plus faible dans le processus. Et la partie importante de ceci est que, en raison de beaucoup de gaspillage, de beaucoup de temps d'attente qui s'accumule dans le système de travail, nous retardons également la livraison, ce qui signifie que notre cadence d'apprentissage, le taux d'apprentissage que nous avons, décélère. Nous effectuons donc également des expériences moins souvent et, de ce fait, nous apprenons moins souvent.
[00:17:14] D'accord, voici le nuage de points pour le temps d'attente par taille. Donc sur l'axe des ordonnées, vous pouvez voir le temps d'attente en heures. Et encore une fois, pour ce nuage de points, euh, pas grand-chose, dans le sens où la plupart des pull requests ont pris euh, euh, moins de 200 heures, ce qui est énorme, mais euh, euh, oui, les gens sont souvent surpris par les chiffres quand ils les voient. Euh, mais quand on y pense, si euh, si je fais un petit changement, je renomme quelques méthodes, quelques variables ou euh, euh, quelque chose comme ça, plus petit, de taille plus petite, et disons que j'investis 20 ou 30 minutes pour faire cela, et ensuite j'attends un jour ou deux pour une revue. Ce n'est pas la même chose que si j'investis une semaine et que j'attends ensuite une journée ou deux pour une révision, donc le coût relatif de la révision est différent dans ces deux cas, n'est-ce pas ? Alors, que se passe-t-il lorsque nous normalisons l'axe des Y par la taille, n'est-ce pas ? Donc, euh, ici nous avons euh des minutes, temps d'attente, temps d'attente en minutes par ligne de code. Et c'était intéressant parce que ce que nous voyons ici, et encore une fois, c'était — je peux, je —, tous les ensembles de données que j'ai analysés présentaient le même motif. À mesure que nous réduisons la taille de la pull request, le temps d'attente par taille augmente exponentiellement. Et c'est assez intéressant parce que la façon dont je l'interprète est que le coût de la revue de code par taille augmente exponentiellement à mesure que nous réduisons la taille de la pull request. D'accord. Ainsi, les revues par taille de la pull request deviennent de plus en plus coûteuses à mesure que nous réduisons la taille de la pull request.
[00:18:59] Euh, et ça a été une surprise pour moi, n'est-ce pas ? Souvent, quand je vais dans les équipes et qu'il y a, vous savez, d'énormes PR, etc., un conseil par défaut est de faire des pull requests plus petites. Et nous voulons faire des pull requests plus petites parce que nous avons aussi appris la leçon sur les petits lots du Lean. Euh, et la raison pour laquelle nous voulons avoir des pull requests plus petites est qu'elles prennent moins de temps à écrire, elles sont plus rapides à examiner. Moi, en tant que relecteur, je peux insérer 10 ou 15 minutes de relecture au lieu d'une relecture d'une journée dans mon calendrier. Euh, comme nous l'avons vu, il y a aussi un engagement plus élevé pour les petites PR que pour les grandes PR, elles sont aussi moins risquées car moins de choses sont modifiées. En même temps, et quand il y a un problème, c'est aussi plus facile à dépanner parce qu'il y a un plus petit tas de foin dans lequel chercher l'aiguille, pour ainsi dire. Et en ce qui concerne la recherche Dora, euh, les PR plus petites, euh, qui, comme effet secondaire, ont euh, une fréquence d'intégration plus élevée, contribuent positivement aux quatre métriques Dora, n'est-ce pas ? Donc nous voulons avoir des pull requests plus petites. Mais ce que nous observons, c'est que le coût de ces pull requests augmente exponentiellement, donc le système nous repousse en quelque sorte, n'est-ce pas ? Et un scénario à garder à l'esprit lorsque nous parlons de cette euh La tendance est que la plupart des développeurs ont, j'en suis sûr, rencontré des suites de tests lentes. Donc si j'ai une suite de tests qui prend 20 minutes à s'exécuter, je ne vais pas exécuter la suite de tests après chaque modification de ligne de code. Parce que ça n'a aucun sens économique, la plupart du temps, je vais juste rester là à attendre que la suite de tests me donne des retours. Donc, effectivement, ce que le système nous dit, c'est que, hé, obtenir un feedback des tests est super cher, alors utilisez-le sagement. Donc, la façon dont nous l'utilisons intelligemment est de l'exécuter moins souvent, ce qui signifie que nous accumulons plus de changements, ce qui signifie que nous retombons dans les PR plus importantes. D'accord. Et un autre scénario à avoir en tête quand on parle de ce modèle, c'est que je suis à peu près sûr que la plupart des développeurs ont connu des suites de tests lentes. Donc si j'ai une suite de tests qui prend 20 minutes à s'exécuter, je ne vais pas exécuter la suite de tests après chaque ligne de code modifiée, car cela n'a aucun sens économique. La plupart du temps, je vais simplement rester là à attendre que le test me donne un retour. Donc, ce que le système nous dit, c'est que obtenir un retour des tests est super cher, alors utilisez-le à bon escient. Donc la façon dont nous l'utilisons sagement est de le faire moins souvent, ce qui signifie que nous accumulons plus de changements, ce qui signifie que nous retombons dans les PR plus importants. Hum, et pour cette raison, j'adore cette citation de Don Rainertson, même si vous ignorez l'économie, elle ne vous ignorera pas. Nous devons donc comprendre l'économie du système que nous avons mis en place, euh, afin de comprendre où sont les points d'intervention que nous pouvons avoir. Donc une autre chose à avoir en tête est d'essayer de faire de petits changements dans ce genre d'environnement. Non? Donc si ça me prend un ou deux jours pour obtenir une révision sur un petit changement, n'est-ce pas? Cela va le plus souvent m'empêcher soit de faire ce changement, soit je vais le regrouper avec autre chose, n'est-ce pas? Et ensuite revenir à une demande de tirage plus importante. Et la raison pour laquelle je pense que c'est important, c'est que je pense que les équipes qui ont une latence de communication plus faible ont tendance à avoir une base de code plus saine.
[00:21:45] Parce que vous, vous changez le système pour qu'il corresponde à votre nouveau modèle mental quand vous le voulez, pas quand ce n'est pas cher. D'accord. Donc ce qui se passe alors, grâce à une base de code saine, c'est que cela signifie également une plus grande réactivité au changement et moins de retravail, etc. Donc, euh, il y a beaucoup d'effets de second, troisième et quatrième ordre de ce genre de schémas systémiques.
[00:22:09] Euh, maintenant, en parlant de ces effets de second et troisième ordre, euh, si vous euh regardez cette partie que j'ai surlignée ici, pouvez-vous examiner ma demande de tirage s'il vous plaît? Et ces mains implorantes. Euh, combien de personnes ici ont fait partie d'équipes où vous avez vu des demandes répétées de révision de requêtes de tirage, que ce soit euh des rappels amicaux ou des supplications ou une escalade pure et simple au responsable de l'ingénierie ou quoi que ce soit, n'est-ce pas? Et euh c'est intéressant, euh j'ai aussi observé que les gens ont des façons très différentes de supplier pour les pull requests. Euh, certains sont plus doux, d'autres moins. Mais chose intéressante, euh, mon point ici est que la quantité de supplications dans le système est proportionnelle au travail en cours. Donc, plus vous travaillez sur des choses en équipe, et si vous travaillez individuellement, vous avez déjà un processus de travail élevé, trop élevé, alors ce qui se passe, c'est que le système devient moins réactif. À cause de cela, vous avez des retards, euh une latence dans ce processus, et à cause de cela, euh les gens ont besoin de demander à plusieurs reprises de revoir le code, le document ou ce que ce soit.
[00:23:25] Euh, quand j'ai tweeté ça, une personne a dit qu'ils avaient un terme pour ça, qui s'appelle la mendicité de fusion. Donc si vous avez besoin d'un terme pour cela, euh, voilà.
[00:23:38] Euh, une autre chose aussi, euh, quand il s'agit de ces effets de second et troisième ordre, ce que j'ai aussi observé, c'est que les requêtes de tirage ont besoin d'être sélectionnées, où le besoin de sélection est défini comme le réviseur demandant un petit changement où 'petit' est relatif à l'effort, euh, et euh, disons que, vous savez, le réviseur a trouvé un meilleur nom pour une variable ou une méthode, ou il y a quelque chose concernant, vous savez, un espace supplémentaire ou un formatage ou quoi que ce soit. Euh, mais ils ont besoin de dire, hé, désolé pour ce pinaillage, pouvez-vous intégrer ce changement? Et ce qu'ils pensent, c'est aussi que j'ai commencé à chercher des articles sur ce sujet parce que j'en ai trouvé beaucoup qui parlent de comment arrêter le pinaillage dans les revues de code, euh comment gérer les relecteurs de code qui pinaille, comment gérer un membre de l'équipe qui pinaille, etc. Mais ce que j'ai observé ici, c'est que lorsque vous réduisez le coût des révisions, et donc aussi le coût du changement, vous voyez moins de pinaillages ou les gens doivent s'expliquer comme, euh, euh, oui, je demande un pinaillage. Par exemple, si je suis en pair programming avec quelqu'un, euh, et que j'attendais la méthode et que mon partenaire a trouvé un meilleur nom pour cela, je n'ai qu'une ligne de code à perdre. D'accord. Mais quand il y a de la latence dans tout ce processus, alors tout le changement devient très coûteux, et nous devons alors trouver un changement relativement plus important afin de le justifier, pour ainsi dire.
[00:25:16] Euh, j'ai donc essayé de comprendre l'idée générale d'essayer d'aider les équipes à réduire la taille de la pull request, euh, les équipes qui ont fait des revues de code asynchrones. Et ici, c'est un diagramme de boucle causale que nous utilisons, qui vient de la boîte à outils de la pensée systémique, et je vais vous donner un bref cours intensif à ce sujet. Euh, donc ces étiquettes sont des variables et elles sont connectées d'une certaine manière. Il existe donc deux euh liens causaux, des types de liens causaux que nous pouvons avoir. L'un est le positif, euh plus, et l'autre est négatif, et le positif dit que lorsque deux variables sont connectées et qu'il y a un plus entre elles, cela signifie qu'elles se déplacent toutes les deux dans la même direction, vers le haut ou vers le bas, tandis que le négatif signifie qu'elles se déplacent dans des directions opposées. Maintenant, lorsque vous déchargez ces variables et tracez des lignes entre elles, vous pourriez découvrir des boucles de rétroaction. Donc, deux boucles de rétroaction, euh, issues de la pensée systémique et également représentées ici, sont une boucle de rétroaction de renforcement et une boucle de rétroaction d'équilibrage. Et une boucle de rétroaction de renforcement est une boucle de rétroaction qui se nourrit d'elle-même, c'est donc une sorte d'effet boule de neige. Tandis que la boucle de rétroaction d'équilibrage est une boucle de rétroaction qui cherche un objectif.
[00:26:31] Donc, disons que, nous avons un thermostat ici, qui est réglé à 21 degrés, si euh il fait chaud dehors, le système va fonctionner jusqu'à ce qu'il corresponde à ce nombre, puis il va s'arrêter. D'accord. Maintenant, si euh, si ça devient euh plus chaud dehors, ça va fonctionner encore plus, mais le fait est que quand ça atteint ce seuil, ça va s'arrêter, quand il y a une divergence, ça essaie de euh stabiliser le système, n'est-ce pas? Alors, passons en revue ce diagramme de boucle causale car il y a une histoire derrière. Le contexte est donc que l'équipe effectue des revues de code asynchrones et souhaite réduire la taille de la pull request. Donc, si vous réduisez la taille de la demande de tirage, l'incitation motivationnelle à la révision augmente, ce qui est une bonne chose car je suis plus en faveur de la révision de petites demandes de tirage que de grandes. Et à cause de cela, le temps d'attente pour une révision du côté de l'auteur diminue, ce qui est une bonne chose. Ce qui, euh, réduit le coût perçu de la revue de code, ce qui pousse la taille de la pull request encore plus bas, n'est-ce pas? Donc cela incite en quelque sorte à des pull requests plus petites.
[00:27:34] Et c'est une boucle de rétroaction de renforcement qui est souhaitable, celle que nous voulons avoir, mais ce n'est pas la seule chose qui se passe. Donc, si nous regardons quelles sont les autres choses qui se produisent lorsque vous utilisez la taille de la pull request dans les équipes qui effectuent des revues de code asynchrones, c'est que le nombre de PR à examiner dans une unité de temps augmente. Donc, si nous réduisons de moitié la taille de la pull request, nous obtenons deux fois plus de pull requests à examiner dans une unité de temps. Ensuite, lorsque vous poussez cela plus loin, vous obtenez un plus grand nombre d'interruptions pour un réviseur, ce qui, alors que tout le monde essaie de protéger son flux psychologique personnel, personne ne veut être interrompu trop souvent et faire des changements de contexte et arrêter ce sur quoi ils travaillent, euh cela réduit en quelque sorte l'incitation motivationnelle à la révision, ce qui nous ramène, euh, dans l'autre direction,
[00:28:26] euh, nous incitant à augmenter la taille de la pull request. Il s'agit donc de la boucle de rétroaction d'équilibrage qui s'oppose en quelque sorte à cette boucle de rétroaction de renforcement souhaitable. Et le problème ici est ce conflit que nous observons dans cette incitation motivationnelle à la révision, qui est principalement motivée par le nombre d'interruptions. Euh, mais ce n'est pas le seul problème que nous avons lorsque nous réduisons la taille de la pull request, car ce qui se passe aussi et vous l'avez vu avec Emma quand elle attendait Luca, c'est qu'elle a intégré autre chose. Ainsi, la tentation de commencer à travailler sur quelque chose de nouveau augmente, ce qui signifie que nous avons encore plus de travail en cours, plus de requêtes de tirage à examiner, et le système nous pousse encore plus.
[00:29:12] Euh, donc, changeons de sujet maintenant et parlons de l'efficacité du flux, euh nous sommes à FlowCon, je suis à peu près sûr que beaucoup de gens la connaissent. Mais en bref, l'efficacité du flux est l'idée ou la métrique où nous essayons de comprendre combien de temps de cycle d'un élément de travail nous passons à travailler dessus par rapport à son simple attente de l'attention de quelqu'un ou à son attente dans une file d'attente. Plus l'efficacité du flux est faible, pire est notre processus, plus le temps d'attente est long, plus nous avons de déchets dans le système et vice versa. Et j'ai euh euh analysé les données et euh c'est l'un des modèles qui était à nouveau observable dans euh dans ces ensembles de données. Euh, sur l'axe Y, considérez-le simplement comme une efficacité de flux, je ne vais pas passer trop de temps à essayer de décrire exactement cette métrique. Euh, mais c'est un indicateur de l'efficacité du flux. Et ce que vous observez, c'est que l'efficacité du flux commence à chuter à un certain point, euh, sur la taille de la pull request, n'est-ce pas? Euh, et c'est intéressant parce que quand vous pensez, euh, si vous faites une expérience de pensée et disons que vous avez un changement de 300 lignes de code que vous devez pousser à travers le système de travail, vous pouvez le faire d'au moins deux manières. Donc, une façon est 15 PR de 20 lignes de code, disons, et l'autre est un PR de 300 lignes de code. Maintenant, si nous avons ce genre de comportement, si, quand on y pense, le délai cumulé pour faire passer 15 PR de 20 lignes de code dans le système de travail est beaucoup plus long que le délai cumulé d'un PR de 300 lignes de code, n'est-ce pas?
[00:30:46] Euh, et c'est aussi intéressant parce que cela signifie également que le débit pour les requêtes de tirage plus petites diminue parce que nous encourons plus de temps d'attente par temps de cycle ou que le rapport temps d'attente/temps de traitement augmente, et à cause de cela, le débit s'effondre. Euh, une façon de le voir aussi, c'est que lorsque nous réduisons la taille de la pull request, quand je travaille sur une pull request, euh, le temps de traitement par taille diminue ou reste le même, peu importe, euh, mais le temps d'attente, comme nous l'avons vu, augmente de manière exponentielle, n'est-ce pas? Et la raison en est que, avec une pull request plus petite, avec des lots plus petits dans un système pleinement utilisé, vous encourez le coût d'intégration des dépendances beaucoup plus souvent. D'accord. Donc j'ai besoin, quand j'ai une pull request plus petite, j'ai besoin de mes pairs plus souvent maintenant pour revoir ma pull request, n'est-ce pas? Euh, et cela fait monter le rapport temps d'attente/temps de traitement, ce qui tue l'efficacité du flux, ce qui entraîne un débit plus faible.
[00:31:48] Euh, et quand vous pensez au travail asynchrone, la promesse du travail asynchrone est que vous pouvez commencer à travailler sur quelque chose sans que l'autre personne dont vous aurez besoin soit disponible. Alors, pensez aux incitations que vous avez maintenant dans le système, ce que vous faites en fait, c'est de rendre le coût de démarrage d'un nouveau travail nul. N'est-ce pas? Ce qui signifie que cela incline le taux d'arrivée dans le système, ce qui signifie que vous obtenez un afflux plus élevé de nouveau travail, ce qui augmente ensuite le travail en cours, plus d'inventaire, euh, et une livraison plus lente à la fin.
[00:32:23] Euh, et donc à cause de cela, et si nous, euh, oui, prenons en compte la formule de la loi de Little, le travail en cours, comme vous pouvez le voir ici, monte en flèche et, à mesure que vous avez plus d'inventaire, les temps de cycle s'envolent, euh, euh. Et ce n'est pas la seule chose.
[00:32:41] Euh, parce que lorsque vous avez un processus de travail élevé, vous avez plus de blocages dans le système, vous avez plus de retards parce que le système est moins réactif, et à cause de cela, les gens sont, surtout, les humains sont très bons pour prendre plus de travail quand ils sont bloqués.
[00:32:54] Vous finissez donc par prendre plus, euh, de travail en cours que vous n'en avez, et c'est une boucle de rétroaction de renforcement vraiment méchante à avoir. D'accord. Maintenant, pensez-y dans ce cas, n'est-ce pas? Si nous avons cette chose, ce genre de, euh, rapport temps d'attente/temps de traitement dans un système entièrement utilisé. Encore une fois, si vous travaillez individuellement, euh, vous avez une utilisation trop élevée. Essayez d'estimer dans ce genre de, euh, système, n'est-ce pas? Ce qui se passe, c'est que vous estimez probablement l'effort, mais estimez-vous le temps d'attente, dont vous n'avez aucune idée de la durée, mais le temps d'attente est ce qui domine le temps de cycle. Donc
[00:33:36] Il y a donc une raison pour laquelle je dis qu'estimer dans un système pleinement chargé est une tentative de pauvre pour atteindre la prévisibilité. Vous avez de plus gros problèmes à résoudre avant d'essayer de faire des estimations.
[00:33:49] Euh, et une autre chose comme effet de second ordre est celle des longs délais. Quand vous pensez que si je veux commander une veste dans la boutique de vêtements en ligne et disons qu'il leur faut trois ou quatre jours pour livrer l'article, n'est-ce pas? Et je veux acheter une veste et il y a quelques candidats que j'ai. Ce qui se passe, c'est que je ne vais pas commander la première chose et attendre trois jours, puis commander la deuxième et attendre trois jours. Je vais regrouper toutes ces choses et ensuite je vais commander toutes ces choses. Maintenant, ce qui se passe, c'est que, euh, je ne vais choisir qu'une seule des vestes, très probablement, n'est-ce pas? Donc je vais retourner n moins un à
[00:34:30] au magasin, n'est-ce pas? Et euh, donc c'est ça, c'est l'inventaire spéculatif qui commence à s'accumuler dans le système parce que les délais sont longs. D'accord. Il y a donc un magasin de vêtements en ligne en Allemagne, je ne sais pas s'ils opèrent aussi en France, Zalando, et ils disent généralement qu'ils ont des problèmes avec un taux de retour élevé, et mon avis est qu'ils n'ont pas de problème avec un taux de retour élevé, ils ont un problème avec les délais de livraison et à cause de cela, ils ont beaucoup d'inventaire spéculatif qui circule dans le système, ce qui pousse aussi leurs partenaires à accumuler l'inventaire parce que cela va être accumulé euh tiré vers la euh livraison.
[00:35:11] C'est pourquoi je dis que l'inventaire spéculatif dans le système augmente avec les retards. Et quand on pense à la pull request, il y a souvent, quand il y a beaucoup de retards, on voit souvent des solutions sur-conçues parce que Je ne suis pas sûr de quand sera la prochaine fois que je pourrai euh modifier le design pour ça, donc je vais en quelque sorte le faire euh dès le départ. Mais c'est spéculatif, n'est-ce pas? Donc ce n'est pas émergent.
[00:35:38] D'accord. Donc, pour résumer, euh, une faible qualité ou l'incapacité d'intégrer la qualité dans des pull requests plus grandes et euh, le débit qui diminue pour les pull requests plus petites. Nous sommes donc en quelque sorte euh entre le euh marteau et l'enclume. Nous devons donc choisir: faisons-nous un compromis en perdant du débit ou perdons-nous de la qualité?
[00:36:01] Et pour quiconque a eu la chance de lire le livre de Don Reinertsen, les principes du flux de développement de produits, il s'agit donc d'une courbe en U typique d'optimisation de la taille des lots. Vous essayez de trouver le juste milieu dans ces différentes forces qui font partie du système et ici nous parlons principalement du coût de transaction car ces retards sont une sorte de forme de coût de transaction.
[00:36:23] D'accord. Donc, en grandissant en tant qu'ingénieur, j'ai appris à dire qu'il y a toujours un compromis si souvent, n'est-ce pas? Euh, euh, mais la chose que j'ai aussi découverte, c'est que certains compromis n'existent en fait pas parce que les hypothèses sous-jacentes sont erronées. Il est donc très important de comprendre quelles sont les hypothèses que nous avons derrière le compromis que nous prétendons exister, n'est-ce pas? Euh, parce que je pense qu'il y a beaucoup de cas où l'on peut avoir une situation gagnant-gagnant, n'est-ce pas? Cela dépend vraiment du contexte, en un sens. Et quand j'ai mentionné le gagnant-gagnant, euh, une des choses qui a été un très grand mythe qui a été démystifié grâce, euh, à la recherche de Dora et qui a été présentée, euh, les résultats ont été présentés dans le livre Accelerate, c'est que quand vous parlez de DevOps, vous savez, ce n'est pas le débit ou la stabilité, c'est les deux ou aucun des deux. Donc, soit vous avez à la fois le débit et la stabilité, soit aucun d'entre eux. Ce que j'essaie de dire, c'est que nous pourrions peut-être avoir le beurre et l'argent du beurre. Euh, essayons de trouver peut-être l'une des options pour aborder ce problème. Donc ce que nous observons, c'est que nous avons un coût de revue de code qui augmente de manière exponentielle à mesure que nous réduisons la taille de la pull request, et cela conduit à un débit plus faible pour les pull requests plus petites, n'est-ce pas? Donc nous voulons avoir une petite pull request, mais nous ne voulons pas perdre de débit. Comment s'y prendre? Partons de là et travaillons à rebours.
[00:37:54] Donc, si nous voulons maintenir le débit le même ou ne pas le perdre de manière exponentielle en réduisant la taille de la pull request, euh nous ne devons pas encourir des coûts de revue de code plus élevés par taille en réduisant la taille de la pull request. Maintenant, pour ce faire, ce qui doit se produire est que le temps de réaction des acteurs, par acteurs, j'entends les auteurs et les réviseurs, leur temps de réaction à mesure que nous réduisons la taille de la pull request doit être exponentiellement plus rapide et plus rapide et plus rapide si vous ne voulez pas perdre le débit. Et pour ce faire, la disponibilité des acteurs doit augmenter de manière exponentielle à mesure que nous réduisons la taille de la pull request. Donc si vous vous souvenez d'Emma et Luca, ils n'étaient pas capables de réagir aux demandes de l'autre parce qu'ils étaient occupés par d'autres choses, donc un processus de travail élevé, euh, qui tuait la disponibilité, n'est-ce pas?
[00:38:46] Donc, si nous regardons le ticket numéro un et que nous tirons sa chronologie, ici les écarts entre les flèches représentent les retards qui existent actuellement dans le processus et disons que nous voulons réduire la taille de la demande de tirage. Ce que nous disons, c'est qu'à mesure que nous réduisons la taille de la pull request afin de ne pas perdre de débit, M et Luca doivent réagir de plus en plus vite aux demandes de l'autre. D'accord. Jusqu'au point où, à un moment donné, la requête sera suffisamment petite, ou la demande de tirage sera suffisamment petite, pour qu'ils aient besoin de travailler ensemble afin de ne pas perdre le débit. Donc, c'était la conclusion de l'étude, afin de ne pas perdre exponentiellement le débit tout en réduisant la taille moyenne de la pull request, les gens doivent se rapprocher exponentiellement dans le temps, ce qui nous amène à des revues de code continues.
[00:39:39] Donc, pour revenir à ce problème que nous voyons ici, le conflit, l'incitation motivationnelle à la révision, n'est-ce pas? Euh, ce qui était causé par le nombre croissant d'interruptions, n'est-ce pas? Eh bien, pourquoi? Tu as de l'eau ici. au point qu'à un moment donné, la requête va être euh ou la requête va être suffisamment petite pour être suffisamment petite pour qu'ils aient besoin de travailler ensemble afin de ne pas perdre le débit.
[00:39:22] C'était donc la conclusion de l'étude : pour ne pas perdre exponentiellement le débit tout en réduisant la taille moyenne de la requête de fusion, les gens doivent se rapprocher exponentiellement dans le temps, ce qui nous mène à une revue de code continue.
[00:39:39] Donc, pour en revenir à ce problème que nous voyons ici, le conflit, l'incitation motivationnelle à la révision, n'est-ce pas ? Euh, qui était causé par le nombre croissant d'interruptions, n'est-ce pas ? Eh bien, pourquoi boire de l'eau ?
[00:39:58] D'accord, donc si vous travaillez sur la même chose en même temps, vous ne pouvez pas me faire interrompre parce que nous travaillons tous les deux sur la même chose, n'est-ce pas ? Et cela m'amène à cet univers parallèle, euh, que j'appelle les schémas de cocréation, mais c'est une sorte de terme conjoint pour la programmation en binôme et en groupe, ou en ensemble, ou en soft reming comme on l'appelle aussi de nos jours. Et quand on pense à l'économie du système, l'effet secondaire important, l'effet secondaire positif de travailler ensemble, c'est que vous avez une disponibilité garantie des réviseurs. D'accord ? Donc le coût de la revue de code est zéro, parce que je peux en avoir autant que je veux. Donc, l'autre personne est disponible tout le temps, donc je peux faire la révision pour chaque petite modification que je fais, n'est-ce pas ? Et qu'est-ce qui se passe à cause de ça ? Cela signifie que le coût de transaction, c'est-à-dire le coût de transfert d'un lot d'une étape à l'autre, du développement à la revue, euh est minimisé ou se rapproche de zéro. Vous pouvez donc avoir la taille de lot optimale tout à fait à gauche.
[00:41:03] Et puis, pensez à quoi ressemblerait ce nuage de points si nous avions des revues de code continues, n'est-ce pas ? Donc, le temps d'attente sera proche de zéro ou zéro, n'est-ce pas ? Et l'engagement, euh, je ne sais pas, je ne l'ai pas mesuré, mais je suppose qu'il augmente au moins, et nous l'avons aussi vu, euh, du côté de l'engagement des choses, mais quand vous avez une latence plus faible dans le processus, vous arrivez aussi à voir un engagement plus élevé. Maintenant, ce qui est intéressant aussi, c'est que lorsque vous pensez à une panne de production dans vos équipes ou votre entreprise, comment vous y prenez-vous pour travailler ? Donc, est-ce que vous faites des messages asynchrones sur Slack ou, vous savez, des e-mails, etc. ? Non. Vous voulez minimiser ou réduire le temps moyen de récupération, alors vous sautez dans un appel et vous essayez de résoudre la même chose. C'est donc important, et c'est une leçon d'Eli Goldrad tirée de la théorie des contraintes. Vous pouvez souvent trouver ces schémas dans les situations d'urgence que vous pouvez réellement appliquer dans votre travail quotidien, n'est-ce pas ? Donc vous avez le même objectif avec la livraison, vous voulez avoir des délais plus courts parce que nous voulons accélérer le rythme d'apprentissage et nous pouvons appliquer la même chose à votre travail quotidien. Euh, alors réfléchissez à ce que nous essayons d'optimiser ici, n'est-ce pas ? Donc vous voulez que la taille de la pull request diminue, nous voulons que le temps d'attente précis diminue et nous ne voulons pas perdre l'engagement, ce sont les choses pour lesquelles nous optimisons ici.
[00:42:29] Et euh, vous avez peut-être remarqué cette barre sur le côté droit, qui est ce que j'appelle le score de PR. Mais ce que j'ai fait, c'est que j'ai simplement cartographié les relations entre ces variables que nous essayons d'optimiser dans une formule. Euh, donc vous avez la taille euh multipliée par le temps d'attente en minutes divisé par l'engagement, donc vous voulez que la taille diminue, euh le temps d'attente diminue et l'engagement ne le perde pas, reste constant ou augmente, mais plus ce nombre est bas, meilleur est ce processus, n'est-ce pas ?
[00:42:58] Donc quand on pense à travailler ensemble, la taille de la pull request ou du changement est minimale, elle peut être aussi basse qu'une ligne de code, le temps d'attente en minutes est zéro parce que vous avez une disponibilité garantie, ce qui signifie que le temps d'attente est zéro. Et euh, oui, l'engagement n'a même pas vraiment d'importance s'il reste le même ou augmente, euh, j'utilise un plus l'engagement parce que je tombe souvent sur des pull requests qui n'ont aucun commentaire non trivial. D'accord, donc vous ne voulez pas diviser par zéro, et ce à quoi cela aboutit, c'est zéro, n'est-ce pas ? Donc, cela signifie en quelque sorte que si vous optimisez pour ces choses, vous obtenez les meilleurs résultats comme sous-produit de la manière de travailler.
[00:43:42] Euh, et c'est la raison pour laquelle je dis aussi que la taille optimale d'une pull request est une ligne de code qui est révisée au fur et à mesure qu'elle est tapée. Et je ne connais personnellement pas de meilleure façon d'y parvenir que par la programmation en binôme et en groupe. Je suis complètement ouvert à l'apprentissage de nouvelles façons de faire cela, et c'est, je pense, le meilleur que nous ayons actuellement, du moins de mon point de vue, dans notre boîte à outils.
[00:44:08] Donc, en traçant les euh pull requests dans les équipes qui ont fait des revues de code AC, ici sur l'axe Y, nous pouvons voir le score, qui est, que j'ai dû tracer sur une échelle logarithmique parce que les résultats étaient si élevés ou si mauvais. Euh, et c'est un monde que je vois. Et puis il y a cet autre monde, l'univers parallèle de la revue de code continue, euh, la programmation en binôme et en groupe, qui est, euh, très, euh, loin de cela, encore une fois sur l'échelle logarithmique.
[00:44:37] Euh, donc encore une fois, euh, l'une des choses que je voulais partager, c'est, euh, il y a quelques années, j'ai travaillé avec l'une des équipes où nous, euh, oui, nous faisions du développement basé sur la branche principale, de la programmation en groupe, euh, par défaut, euh, toutes les pratiques XP, donc le développement piloté par les tests, de très bonnes compétences en refactoring et en conception, et cetera. Et un jour, je me suis dit, ok, vous savez, euh, nous travaillons de cette façon, je suis curieux, euh, quelle est la fréquence d'intégration que nous voyons ? Donc, ce sont les résultats de l'équipe qui compte 3 millions de clients actifs quotidiens, euh, et de nombreux millions de revenus qui transitent par ce système. Et, euh, ce que j'ai pu constater, c'est qu'en l'espace de neuf heures et vingt minutes, nous avions 107 commits atterrissant sur une branche principale. Ce qui signifie que si vous traduisez cela dans le monde des pull requests, une équipe de cinq personnes a eu 107 pull requests fusionnées dans cet intervalle de temps, n'est-ce pas ? Ce qui est très différent de ce que l'on observe, euh, autrement dans les équipes qui ne pratiquent pas ces méthodes. Et le temps moyen d'intégration était de deux, 3,3 minutes, ce qui signifie que toutes les 2,3 minutes, vous aviez un nouveau changement qui atterrissait sur le master et était dans un état déployable. Nous n'avons pas déployé tous les changements parce qu'essentiellement ce que nous avons fait, c'est que nous avons déplacé le goulot d'étranglement vers le pipeline de livraison, n'est-ce pas ? Et c'est, c'est une, c'est une bonne chose à avoir. Euh, mais oui, il y a différentes, il y a certaines préconditions pour pouvoir y parvenir. Euh, donc j'entends aussi beaucoup parler du développement basé sur le tronc et comment s'y prendre. Un fait amusant sur le développement basé sur le tronc est que c'est un sous-produit de toutes ces pratiques, euh, que vous arrivez à faire, et ensuite vous débloquez cela comme une récompense de faire ces choses parce que vous déplacez à gauche sur la qualité et vous êtes capable de l'intégrer plus tôt.
[00:46:35] Alors, débit ou qualité, je dirais débit et qualité, n'est-ce pas ? Donc je pense qu'il y a un moyen pour nous d'obtenir un gagnant-gagnant dans ce cas. Et j'aimerais aussi terminer par ce point euh que je pense qu'on nous a toujours dit que nous atteindrions et plus si nous limitions et retardions nos interactions en tant qu'humains, n'est-ce pas ? Mais je pense que vous aussi, ou j'espère que vous avez aussi une raison basée sur des données pour ne pas le croire.
[00:47:05] Euh, j'ai écrit un article pour InfoQ euh il y a quelque temps, et il a eu beaucoup de succès dans la communauté où j'ai euh parlé un peu de cette étude et d'un tas d'autres choses dont je n'ai pas eu l'occasion de parler aujourd'hui. Euh, si vous êtes intéressé, n'hésitez pas à le consulter et euh, avec cela, je voudrais vous remercier pour votre temps et votre attention et nous pouvons avoir des questions.
[00:47:49] Bonjour. Euh, merci beaucoup, j'adore la présentation. J'ai passé la majeure partie des 15 dernières années à travailler avec des équipes qui faisaient de la programmation en pair par défaut, du développement basé sur le tronc, toutes les pratiques que vous avez mentionnées, mais j'ai vu une évolution dans l'industrie, surtout au cours des cinq à dix dernières années, où elles se sont beaucoup éloignées de cela et se sont tournées vers des modèles de requêtes asynchrones. Et je suppose que certains des retards que vous avez signalés en utilisant les mathématiques et les graphiques. Euh, je suis curieux cependant, vous avez mentionné quelque chose plus tôt sur la façon dont les outils que nous utilisons, Git spécifiquement, euh, nous sommes sortis d'une communauté open source et nous avons essayé de résoudre un problème open source, ce qui est fondamentalement différent de la façon dont les entreprises structurent leurs organisations d'ingénierie. La question que j'ai est la suivante : Git est un outil intrinsèquement meilleur que SVN, ce que nous utilisions pour analyser le code, mais le modèle GitHub d'utilisation des requêtes de tirage, je ne comprends pas comment les entreprises l'ont adopté comme norme de facto. Alors, quelle est votre, euh, je suppose, observation à ce sujet ?
[00:48:51] Oui, c'est une question très importante à laquelle je n'ai pas la réponse. Euh, je pense que cela a en quelque sorte émergé à un certain point de notre industrie et je ne suis pas sûr de ce qui l'a motivé, je pense qu'il y a beaucoup de choses de fournisseurs qui circulent, faisant la promotion d'outils, n'est-ce pas, qui vont dans cette direction sans vouloir en nommer aucun. Euh, et nous je pense qu'il y a aussi le fait que la plupart des gens, comme ce que j'ai entendu aussi, euh, que tous les cinq ans, le nombre de développeurs, euh, double, ce qui signifie qu'à tout moment vous avez moins, euh, vous avez au moins 50% des développeurs qui ont moins de cinq ans d'expérience, donc maintenant nous sommes déjà au-delà de ce seuil où la plupart des gens ne se souviennent même plus de ce qui était avant. Et c'est comme, c'est un nouveau monde pour la plupart de ces gens avec qui je travaille aussi, vous savez, et il y a aussi cette hypothèse que quelque chose de plus ancien est, euh, est pire ou pas meilleur qu'aujourd'hui, n'est-ce pas ? Donc ce besoin de nouvelles choses brillantes. Euh, oui, je n'ai pas de réponse à cela, je pense, je pense que c'est une chose qui a émergé d'une manière ou d'une autre avec beaucoup de ces différents facteurs contributifs, euh, mais certainement, euh, il y a aussi cette chose avec Git, qui est que encore une fois, en parlant de l'économie du système, Git a vraiment réduit le coût du branching, il l'a rendu nul, proche de zéro. Il est donc très facile de faire des branches, et l'incitation que vous obtenez est d'avoir plus de branches. Donc je pense que c'est aussi cela, essayer de comprendre les incitations et l'économie qui entourent l'utilisation d'outils donnés, ce qui, je pense, y a également contribué. Oui, c'est mon point de vue.
[00:50:37] Merci. Une merveilleuse conférence. Je vais attendre l'enregistrement pour l'envoyer à toutes mes équipes avec lesquelles je travaille. Euh, vous avez mentionné la dynamique des pull requests au sein d'une seule équipe, n'est-ce pas ? ces deux personnes dans un environnement multi-équipes à grande échelle. Je suppose que vous aurez la même dynamique mais entre les équipes quand une équipe envoie une demande à une autre équipe. J'ai mes propres opinions là-dessus, mais j'aimerais entendre vos heuristiques, quelles sont vos pratiques et idées pour résoudre cela à l'échelle de plusieurs équipes collaborant sur la même base de code. Merci.
[00:51:13] Oui, donc je pense, euh, je pense qu'il y a quelques choses qui dépendent aussi beaucoup de l'horizon temporel de l'intervention. Il y a des choses à court terme, à moyen terme, à long terme que l'on peut faire à ce sujet. Euh, je suis un grand fan de la conception stratégique axée sur le domaine, euh, qui, je pense, aide beaucoup à essayer de comprendre où où où nous pouvons libérer plus de valeur.
[00:51:34] Euh, et, euh, parfois c'est aussi, du moins dans un des cas récents, nous avions, euh, un peu plus de fluidité en termes d'équipes, donc une recomposition dynamique des équipes ou des limites un peu moins strictes jusqu'à ce que nous essayions de trouver de meilleures limites que celles que nous avons actuellement. Donc avec ça, euh, nous utilisons aussi la, euh, l'entreprise actuelle, nous utilisons la méthode de kit complet, euh, pour planifier le travail, ce qui signifie ne commencez pas le travail si toutes les compétences nécessaires pour réaliser cette chose du début à la fin ne sont pas disponibles. Donc, cela signifie que c'est un mécanisme de planification qui, euh, empêche de tirer plus de travail que nécessaire et les gens n'essaient pas de se devancer, et puis, en conséquence, il y a moins de temps d'attente qui, qui en fait partie. Donc, oui, euh, certaines choses sont des interventions à court terme, d'autres à moyen et long terme, mais c'est un peu mon point de vue.
[00:52:28] Merci beaucoup pour la présentation. Euh, j'ai l'impression que vous essayez d'optimiser ici pour ce que vous appelez le débit, qui est en fait le délai d'une PR. Et avez-vous essayé de voir ce qui se passe quand, au lieu de regarder le délai d'une PR, vous regardez le débit d'une équipe ? Parce qu'avec la programmation en binôme, vous dites en fait que pour réaliser un ticket, une fonctionnalité, il faut deux personnes. Euh, donc vous divisez déjà par deux d'une certaine manière le débit disponible au niveau de l'équipe, ça marche pour un PR, mais comment ça se met à l'échelle au niveau de l'équipe ? Est-ce que c'est quelque chose que vous avez essayé de chercher ?
[00:53:05] Oui, c'est une question que je reçois souvent. Je pourrais en parler des heures, mais je pense que nous devons distinguer entre essayer d'éliminer le gaspillage de travailleurs inactifs et le gaspillage de travail inactif. Donc, cela signifie que si vous optimisez l'utilisation des personnes, alors ce que vous obtenez en résultat est un système qui ne répond pas et qui a d'énormes retards et des longs délais de livraison. Et les longs délais sont la magie principale pour le débit, donc si vos longs délais augmentent, il est impossible d'avoir un débit plus élevé, d'accord, et vice versa également. Donc, euh, l'objectif n'est pas de savoir à quel point certaines personnes sont occupées ou utilisées, l'objectif est de livrer de la valeur plus tôt, d'accord ? Et puis, quand vous commencez à optimiser pour cela, vous ne vous souciez pas du nombre de personnes qui vont travailler sur un élément, je veux dire, il y a des façons ou des heuristiques sur la façon de former ce groupe, mais vous devez avoir toutes les compétences nécessaires pour mener cette chose du début à la fin. Ce peut être deux personnes, trois, cinq, quatre, peu importe, mais vous voulez optimiser pour obtenir la valeur plus tôt et accélérer la cadence d'apprentissage. Je pense que, vous savez, c'est une chose typique de l'efficacité des ressources par rapport à l'efficacité des flux et il y a beaucoup d'articles et de vidéos sur ce sujet, oui, la théorie des contraintes aussi, euh, qui en parlent, c'est contre-intuitif. C'est la raison pour laquelle la plupart des entreprises ne le font pas, n'est-ce pas ? Mais c'est aussi un avantage concurrentiel pour vos entreprises, qui est encore inexploité. Je sais, je sais que cela semble irréaliste, mais oui, je veux dire, El Goldrat a passé trois ou quatre décennies à parler de cela, oui.
[00:54:57] Salut, Regan, je suis Flavian. Euh, merci pour cette merveilleuse conférence. C'était une explosion. Euh, hum, vous avez parlé de qualité et que lorsque l'engagement augmente, la qualité augmente également. Avez-vous examiné euh la qualité du produit fini également, euh, vous savez, du point de vue des QA, des PMs, et aussi du point de vue de l'utilisateur, le nombre de bugs de production ? Avez-vous observé des effets ou mesuré des effets sur ces variables ?
[00:55:32] Oui. Donc, l'un des points que j'ai mentionnés était que je ne dis pas que si vous avez un engagement élevé, vous avez une qualité supérieure. D'accord, donc je ne parlais que du côté droit, si vous avez l'engagement comme précondition pour obtenir la qualité, pour obtenir le jugement humain et que vous ne l'avez pas, alors vous n'êtes pas capable de construire la qualité que vous voulez construire, celle qui est une précondition à cela. Euh, mais je peux donc je n'ai pas mesuré ces, euh, ces métriques dont vous avez parlé. Mais ce que j'ai observé encore une fois, c'est que lorsque vous avez une latence plus faible, dans le sens où lorsque les gens commencent et finissent le travail ensemble, vous observez une qualité supérieure car le simple fait de pouvoir couper le mauvais chemin plus tôt, signifie que vous réduisez une grande partie du travail de reprise qui vous attend si vous ne le faites pas, et à cause de cela, vous avez moins, euh, moins de travail de reprise, moins d'incidents, euh, euh, ce qui signifie que vous débloquez plus de temps pour les activités à valeur ajoutée, et ensuite à cause de cela, vous devenez plus productif, c'est comme étendre la capacité d'une équipe dans un sens pour l'obtenir de cette manière. C'est un peu mon point de vue, je n'ai pas mesuré cela, mais c'est mon expérience de, euh, oui, au fil des ans. Merci.
[00:56:42] D'accord, plus de questions. Merci.

Transcription (Traduit)