Malheureusement, nous ne vivons pas dans un monde idéal où chaque développeur a un niveau de productivité idéal et équilibré, tout en se concentrant sur les tâches et en les réfléchissant de l'un à l'autre. La collaboration d'équipe n'est pas toujours conçue de manière à ce que tous les membres de l'équipe travaillent avec une efficacité maximale. Comme pour de nombreux problèmes en général, le développement précoce de l'équipe de développement permet d'économiser des ressources, de gérer les nerfs et de créer une bonne atmosphère de travail.
Dans une petite équipe, le chef d'équipe peut essayer de juger tout ce qui se passe sur la base de sentiments subjectifs, mais plus l'entreprise est grande, plus il est important d'utiliser des données et des mesures objectives.
Alexander Kiselev (
AleksandrKiselev ) et
Sergey Semenov dans leur rapport sur
TeamLead Conf ont montré comment utiliser les données que vous avez déjà accumulées, où obtenir des données supplémentaires et qu'ensemble, ils peuvent aider à identifier les problèmes non évidents. Et même, après avoir accumulé l'expérience de nombreux collègues, ils ont proposé des solutions.
À propos des intervenants: Alexander Kiselev et Sergey Semenov, nous travaillons dans l'informatique depuis plus de 8 ans. Tous deux sont passés du développeur au chef d'équipe et ensuite au chef de produit. Maintenant, ils travaillent sur le service analytique GitLean, qui recueille automatiquement les analyses des équipes de développement pour les chefs d'équipe et le CTO. L'objectif de ce service est que les responsables techniques puissent prendre leurs décisions sur la base de données objectives.
Énoncé du problème
Nous avons tous deux travaillé en tant que chefs d'équipe et avons souvent été confrontés au problème d'incertitude et d'ambiguïté dans notre travail.
En conséquence, il était souvent nécessaire de prendre des décisions à l'aveugle, et parfois il n'était pas clair si c'était mieux ou pire. Par conséquent, nous avons examiné les solutions existantes sur le marché, examiné les méthodologies d'évaluation de la performance des développeurs et réalisé qu'il n'existait aucun service répondant à nos besoins. Par conséquent,
nous avons décidé de le créer nous-mêmes .
Aujourd'hui, nous allons parler de ce que vous pouvez dire des données que vous avez déjà accumulées, mais ne les utilisez probablement pas.
Cela est nécessaire dans deux cas principaux.
L'examen des performances est un processus assez complexe et subjectif. Ce serait formidable de collecter automatiquement des faits sur le travail du développeur.
Nous nous sommes entretenus avec des représentants d'une grande entreprise allemande avec une grande équipe de développement. Environ une fois par an, ils ont interrompu l'intégralité du travail de développement pendant 2 semaines, et toute l'entreprise n'a effectué une évaluation des performances - les développeurs ont écrit des dénonciations anonymes toute la journée à leurs collègues avec lesquels ils ont travaillé pendant un an. Si cette entreprise avait la possibilité de collecter automatiquement des faits, elle gagnerait une tonne de temps.
Le deuxième aspect est le
suivi de la situation actuelle dans l'équipe. Je veux comprendre rapidement les problèmes qui se posent et y répondre rapidement.
Options de décision
Il peut y avoir plusieurs solutions.
Tout d'abord, vous
ne pouvez
pas utiliser d'analyse du tout , mais uniquement votre évaluation subjective. Cela fonctionne si vous êtes chef d'équipe dans une petite équipe. Mais si vous êtes déjà CTO, et que vous avez beaucoup d'équipes, alors vous ne pourrez pas utiliser votre évaluation subjective, car vous ne savez pas tout. Vous devrez recourir à une évaluation subjective de vos timlids, et c'est un problème, car bien souvent les timlids abordent l'évaluation subjective de manière très différente.
C'est la prochaine chose à faire. Étant donné que l'évaluation subjective ne suffit souvent pas, vous pouvez
être confus et
recueillir des faits à la main .
Par exemple, un CTO avec qui nous avons parlé soupçonnait l'équipe de faire un examen du code trop lentement, mais il n'y avait rien à leur présenter. Comme il n'avait qu'un vague sentiment, il a décidé de recueillir les faits, juste quelques semaines pour regarder l'équipe. Le CTO a enregistré le temps qu'il a fallu à l'équipe pour passer en revue, et ce qu'il a découvert à la fin l'a choqué. Il s'est avéré que 2 aînés étaient en conflit depuis longtemps dans la révision du code, alors qu'ils ne l'ont pas retiré du tout. Ils étaient assis comme des souris, personne ne criait à personne - l'équipe n'était pas du tout au courant. La seule chose qu'ils ont faite était de se rendre périodiquement à la glacière, de se verser un peu plus d'eau et de courir pour écrire des réponses pleines d'esprit dans une revue de code à leur ennemi en pull-request.
Lorsque le CTO l'a découvert, il s'est avéré que le problème était tellement ancien qu'il était impossible de faire quoi que ce soit, et à la fin l'un des programmeurs a dû être licencié.
Les statistiques Jira sont une option souvent utilisée. Il s'agit d'un outil très utile dans lequel il existe des informations sur les tâches, mais il est assez élevé. Il est souvent difficile de comprendre ce qui se passe spécifiquement dans une équipe.
Un exemple simple - le développeur du sprint précédent a fait 5 tâches, celle-ci - 10. Est-il possible de dire qu'il a commencé à mieux travailler? C'est impossible, car les tâches sont complètement différentes.
La dernière solution qui existe consiste à simplement retrousser vos manches et à écrire
votre propre script pour la collecte automatique des données . C'est de cette façon que viennent tous les CTO des grandes entreprises. Il est le plus productif, mais, bien sûr, le plus difficile. C'est de lui que nous parlerons aujourd'hui.
Solution choisie
Ainsi, la solution choisie consiste à entailler vos scripts pour collecter des analyses. Les principales questions sont de savoir où obtenir des données et quoi mesurer.
Sources de données
Les principales sources de données dans lesquelles les informations sur le travail du développeur sont accumulées sont:
- Git - les principales entités: commits, branches et code à l'intérieur.
- Outils de révision de code - les services d'hébergement git qui hébergent les révisions de code contiennent des informations sur les pull-request qui peuvent être utilisées.
- Suivi des tâches - informations sur les tâches et leur cycle de vie.
Sources de données auxiliaires:
- Messagers - vous pouvez, par exemple, effectuer une analyse des sentiments, calculer le temps de réponse moyen du développeur à une demande d'informations.
- Services CI qui stockent des informations sur les versions et les versions.
- Sondages d'équipe.
Étant donné que toutes les sources dont j'ai parlé ci-dessus sont plus ou moins standard, et la dernière n'est pas si standard, je vais en parler un peu plus.
Un autre directeur technique a partagé cette méthode avec nous. À la fin de chaque itération, il a envoyé automatiquement un sondage à l'équipe, dans lequel il n'y avait que 2 questions:
- À votre avis, quelle était l'importance de ce que nous avons fait dans cette itération?
- Pensez-vous que ce que nous faisons était intéressant?
C'est un moyen assez bon marché de mesurer l'humeur d'une équipe et, peut-être, d'attraper des problèmes de motivation.
Quoi et comment mesurer
Tout d'abord, nous discuterons de la méthodologie de mesure. Une bonne métrique devrait répondre à 3 questions:
- Est-ce important? Il suffit de mesurer ce qui signale quelque chose d'important pour l'entreprise.
- A-t-il empiré / amélioré / le même? Par métrique, il devrait être clair si c'est devenu meilleur ou pire.
- Que faire D'après la métrique, il devrait être clair quoi faire pour rectifier la situation.
En général, il vaut la peine de suivre le principe:
Mesurez ce que vous voulez et pouvez changer.
Il convient de mentionner tout de suite qu'il n'y a pas de métrique universelle, et nous ne parlerons pas d'une métrique universelle aujourd'hui pour les raisons suivantes:
- Le développeur a de nombreux aspects de son activité - il travaille avec les exigences, écrit du code, teste, effectue des révisions de code, effectue des déploiements - et il est impossible de mettre tout cela dans une seule métrique universelle. Par conséquent, il est préférable de se concentrer sur les cas individuels qui peuvent être détectés.
- La deuxième raison pour laquelle la seule métrique ne vaut pas la peine est qu'une métrique est facile à contourner, car les développeurs sont des gens assez intelligents et ils sauront comment le faire seuls.
Nouvelle approche
Par conséquent, nous avons formulé une approche dans laquelle nous allons des problèmes: nous essayons d'identifier des problèmes spécifiques et de sélectionner un ensemble de métriques pour eux qui les détectera. Un bon développeur sera appelé le développeur avec le moins de problèmes.
Sur quoi est basé notre choix de problèmes? C'est simple: nous avons mené une entrevue avec 37 CTO et chefs d'équipe qui ont parlé des problèmes qu'ils ont dans leurs équipes et comment ils résolvent ces problèmes.
L'énorme liste résultante, nous avons priorisé et collecté des hacks de vie et des mesures pour ces problèmes. Nous avons divisé tous les problèmes en 2 groupes:
- Problèmes d'un développeur individuel (le développeur est responsable de ces problèmes).
- Problèmes d'équipe. L'équipe est responsable de ces problèmes; en conséquence, pour les résoudre, vous devez travailler avec l'équipe dans son ensemble et changer les solutions de processus.
Examinons en détail chaque problème, quelle clé des métriques à celui-ci peut être sélectionnée. Commençons par les problèmes les plus simples et progressons lentement le long du gradient de complexité vers les plus difficiles à mesurer.
Problèmes de développeur
Développeur peu performant
De plus, «peu de performances» signifie généralement que le
développeur ne fait presque rien . Conditionnellement, un ticket est accroché à Jira, il en fait un rapport, mais vraiment aucun travail ne se passe. Il est clair que ce problème se posera tôt ou tard, vous le trouverez, mais ce serait cool de le faire automatiquement.
Comment cela peut-il être mesuré?La première chose qui me vient à l'esprit est simplement de regarder le
nombre de jours actifs avec le développeur. Le jour actif sera appelé le jour où le développeur a effectué au moins une validation. Pour les développeurs à plein temps, en fait, le nombre caractéristique de jours actifs par semaine est d'au moins 3. Si moins, alors nous commençons à soupçonner le développeur qu'il ne fera pas beaucoup.
De toute évidence, le nombre de jours actifs ne suffit pas. Un développeur pourrait simplement écrire du code et ne pas le valider - a écrit, écrit, puis un jour a validé un tas de code.
Par conséquent, la prochaine limitation que nous imposons est que le développeur doit également avoir un
peu de code . Comment déterminer le seuil "petit code"? Nous vous recommandons de le mettre suffisamment petit pour que n'importe qui, autant qu'un développeur performant, puisse facilement le surmonter. Par exemple, dans notre service pour JS, cela représente environ 150 lignes de code et pour Clojure - 100 lignes de code.
Pourquoi un si petit seuil? L'idée est que nous voulons séparer non pas les développeurs qui travaillent bien de ceux qui travaillent en moyenne, mais ceux qui ne font presque rien, de ceux qui font au moins une quantité raisonnable de travail.
Mais même si le développeur a peu de jours actifs et peu de code, cela ne veut pas du tout dire qu'il n'a pas fonctionné. Il pourrait, par exemple, faire des corrections de bogues qui nécessitent une petite quantité de code. En conséquence, une personne semble avoir effectué de nombreuses tâches, mais elle peut avoir peu de code et des jours actifs. Autrement dit, nous prenons en compte le
nombre de tâches .
La prochaine chose à surveiller est la
quantité de révision de code qu'il a faite, car une personne ne pouvait pas effectuer de tâches et ne pas écrire de code, mais être complètement immergée dans la révision de code. Ça arrive.
Par conséquent, si pour toutes ces mesures - et seulement ainsi! - le développeur n'atteint aucun seuil, vous pouvez le soupçonner de ne pas bien performer.
Que faire à ce sujet?Premièrement, si vous connaissez une raison légitime, vous n'avez rien à faire du tout - par exemple, un développeur est formé ou a un jour de congé. Si vous ne connaissez pas la raison légitime, cela vaut probablement la peine de
parler à une personne. Si une raison légitime n'apparaît pas, il vaut la peine de la surveiller davantage et si ce problème continue de se répéter parfois, il vaut probablement la peine de dire au revoir à un tel développeur.
C'était le problème le plus simple et le plus provocateur. Passons aux plus lourds.
Le développeur recycle
C'est aussi une histoire courante. Si une personne la traite, elle s'épuise, finit par se démotiver et, par conséquent, peut quitter l'entreprise. L'un des responsables techniques avec qui nous avons parlé a raconté une telle histoire. Il a travaillé pour une entreprise américaine dans laquelle la culture des rallyes s'est fortement développée. En conséquence, tous les développeurs, quand ils sont venus travailler, ont juste fait ce qu'ils ont rassemblé, et ils ont écrit le code après les heures et le week-end. En conséquence, le chiffre d'affaires annuel des développeurs de l'entreprise a atteint 30%, bien que la norme de l'industrie soit de 6%.
En conséquence, toute direction technique composée de 30 personnes a été licenciée de ce bureau. Afin de ne pas en parler, je veux trouver ce problème à temps.
Comment cela peut-il être mesuré?En fait, rien n'est trop compliqué - regardons la
quantité de code que le développeur écrit après les heures. Si cette quantité de code est conditionnellement comparable ou supérieure à ce qu'elle fait pendant les heures de travail, le développeur le traite explicitement.
De toute évidence, les développeurs ne vivent pas comme un seul code. Un problème courant est qu'il y a suffisamment de temps pour le code - le travail principal - mais plus pour la révision du code. Par conséquent, la révision du code est reportée le soir ou le week-end. Cela peut être suivi simplement par le
nombre de commentaires dans la pull-request après les
heures .
Le dernier déclencheur explicite est un
grand nombre de tâches parallèles . Il y a une limitation raisonnable de 3-4 tâches pour le développeur. Vous pouvez les suivre par git ou par Jira - comme vous le souhaitez. Cela fonctionne plutôt bien.
Que faire à ce sujet?Si vous trouvez un développeur de recyclage, vous devez d'abord
vérifier son calendrier pour voir s'il est surchargé de rallyes inutiles. S'il est surchargé, il est conseillé de les réduire, et idéalement de faire une journée de réunion - une journée dédiée où le développeur concentrera la plupart de ses plus longues réunions afin qu'il puisse travailler normalement les autres jours.
Si cela ne fonctionne pas, il est nécessaire de
redistribuer la charge . C'est en fait une question assez compliquée - comment le faire. Il existe de nombreuses façons différentes. Nous n'irons pas en profondeur, mais notons le
rapport cool sur HighLoad 2017 d'Anton Potapov, dans lequel ce sujet a été examiné de très près.
Le développeur ne se concentre pas sur la publication des tâches
Je veux comprendre combien de ces développeurs sont dans votre équipe et combien cela coûte en temps.
Il est assez courant qu'un développeur prenne une tâche, la remette au statut en cours d'examen, de test - et l'oublie. Ensuite, elle revient pour révision et accroche là pas clair combien de temps. J'ai moi-même eu un développeur dans mon équipe à un moment donné. J'ai sous-estimé le problème pendant longtemps, jusqu'à ce qu'une fois que je calcule le temps qui, en moyenne, prend différents temps d'arrêt. En conséquence, il s'est avéré que les tâches de ce développeur, en moyenne, restaient inactives 60% du temps de sortie.
Comment cela peut-il être mesuré?Tout d'abord, vous devez mesurer tous les temps d'arrêt qui dépendent du développeur. C'est le moment de corriger
après la révision et le test du code . Si vous avez une livraison continue, il s'agit
du délai de libération. Une restriction raisonnable devrait être imposée à chacune de ces heures - par exemple pas plus d'une journée.
La raison est la suivante. Lorsqu'un développeur vient travailler le matin, il serait intéressant pour lui d'analyser d'abord les tâches les plus prioritaires. Les tâches les plus prioritaires, s'il n'y a pas de correction de bogue ou quelque chose de très important, sont les tâches les plus proches de la publication et de la publication.
Un autre déclencheur intéressant sur ce sujet est la
quantité de révision de code qui pèse sur le développeur, comme sur un réviseur. Si une personne oublie ses tâches, il est très probable qu'elle se rapportera également aux tâches de ses collègues.
Que faire à ce sujet?Si vous trouvez un tel développeur, cela vaut clairement la peine de lui
parler : "Regardez, c'est 30 à 40% de votre temps consacré aux temps d'arrêt!" Cela fonctionne généralement très bien. Dans mon cas, par exemple, cela a eu un tel effet, que le problème a presque complètement disparu, sinon, vous devez continuer à
surveiller , disons périodiquement, mais l'essentiel ici n'est pas de tomber dans la microgestion, car ce sera encore pire.
Par conséquent, dans la mesure du possible, il vaut la peine de traiter immédiatement les solutions de processus. Cela peut être, par exemple, des
limites sur le nombre de tâches actives , ou, si votre budget et votre temps le permettent, vous pouvez écrire un bot ou utiliser un service qui enverra automatiquement une
requête ping au développeur si la tâche a été dans un certain état pendant trop longtemps. C'est probablement la solution la plus cool ici.
Le développeur ne pense pas à suffisamment de tâches
Je pense que vous connaissez les symptômes - ce sont des estimations incompréhensibles du temps nécessaire pour terminer les tâches dans lesquelles nous ne tombons pas, les longs délais à la fin, l'augmentation du nombre de bogues dans les tâches - en général, rien de bon.
Comment cela peut-il être mesuré?Je pense que vous connaissez les symptômes - ce sont des estimations incompréhensibles du temps nécessaire pour terminer les tâches dans lesquelles nous ne tombons pas, les longs délais à la fin, l'augmentation du nombre de bogues dans les tâches - en général, rien de bon.
Comment cela peut-il être mesuré?Pour ce faire, nous devons introduire 2 métriques, dont la première est le code Churn.
Le taux de désabonnement est une mesure de la quantité de code qu'un développeur écrit conditionnellement en vain.
Imaginez la situation. Lundi, le développeur a commencé à effectuer une nouvelle tâche et a écrit 100 lignes de code. Puis, mardi, il a écrit 100 nouvelles lignes de code dans cette tâche. Mais, malheureusement, il est arrivé que 50 lignes de code écrites lundi, il supprime et libère la tâche. En conséquence, 200 lignes de code semblaient avoir été créées dans la tâche, mais seulement 150 ont survécu jusqu'à la sortie, et 50 ont été écrites en vain. Ces 50 nous appelons Churn. Et donc dans cet exemple, le développeur Churn était de 25%.
À notre avis, un
niveau élevé de désabonnement est un déclencheur sympa que le développeur n'a pas pensé à la tâche.
Il existe une étude réalisée par une société américaine dans laquelle elle a mesuré le niveau de désabonnement de 20 000 développeurs et est arrivée à la conclusion qu'un bon code de désabonnement devrait se situer entre 10 et 20%.
Mais il y a 2 conditions importantes:
- High Churn est parfait si, par exemple, vous faites un prototype ou un nouveau projet. Ensuite, il peut être égal à 50-60% pendant plusieurs mois. Il n'y a rien à craindre. , Churn — , .
- Churn — . . - . delivery .
, , , , Fixed Tasks,
. , .
, bug fixes , bug fixes . bug fixes 3 , , . , , , .
—
. , , , - .
?, , ,
. , ,
, estimation ..
CTO, , workflow, , . , , ,
- , .
Churn Fixed Tasks, , :
- commit message, . commit message, , git .
- git-squash commit' , Churn .
- git. merge master, merge , . — , , Churn Fixed Tasks.
, —
, . , , , . , - .
, , - 3-4 . , .
?— - , , .
, 3 , , ( ), .
, , . — , .
— ,
— — , , .
?. , , . - , .
— , , . . , , . .
30-50 50-60 %. , .
, , . , , , .
.
, —
. product- , . , , .
?product- , ?
, product- , :
- Churn, ;
- , , estimation;
- in progress product-.
?product- : «, Churn - — ».
« » , 1-2 . , product-, .
. , , .
, , , . , , - , , . , . .
?, , :
?-, , ,
, .
-, , , ,
, , .
— - , . best practise, , , , . 3 , 3 .
, —
. , . - , , -. , , CTO, , 100%. , - .
?,
legacy refactoring . , . . , , , .
,
legacy refactoring , ,
complexity , , .
?, , . , CTO. , .
CTO , , Jira
«» . , - estimation . , — , ..
CTO . , , ,
«Hack». - -, : « Hack — », . grep' «Hack» , .
. .
:
- . , , Churn legacy refactoring. , .
- . , , , — git , git-. — , .
- , . , , .
- La plupart des mesures que nous avons répertoriées ici ne fonctionnent que pour les développeurs multtime, car seules les activités des développeurs multtime sont bien reflétées dans les sources de données disponibles: git, Jira, GitHub, messageries instantanées, etc.
Conclusions
Nous voulions vous transmettre les éléments suivants:
- Les développeurs et l'équipe peuvent et doivent être mesurés . Cela peut être difficile, mais cela peut être fait.
- Il n'y a pas de petit ensemble universel de KPI . Pour chaque problème, vous devez sélectionner votre ensemble de mesures hautement spécialisé. Il ne faut pas oublier que vous ne devez pas négliger même les mesures les plus simples. Ensemble, ils peuvent bien fonctionner.
- Git peut dire beaucoup de choses intéressantes sur le développement et les développeurs, mais vous devez suivre certaines pratiques afin que les données soient facilement accessibles à partir de celui-ci, notamment:
- nombre de tâches dans les validations;
- pas de courge;
- Vous pouvez déterminer l'heure de sortie: fusion dans le master, tags.
Liens et contacts utiles:- Il y a plusieurs problèmes de bonus et mesures pour eux dans la présentation de la présentation .
- Blog des auteurs avec des articles utiles pour les responsables du développement
- Contacts télégrammes: @avkiselev (Alexander Kiselev) et sss0791 (Sergey Semenov).
Chez TeamLead Conf, ils discutent de nombreux problèmes différents de gestion d'une équipe de développement et recherchent des solutions. Si vous avez déjà parcouru une partie du chemin, rempli plus d'une bosse, monté sur un râteau, essayé différentes approches et êtes prêt à tirer des conclusions et à partager votre expérience - nous vous attendons. Vous pouvez postuler pour un spectacle jusqu'au 10 août .
Les participants devraient également être plus impliqués, commencer par réserver un billet , puis essayer de formuler ce qui vous passionne le plus - vous pourrez ensuite discuter de votre douleur et tirer le meilleur parti de la conférence.