Mesurer l’impact de GitHub Copilot sur la productivité de l’ingénierie – DevOps.com
La plupart des équipes de livraison de logiciels envisagent d’adopter l’IA sous une forme ou une autre pour aider les ingénieurs à accélérer leur création de valeur et à accroître leur efficacité. GitHub Copilot est l’un des premiers exemples d’assistance à l’ingénierie basée sur l’IA. Il se présente comme « votre programmeur de paire IA » et peut compléter automatiquement des lignes de code.
Les premiers utilisateurs signalent des « améliorations de productivité » allant jusqu’à 20 % grâce à GitHub Copilot. Pourtant, ce n’est pas bon marché (à 10 $ par utilisateur et par mois), alors comment pouvez-vous élaborer une analyse de rentabilisation pour GitHub Copilot ?
La plupart des organisations élaborent une analyse de rentabilisation autour des gains de productivité et de la valeur associée que GitHub Copilot peut apporter. Mais quelle méthodologie (et métriques) devriez-vous utiliser pour évaluer avec précision l’impact sur la productivité et la création de valeur d’un outil comme GitHub Copilot ?
GitHub Copilot : assistance IA de première génération pour les ingénieurs logiciels
Copilot est clairement le début d’un voyage long et accéléré à mesure que l’IA est appliquée à de nombreux domaines du SDLC. Il utilise le Codex OpenAI pour suggérer du code et des fonctions entières en temps réel depuis votre éditeur.
D’autres outils d’IA arrivent presque quotidiennement et peuvent aider les ingénieurs logiciels de nombreuses manières à gagner du temps et à améliorer leur efficacité. Voici quelques exemples :
- Grit.io aidera à gérer la dette technique
- Mintlify fournit une documentation automatisée pour les développeurs
- Code AI aide à traduire (certaines) langues, à déboguer, à naviguer dans le code et à agir en tant que programmeur en binôme
- Et des outils comme AdrenalineAI utilisent l’IA pour améliorer la compréhension de votre base de code.
Ainsi, lorsque le contrôle des coûts est à l’ordre du jour, vous vous demandez peut-être comment quantifier avec précision l’impact d’outils comme ceux-ci et justifier les dépenses supplémentaires.
Une méthodologie pour mesurer l’impact d’un outil comme GitHub Copilot
Pour mesurer de manière robuste l’impact de GitHub Copilot (et des outils similaires d’amélioration de l’ingénierie de l’IA), la méthodologie doit être :
- Quantitatif : basé sur des données concrètes et mesurables
- Holistique : prise en compte de tous les avantages et impacts potentiels tout au long du SDLC (cycle de vie de livraison de logiciels) de bout en bout
- Équilibré : inclut des données d’enquête subjectives ainsi que des données sur la livraison de logiciels.
Cela nécessite un tableau de bord de métriques qui capture pleinement les avantages et les coûts potentiels de GitHub Copilot. Les métriques reflètent le cadre SPACE pour mesurer la productivité des développeurs, en mettant l’accent sur les domaines clés que GitHub Copilot aura probablement un impact.
Ces métriques peuvent être suivies au fil du temps pour un groupe représentatif d’utilisateurs de GitHub afin de voir l’effet « avant et après ». Nous suggérons qu’un échantillon représentatif inclurait des ingénieurs d’ancienneté et d’activité différentes – et que la période d’analyse serait d’au moins trois cycles de sprint (par exemple, six semaines ou plus).
Indicateurs clés pour quantifier l’impact de GitHub Copilot
Une plate-forme d’analyse de livraison de logiciels de bout en bout fournit un panneau unique pour mesurer l’impact réel d’un outil comme GitHub Copilot.
Il présente une gamme de mesures d’ingénierie et de livraison de logiciels pour capturer l’impact de GitHub Copilot sur cinq variables clés qui déterminent la « productivité » :
- Vitesse et débit – Mesures du « résultat » de l’équipe
- Délai de rentabilisation – Temps nécessaire pour fournir un incrément de logiciel
- Qualité
- Fiabilité – Un avantage clé si les équipes respectent leurs plans de manière plus fiable
- Satisfaction des développeurs – Impact sur l’accélération des tâches répétitives/moins intéressantes
Ces métriques peuvent être suivies au fil du temps pour un groupe de contrôle GitHub Copilot par rapport aux non-utilisateurs.
1. Mesures de vitesse et de débit
Débit est une mesure essentielle du « résultat » au fil du temps pour les équipes Scrum et Kanban, et peut être calculée en tickets, story points, pull request, builds ou points de valeur. Un outil d’analyse de livraison doit calculer le débit par ingénieur pour les utilisateurs et les non-utilisateurs de GitHub CoPilot. Cela peut être exprimé en pourcentage d’augmentation.
Vitesse de sprint considère le rythme de travail réalisé au cours d’un sprint et comment il varie dans le temps. Il peut être calculé en tickets ou en story points. Des outils d’analyse avancés vous montreront également la quantité de travail reportée par le sprint pour obtenir une mesure sous-jacente encore meilleure de la livraison. Il s’agirait d’une mesure clé si l’on considère l’impact de GitHub Copilot.
2. Délai de rentabilisation
Temps d’un cycle est une mesure de base de livraison de logiciels agiles qui suit la capacité d’une organisation à livrer des logiciels tôt et souvent. Il calcule le temps nécessaire pour fournir un incrément de logiciel depuis le début du développement jusqu’au déploiement. Plus le temps de cycle est court, plus les boucles de rétroaction sont courtes et plus rapidement l’organisation recevra de nouvelles fonctionnalités et répondra aux besoins des clients. Il s’agit d’un KPI essentiel lors de l’évaluation de l’efficacité de la fourniture de technologies.
Temps de cycle de code représente généralement 20 à 30 % de la durée globale du cycle. Il calcule le temps moyen écoulé entre l’ouverture d’une pull request (PR) et sa fusion/fermeture. La majeure partie de ce temps est généralement consacrée au processus d’approbation.
En théorie, GitHub CoPilot permet un développement plus rapide et plus facile. Par conséquent, les développeurs devraient avoir une plus grande disponibilité pour examiner les PR de chacun. Si la qualité du code est améliorée, le résultat des révisions devrait alors entraîner moins de modifications demandées et un délai d’approbation.
3. Qualité
Défauts échappés est une mesure simple mais efficace de la qualité globale de la livraison des logiciels. Il peut être suivi de nombreuses manières, mais la plupart impliquent le suivi des défauts par criticité/priorité.
Toute analyse de l’efficacité de la livraison avant/après la mise en œuvre de GitHub Copilot doit prendre en compte les taux de défauts échappés, car ce serait un mauvais compromis d’augmenter la vitesse et la « productivité » au détriment de la qualité.
Taux d’échec de construction identifie le pourcentage de builds qui échouent et le risque global que cela représente pour une équipe travaillant de manière productive. Des changements notables dans le taux d’échec après la mise en œuvre de GitHub Copilot indiquent que la qualité du code peut être affectée.
4. Fiabilité
Achèvement de l’objectif de sprint suit le pourcentage des objectifs de sprint atteints à chaque cycle. Les « équipes Scrum » et les « sprints » sont les éléments de base de la livraison de logiciels Scrum Agile. Si les équipes Scrum atteignent systématiquement leurs objectifs de sprint, la livraison de logiciels Agile devient relativement fiable, permettant de prédire les résultats de livraison au sein de plusieurs équipes et sur des périodes plus longues.
La prévisibilité de l’équipe Scrum est donc un critère de réussite essentiel dans la livraison de logiciels Agile. Si GitHub Copilot peut améliorer la probabilité qu’une équipe livre ses tickets plus rapidement et avec moins de bugs, cela contribue grandement à l’amélioration globale de l’efficacité.
5. Satisfaction des développeurs
eNPS suit la satisfaction et la fidélité des employés au sein des équipes et des organisations. Des rapports anecdotiques suggèrent que les développeurs trouvent que GitHub Copilot gère les aspects les plus fastidieux de le codage est moins pénible et a un impact positif sur le bien-être. Un NPS des employés rend cela simple à valider et à quantifier.
Bien qu’il s’agisse d’un facteur important de mesure de la productivité, il ne doit pas être considéré isolément des autres mesures lors de la quantification de la productivité globale des développeurs.
Voici quelques exemples de mesures pertinentes à prendre en compte lors de l’analyse de l’impact de GitHub Copilot sur la productivité de la livraison. La clé est d’adopter un ensemble équilibré de mesures qui considèrent de manière globale la livraison de logiciels comme un processus complexe.
Combiner le tableau de bord équilibré des métriques pour créer une analyse de rentabilisation pour GitHub Copilot
En règle générale, nous combinerions les données du « tableau de bord équilibré » des métriques discutées ci-dessus à l’aide de pondérations simples pour créer une évaluation globale de l’impact sur la productivité (PIA) de GitHub Copilot. Voir le tableau ci-dessous :
Évaluation de l’impact sur la productivité de GitHub CoPilot – Exemple de modèle
Améliorations de la productivité grâce à l’utilisation de GitHub Copilot – Les données empiriques
Il y a un manque flagrant de données indépendantes à cet égard.
La propre enquête de GitHub auprès de 2 000 développeurs a montré que 88 % des développeurs affirmaient « être plus productifs » lorsqu’ils utilisaient l’outil, tandis qu’un test de tâches entrepris par 95 développeurs a montré que le groupe qui utilisait GitHub Copilot était 55 % plus rapide et avait un taux 7 % plus élevé. de terminer la tâche (voir ci-dessous).
Données d’enquête de GitHub – L’impact du copilote GitHub sur les utilisateurs (2022)