Mesurer la productivité de l'ingénierie est un processus complexe : il est difficile d'avoir une idée complète de la façon dont les développeurs passent leur temps. Une façon courante de mesurer la productivité consiste à analyser les métriques du système telles que DORA ou SPACE. Ces mesures peuvent être extrêmement utiles pour comprendre la productivité de l’équipe par rapport aux normes de l’industrie. Plonger dans chacune de ces mesures peut également fournir un aperçu de ce qui ralentit l'équipe. Mais parfois, il existe également des « poches cachées » de temps que les développeurs passent tout au long de leur journée et qui peuvent ne pas être perçues comme ayant un impact sur la productivité. Cependant, lorsque l’on commence à additionner ces éléments, les chiffres peuvent être alarmants. Par exemple, considérons le temps qu'un développeur passe à déboguer un test irrégulier pour essayer de déterminer s'il a échoué à cause de sa modification ou non. Ou le temps passé par un développeur à essayer de résoudre un échec de build principal. Pour fournir cette perspective, nous avons construit un calculateur qui permet d'évaluer l'efficacité de l'ingénierie. Cela ne fournit en aucun cas une analyse complète de l’efficacité de votre équipe d’ingénierie. Ce qu'il donne, c'est un aperçu des « poches cachées » de temps perdu qui n'apparaissent généralement pas dans les mesures de productivité plus courantes. Le calculateur se concentre sur le temps que vous et votre équipe perdez en raison des échecs de construction et de test dans les flux de travail des développeurs. Si vous comparez cela aux métriques DORA, le délai de modification est considérablement affecté par l'instabilité de la construction et des tests. Cet impact peut être évalué à l’aide de ce calculateur. Comment ça fonctionne Nous vous demandons de saisir des données en fonction de vos activités GitHub et de la façon dont vous utilisez les branches GitHub. Pour expliquer les calculs réels ci-dessous, attribuons des variables à chacun d'eux : M – PR fusionnés par jour X – pannes de ligne principale en une semaine T – temps moyen d’IC F – facteur de desquamation % Sur la base de ces informations, nous estimons le temps que votre équipe d'ingénierie perd chaque semaine à gérer les échecs de construction et à gérer les tests irréguliers. Passons en revue les résultats un par un. Des heures perdues à réparer Cela calcule le nombre d'heures perdues pour identifier, trier, corriger et faire réussir à nouveau la build lorsqu'un échec de build principal est détecté. En règle générale, dans une grande équipe, quelqu'un remarquera et signalera la version principale cassée. Nous supposons qu'un échec de build principal implique en moyenne 1 à 3 développeurs pour déboguer et corriger. Si nous considérons en moyenne une heure pour le temps nécessaire pour que le problème soit signalé et qu'un correctif soit proposé, nous passons à suivre, enquêter et résoudre le problème. (2*T + 1) heures Cela signifie que s'il y a X échecs par semaine, nous passons (( en temps de développeur pour lutter chaque jour contre les échecs de construction principale. 2 développeurs * X/5 * (2*T + 1)) heures Heures perdues à résoudre les conflits de fusion Les restaurations et les conflits de fusion peuvent entraîner d'autres problèmes. En supposant qu'il y a environ 2 % de PR qui ont des conflits de fusion pendant la fenêtre de temps de construction interrompue et que les PR arrivent toutes les heures, nous dépenserons gaspillés dans la résolution de ces conflits. ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0,02 * M/8 Échecs hebdomadaires du CI en raison de builds cassés Si l'équipe n'utilise pas de branche dorée sur laquelle baser ses branches de fonctionnalités, elle créera probablement des branches de fonctionnalités au-dessus d'une branche principale défaillante. Étant donné que le nombre de PR créés à tout moment serait similaire au nombre moyen de branches de fonctionnalités basées sur la ligne principale, cela entraînerait un nombre d'échecs de CI se produisant chaque jour. . (2*T + 1 heure) * X/5 * M/8 Il est temps de résoudre CI Avec environ quinze minutes de changement de contexte à chaque échec de build, cela représente heure de temps de développeur perdu chaque jour avec des échecs de CI. (2*T + 1 heure) * X/5 * M/8 * 0,25 Temps passé à réexécuter des tests irréguliers. De même, avec les tests irréguliers, le temps de changement de contexte nécessaire pour déterminer si le test était irrégulier ou réel, et la réexécution des tests eux-mêmes prend en moyenne quinze minutes par exécution. En fonction du facteur de desquamation, les développeurs perdraient heures chaque jour. (0,25 * M * F / 100) Améliorer l'efficacité Bien que la plupart de ces éléments aient un impact sur les métriques DORA associées au nous ne faisons encore qu'effleurer la surface en termes de mesure des inefficacités dans les flux de travail des équipes d'ingénierie. L'impact des échecs de construction et de test entraîne également des retards de publication ayant un impact sur les autres mesures DORA telles que et la persistance de tests irréguliers dans le système, ce qui peut entraîner un risque plus élevé de taux d'échec. . délai de modification, la fréquence de déploiement, le temps de restauration du service En savoir plus sur les métriques DORA Ou apprenez-en davantage sur leurs inconvénients. Nous avons créé pour résoudre certains de ces défis cachés auxquels sont confrontées les grandes équipes d'ingénierie. Aujourd'hui, grâce à Aviator MergeQueue, de nombreuses organisations d'ingénierie peuvent faire évoluer leur flux de travail de fusion sans interrompre les builds. En combinant cela avec un système de suppression de tests instable comme , les équipes peuvent économiser des centaines d'heures d'ingénierie chaque semaine. Aviator TestDeck Également publié . ici
