Motivés par certaines nouvelles récentes sur les fusions et acquisitions et les pressions générales sur la productivité en période de budgets serrés, nous présentons quelques anti-modèles à l’utilisation des métriques d’ingénierie et donnons un aperçu de la façon d’utiliser les métriques pour des informations sur la productivité à la place. Tout d’abord, commençons par ce qu’il faut éviter :
Anti-modèle aux métriques d’ingénierie
Lignes de code écrites: Bien que les lignes de code puissent être une mesure indirecte de la quantité de code que vous devez maintenir (et donc des coûts à engager), il s’est avéré qu’il s’agit d’une mesure terrible pour la productivité. Cela ne devrait pas nécessiter beaucoup d’explications, mais : Le résultat n’est pas nécessairement égal au résultat. Différents langages de programmation ont une verbosité différente, et par exemple, le simple fait d’inclure certains packages open source ou de coller du code de Stack Overflow ne vous rend pas plus productif. Et, bien sûr, la résolution de problèmes difficiles ne nécessite souvent pas beaucoup de code, mais beaucoup de réflexion, d’exploration et de collaboration.
Complexité ou saillance du code: Un code complexe n’est pas un bon code. Quelqu’un d’autre doit le lire, le comprendre et le maintenir. Le code saillant (interprétons-le comme « le plus remarquable ») peut être intéressant à noter, mais cela ne fait pas de vous un bon joueur d’équipe et ne montre aucune cohérence. Un point clé ici : le développement de logiciels est un sport d’équipe. Cependant, chaque entreprise a des rock stars capables de faire des choses que d’autres ne peuvent pas, mais cela ne signifie pas que vous ne voulez que des rock stars qui ne peuvent pas travailler avec les autres. Cela est particulièrement vrai si vous avez plus d’une étoile avec des traits similaires.
Nombre de PR/Revues: Maintenant, c’est un peu plus sur le côté gris. Bien sûr, si vous pouvez générer de nombreuses demandes d’extraction (PR), cela signifie généralement qu’il s’agit d’un travail associé à certaines spécifications de fonctionnalités (au moins on l’espère). Cela signifie qu’il va au moins dans la direction qui est perçue comme la valeur client. Mais à eux seuls, les PR sont à nouveau un indicateur de la quantité de travail qui nécessite une maintenance et une métrique sujette aux jeux. Bien sûr, vous pouvez faire beaucoup de petites relations publiques et « obstruer » le pipeline de révision et de fusion, ou faire beaucoup de révisions superficielles (LGTM), ou ajouter des commentaires déroutants et inutiles. Ainsi, ajouter de la valeur à certaines fonctionnalités client est une bonne chose, mais pour montrer l’activité, ce n’est pas le cas.
Corrections de bogues: Quelqu’un corrige un million de bogues ? Cela peut être formidable, mais deux questions viennent à l’esprit : pourquoi y a-t-il tant de bogues en premier lieu ? Et : est-ce que tous ces « bogues » doivent être corrigés ? La triste vérité est qu’aucun logiciel n’est parfait et qu’il y a toujours beaucoup plus à faire que ce qu’il reste de temps.
Nombre d’heures travaillées : Cela ne devrait pas non plus nécessiter beaucoup d’explications, mais les heures ne sont pas synonymes de temps bien dépensé. Bien sûr, si vous ne travaillez qu’1h par jour, vous devez être vraiment exceptionnel (et non hardcore) pour produire en permanence une valeur élevée. Mais si vous travaillez 14h, cela ne veut pas dire que vous êtes le plus productif. Surtout à court de vapeur/café. Toutes les bonnes choses nécessitent le bon effort sans aller à l’extrême. Parfois, cela peut être plus de codage, et parfois plus d’exploration/réflexion/discussion.
La valeur de l’ingénierie basée sur les données
Maintenant, nous sommes les derniers à ne pas promouvoir certaines métriques (ahem….), mais les métriques ne sont pas le but ; un aperçu de ce qui se passe dans l’organisation et amélioration continue les boucles sont.
Premièrement, les métriques sont presque toujours pauvres pour gérer les individus. Si vous avez besoin de mesures pour comprendre si un employé vous donne la valeur que vous attendez, alors vous êtes déjà en difficulté. Nous comprenons que les grandes organisations ont besoin d’un certain sens de l’objectivité, mais l’utilisation de l’un des éléments ci-dessus est probablement médiocre. De plus, les métriques en elles-mêmes ne résolvent pas les principaux problèmes. Cela nous amène au point suivant :
Les mesures sont de valeur pour mettre en évidence les tendances, anomalies, déséquilibres, et goulots d’étranglement. Cela est particulièrement vrai pour les processus, les flux de travail et les agrégats d’équipe/de groupe. Il serait impensable de gérer vos opérations sans surveiller certains chiffres, et il en va de même pour les ventes ou le marketing. Mais il est toujours destiné à améliorer et à rationaliser les processus et à créer moins de perturbations. En tant que telles, les métriques peuvent fournir d’excellents signaux pour gérer ingénierie organisationnelle productivité et supprimer la friction dans le système.
Pour équipes de développement, il est logique de mesurer certains chiffres et tendances. Par exemple : Où dans le processus de développement avons-nous être bloqué ou perdre du temps? Notre système de build nous retient-il ? Sommes-nous surchargés de critiques ? Avons-nous un problème d’assurance qualité ? Nos sprints sont-ils constamment redéfinis dans les airs ? Y a-t-il trop de changements de contexte ? Toutes ces choses sont essentielles, notamment pour que les bons managers assistent leurs équipes. Les responsables doivent supprimer les obstacles et les distractions, et non microgérer les lignes de code.
En ce qui concerne les tendances, il existe certains indicateurs indiquant si les équipes sont « dans le courant » ou non. Comment les fonctionnalités/RP suivent-elles au fil du temps ? Quelle quantité de travail accomplissons-nous habituellement (tickets de présentation, même des relations publiques en tant que proxy) ? Suivons-nous le processus (révise-t-il et approuve-t-il) ? Nos contrôles de sécurité fonctionnent-ils ? Comment fonctionne notre fiabilité de construction ? La question est alors : voyons-nous des pics, des anomalies ou des tendances malsaines ? Ceux-ci indiquent des problèmes avec Infrastructure, processus, et santé de l’équipe. Ceux-ci méritent d’être corrigés et, à leur tour, créent des équipes plus heureuses et plus productives.
Assurer un flux fluide dans la livraison des logiciels.
Réduire la friction, pas la micro-gestion
La clé de l’utilisation des métriques est d’obtenir des informations et une confiance dans les processus, les équipes et les flux de travail qui sont autrement difficiles à obtenir. L’objectif de productivité de l’ingénierie doit être de minimiser toute friction dans le pipeline de livraison de logiciels. Cela signifie que les étapes allant de la planification d’une fonctionnalité à sa livraison au client et le temps de réaction aux commentaires/demandes des clients doivent être rapides, fluides et fiables. Tout goulot d’étranglement de processus ou de principe l’emporte de manière significative sur les lacunes d’un seul contributeur et doit donc être l’objectif principal.
Les leaders de l’ingénierie moderne se concentrent sur les 4 mesures clés pour structurer leurs mesures d’ingénierie afin d’obtenir une meilleure visibilité sur leurs équipes et leurs processus de livraison. Ces métriques sont :
- Vitesse de livraison (à quelle vitesse)
- Débit de livraison (combien)
- Qualité de la livraison (quelle qu’elle soit)
- Obstacles à la livraison (comment risqué)
Récemment, une nouvelle vague de plateformes d’intelligence d’ingénierie aide les équipes et leurs responsables d’ingénierie à obtenir la visibilité et les informations nécessaires pour créer des organisations aussi saines et productives. En détournant l’attention des mesures de performance individuelles vers la réduction des frictions vers les objectifs de productivité, les entreprises ont réalisé des pourcentages à deux chiffres d’économies de coûts après une courte période. Nous approfondirons cela dans un prochain article.