Si vous deviez diriger le développement d'un logiciel, vous vous demandiez probablement - comment aider l'équipe à avancer plus vite? Et comment savez-vous à quelle vitesse vous vous déplacez?
Il semble logique d'utiliser des métriques pour répondre à de telles questions. Après tout, nous les utilisons depuis longtemps et avec succès pour les produits logiciels eux-mêmes. Il existe des mesures de performances, la charge du serveur de production, la disponibilité. Il existe également des mesures de produit basées sur le comportement des utilisateurs, comme la conversion et la rétention. L'avantage des métriques n'est pas seulement une meilleure compréhension de l'état actuel, mais, plus important encore, de fournir des commentaires. Vous faites un changement pour améliorer quelque chose, et vous pouvez voir par les métriques quelle amélioration (ou détérioration) vous obtenez. La sagesse populaire en matière de programmation dit: toute optimisation des performances du programme doit commencer par la mesure, ce qui a beaucoup de sens.
Puisque nous pouvons appliquer avec succès des mesures aux produits logiciels eux-mêmes, pourquoi ne pas les appliquer à la vitesse de développement de ces produits? Dans ce cas, nous pourrions essayer quelques améliorations dans les processus et voir visuellement si elles aident à aller plus vite. Et le problème de la détermination d'un salaire équitable pour les programmeurs serait également simplifié. Quelles métriques pourriez-vous utiliser?
Nous n'avons pas de bonnes métriques pour cela.
La vitesse de développement est la quantité de travail effectué par unité de temps. On peut mesurer le temps, tout est simple ici. Mais comment mesurer la quantité de travail effectué? Les tentatives en ce sens ont commencé il y a plusieurs décennies, avec la naissance de l'industrie de la programmation elle-même. Cependant, chaque fois que la métrique était utilisée comme objectif d'amélioration, quelque chose allait sûrement mal tourner. Par exemple:
- . , , , . , , , ;
- . , , ;
- . . , , . , , ;
- . , . , , , ;
- . , , , — , ;
- … .
Les développeurs sont intelligents et créatifs, et se spécialisent dans la résolution de problèmes complexes. Quelle que soit la mesure que vous leur donnez, ils trouveront le moyen le plus simple d'améliorer leurs performances, mais cela n'aura probablement rien à voir avec le volume et la qualité réels du travail effectué. Vont-ils utiliser ces méthodes de «triche»? Pas nécessairement, cela dépend de votre situation particulière, y compris de la force de l'incitation que vous créez. Mais ils se rendront certainement compte que l'évaluation de leur productivité n'a pas grand-chose à voir avec la valeur. Cela démotive non seulement, mais détourne également le travail réel.
Mais pourquoi?
Pourquoi les métriques fonctionnent-elles bien pour améliorer les propriétés des produits logiciels, mais pas pour mesurer le travail effectué par les programmeurs? Peut-être s'agit-il d'une sorte de complot de programmeurs? En fait, si nous regardons au-delà du développement logiciel, nous voyons d'autres exemples, dans certaines métriques qui fonctionnent bien et dans d'autres pas.
La fabrication ou les ventes de masse sont des exemples de domaines dans lesquels les mesures fonctionnent bien. Qu'il y ait production et vente de tasses. Vous pouvez mesurer le volume de production - le nombre de tasses par unité de temps, sa qualité (pourcentage de rebut), le coût d'une tasse. Dans les ventes - volume des ventes, marge. Ces mesures sont utilisées avec succès dans la gestion. Par exemple, le responsable de la production peut se voir attribuer la tâche de réduire le taux de rebut tout en maintenant le prix de revient, et le directeur des ventes - augmenter les ventes tout en maintenant le prix. L'amélioration de ces paramètres profitera à l'entreprise, de sorte qu'ils peuvent être considérés comme des indicateurs de la performance des personnes en charge.
L'évaluation de la performance scientifique est un exemple de cas où les mesures ne fonctionnent pas. Les scientifiques mènent des recherches, qui sont ensuite publiées sous forme d'articles scientifiques. Ce domaine a également ses propres métriques numériques - le nombre d'articles, le nombre de citations, la signification statistique des résultats, etc. Est-il possible de dire qu'un scientifique qui a publié 10 articles scientifiques a apporté au monde deux fois plus d'avantages qu'un scientifique qui a publié 5 articles? Cela est peu probable, car la valeur de leur travail peut être très différente et, en même temps, même à un niveau subjectif, il peut être difficile de comprendre quel travail était le plus précieux. Le problème de la «tricherie» des citations et des publications est largement connu dans la communauté scientifique, donc, malheureusement, ils ne sont pas considérés comme des indicateurs fiables de valeur. Il y a aussi le problème de la manipulation de la signification statistique .
Deux critères principaux
Quel que soit le contexte, les métriques qui fonctionnent bien ont deux choses en commun:
- Relation directe (non indirecte) avec la valeur;
- La précision, c'est-à-dire que la métrique est basée sur la mesure du nombre de certaines unités de valeur et ces unités sont égales les unes aux autres;
Regardons à nouveau les exemples que nous avons examinés ci-dessus: Les
mesures de la production de masse et des ventes répondent aux deux critères. Dans la production de tasses, la valeur est le produit - les tasses elles-mêmes. La connexion est directe, l'entreprise doit produire des mugs. Et puisque la production est en masse, les unités de valeur (cercles) sont égales les unes aux autres. Si nous parlons de ventes, alors les unités de valeur sont l'argent. Le but de l'entreprise est de réaliser un profit, donc la relation avec la valeur est, encore une fois, directe. Et comme chaque dollar gagné est égal à un autre, nous pouvons créer des mesures précises.
Dans l'évaluation des travaux scientifiques, ces critères ne peuvent pas être remplis. Nous ne pouvons pas trouver une unité de mesure qui déterminerait directement la valeur du travail scientifique, car tous les travaux scientifiques sont uniques. Il ne peut en être autrement, en partant simplement de l'essence même de la science - découvrir de nouvelles connaissances. Cela n'a aucun sens pour un scientifique d'écrire un autre travail scientifique qui en répéterait exactement un autre. Chaque travail scientifique doit apporter quelque chose de nouveau.
Comme nous ne pouvons pas trouver de paramètres qui mesurent directement la valeur du travail scientifique, il ne nous reste que des indicateurs indirects - par exemple, le nombre de publications et de citations. Le problème avec les métriques indirectes est qu'elles sont mal corrélées avec la valeur et ont tendance à être facilement trompées. Si vous commencez à utiliser une telle métrique comme objectif, vous créez vous-même une incitation à la clôturer artificiellement.
Retour à la mesure de la productivité du programmeur
Qu'avons-nous là? Lignes de code, nombre de commits, tâches, score de la tâche en heures ou points de stockage ... Si vous essayez de vérifier ces métriques par rapport à deux critères principaux, vous verrez qu'aucun d'entre eux ne les satisfait:
- Il n'y a pas de relation directe avec la valeur. Nous ne fournissons pas à nos clients des lignes de code, des heures de travail ou des points de stockage. Les utilisateurs ne se soucient pas du nombre de commits que nous avons effectués ou du nombre de tâches que nous avons clôturées;
- Ils ne sont pas exacts. Les engagements à commettre sont différents, une ligne de code n'est pas égale à une autre, les tâches sont également différentes, et les heures-homme et les points de stockage sont estimés subjectivement, ils seront donc également différents.
Il n’est donc pas surprenant qu’aucune de ces mesures ne fonctionne: elles sont toutes indirectes et imprécises.
Pourquoi n'y a-t-il pas de métriques qui seraient directement liées à la valeur du travail d'un programmeur? Pour les mêmes raisons que les scientifiques n'en ont pas. Les programmeurs, comme les scientifiques, créent constamment de nouvelles choses. Ils n'écrivent pas exactement le même code encore et encore - cela n'a pas de sens. Le code précédemment écrit peut être réutilisé de différentes manières, séparé en un module ou une bibliothèque séparé, ou simplement copié, au pire. Par conséquent, chaque journée de travail pour les programmeurs est unique. Même s'ils résolvent des problèmes similaires, ils les résolvent à chaque fois dans un contexte différent, dans de nouvelles conditions.
Le travail des programmeurs est une production à la pièce, pas une production de masse. Ils ne produisent pas les mêmes résultats reproductibles, il n'y a donc pas de référence pour la mesure. Les mesures qui fonctionnent si bien dans la production de masse ou les ventes ne fonctionnent pas ici.
N'y a-t-il pas quelque chose de plus moderne, basé sur la recherche?
Bien sûr, aujourd'hui, personne ne parle sérieusement de mesurer le travail d'un programmeur par des lignes de code. Il doit y avoir des mesures plus modernes basées sur la recherche, non?
Il y a quelques. Dans leur livre de 2018 «Accelerate», les auteurs citent les résultats d'une étude portant sur 2 000 organisations de différents secteurs. Les auteurs ont tenté de déterminer quelles métriques mesureraient les performances:
Source: Nicole Forsgren, Jez Humble et Gene Kim, «Measuring Performance», dans Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations
Voici quatre métriques. Voyons lesquels sont liés à la valeur et peuvent être mesurés avec précision:
- . , . , . . . . , , . , . , — ;
- Lead time — , . , , . , , , — ;
- (MTTR) — , , , . . -, . , MTTR . -, , . , — ;
- , . , . , , , . Linux, “ — ”. SaaS- . , — - , , - . , . , — . , — .
Conclusion: aucune de ces quatre mesures n'est précise et elles n'ont pas toujours une relation claire avec la valeur client. Y a-t-il une possibilité de «tricherie» dans ce cas? Sûr. Offrez des changements triviaux à faible risque aussi souvent que possible, et toutes les mesures, à l'exception du délai d'exécution, auront fière allure.
En ce qui concerne le délai de livraison - même si nous omettons le fait (important) qu'il est inexact, l'accent sur celui-ci conduira à la hiérarchisation des souhaits les plus simples du client et à pousser dans le coin le plus éloigné de tout ce que le client n'a clairement pas demandé - il s'agit généralement de refactorisations, de tests et toutes les améliorations auxquelles il n'avait pas pensé.
Par conséquent, je ne recommanderais pas d'utiliser ces mesures comme cibles.
Mais peut-être trouverons-nous de nouvelles métriques?
Bien sûr, vous pouvez dire: «Attendez, si aucune métrique appropriée n'a encore été trouvée, cela ne veut pas dire qu'il ne peut pas y en avoir du tout! Nous sommes des gens intelligents, nous allons nous forcer et trouver quelque chose ». Hélas, j'ai peur que ce ne soit pas le cas. Il y a une raison fondamentale pour laquelle il n'y a pas de bonnes mesures dans ce domaine. Comme nous l'avons dit plus haut, les bons répondraient à deux critères principaux:
- Relation directe (non indirecte) avec la valeur;
- La précision, c'est-à-dire que la métrique est basée sur la mesure du nombre de certaines unités de valeur, et ces unités sont égales les unes aux autres.
Nous ne pouvons pas mesurer avec précision la valeur directe, car tous les résultats du travail des programmeurs sont différents, ils ne produisent jamais rien exactement de la même. Il s'agit d'une production à la pièce pour des tâches uniques et non répétitives. Et comme il n'y a rien de répétitif, il n'y a pas non plus de base de comparaison et de mesure. Il ne nous reste plus que des procurations, mais comme elles sont mal liées à la valeur et sujettes à la triche, il est préjudiciable de se fier à elles.
Pouvez-vous améliorer les domaines pour lesquels il n'y a pas de bonnes mesures?
Les métriques sont excellentes car elles fournissent des commentaires. Vous apportez des modifications au processus et vous pouvez voir clairement si elles ont conduit à des améliorations ou non. S'il n'y a pas de métrique, la rétroaction devient moins prononcée et vous pouvez même avoir l'impression de bouger à l'aveuglette. Il y a un dicton célèbre attribué à Peter Drucker:
Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer.
Seulement ce n'est pas vrai. Selon l'Institut Drucker, Peter Drucker n'était pas vraiment sous l'illusion qu'une métrique pouvait être trouvée pour n'importe quelle activité, et n'a jamais dit de tels mots . Tout ce qui est précieux ne peut pas être mesuré, et tout ce qui peut être mesuré ne l'est pas.
La complexité des métriques ne signifie pas que rien ne peut être amélioré. Certaines entreprises publient des logiciels beaucoup plus rapidement que d'autres et sans sacrifier la qualité. Cela signifie qu'il existe des différences importantes et que, par conséquent, des améliorations devraient être possibles.
Sommaire
Il est possible et nécessaire d'améliorer votre produit logiciel à l'aide de métriques. Les indicateurs de performance, de charge, de disponibilité ou de produit comme la conversion et la fidélisation de la clientèle sont vos amis.
Cependant, vous ne devez pas essayer d'accélérer le processus de développement à l'aide de métriques, en raison du manque de métriques appropriées. De nombreux indicateurs dans ce domaine ont été inventés, mais, malheureusement, ils sont tous indirects ou imprécis, et le plus souvent les deux à la fois, donc lorsque vous essayez de les utiliser comme objectifs, vous ne faites que du mal.
Mais ne vous découragez pas - il y a de l'espoir! Le manque de bonnes métriques pour la vitesse de développement est triste, mais cela ne signifie pas que les améliorations de la vitesse sont impossibles. Comment est-ce possible. Oui, nous n'avons que des évaluations qualitatives subjectives pour la rétroaction. Cependant, il y en a suffisamment pour mettre en œuvre des améliorations et comprendre si elles ont un effet. Par exemple, l'une des choses qui peuvent être améliorées est la communication entre les développeurs et la direction . Le lien ci-dessus fournit des exemples de la façon d'améliorer la communication et pourquoi il vaut la peine de s'y concentrer.
C'est tout, écrivez dans les commentaires ce que vous en pensez. Bonne chance dans vos déploiements, même les vendredis.