(
c )
Presque depuis l'avènement de l'industrie de la technologie, il a recherché la «baleine blanche» - les mesures de travail des développeurs. Peut-être que le désir même de compter les programmeurs KPI est né d'une phrase courante dans les entreprises traditionnelles: "Vous ne pouvez pas planifier, si vous ne pouvez pas mesurer."
Après les centaines de KPI différents que les programmeurs essayaient de contourner, de nombreuses méthodes différentes pour analyser les données opérationnelles sont apparues - du suivi de la direction du regard sur le moniteur à Scrum et Kanban. Les mesures de la qualité du travail ont si bien fonctionné dans de nombreuses industries qu'il semblait logique de transférer cette expérience au développement de logiciels. Le résultat a été décourageant.
Mesurer et gérer la productivité des développeurs n'a pas conduit à une seule norme de qualité internationale. Les sociétés informatiques de haute technologie développent leurs propres métriques ... certaines d'entre elles sont presque impossibles à comparer avec les KPI traditionnels dans d'autres domaines d'activité.
Dans cet article, nous parlerons des métriques actuelles les plus intéressantes et des "métriques" en informatique.
Il est déjà difficile de trouver (au moins dans les sources ouvertes) des informations sur l'utilisation du nombre d'heures travaillées, du nombre de lignes dans le code source (SLOC), des points de fonction ou du nombre de bogues créés par chaque développeur comme métrique.
Dans le discours public, il a été possible de parvenir à un consensus sur le fait que travailler plus
ne signifie pas travailler mieux, qu'une solution avec 200 lignes de code peut être plus rapide ou plus productive qu'une solution avec 1 000 lignes, et la métrique Function Points créée en 1979 est désespérément dépassée.
Mais qu'est-il arrivé au désir de tout mesurer et calculer? Apparemment, il n'a pas disparu.
Netflix
(
c )
Netflix s'est concentré sur la suppression des obstacles qui séparent les utilisateurs du contenu. Chaque fois que quelque chose vous empêche de regarder le prochain épisode de votre série préférée, les développeurs résolvent le problème et mesurent le temps qu'il a fallu pour le résoudre.
La plateforme de streaming teste de nouvelles idées en termes réels et mesure les différences statistiquement significatives dans les interactions des utilisateurs avec le produit. De plus, les erreurs au stade des tests d'hypothèses sont tout à fait acceptables - "la seule vraie erreur inacceptable dans Netflix est l'incapacité à innover".
Le développement de produits chez Netflix commence par une hypothèse qui ressemble à ceci:
L'algorithme / la fonction / la conception (×) augmentent l'interaction des abonnés avec le service et, finalement, leur rétention.
L'hypothèse peut être d'augmenter la pertinence des résultats de recherche, d'utiliser un nouveau design pour les interfaces utilisateur ou une nouvelle fonctionnalité - par exemple, montrer aux participants ce que leurs amis des réseaux sociaux regardent Netflix. L'intuition et une idée de la façon de mieux fournir des services aux abonnés deviennent la base de l'approche de développement.
La deuxième étape de développement consiste à rédiger un test qui mesurera l'impact de l'hypothèse. Parfois, cela signifie que vous pouvez immédiatement créer un prototype qui reflète l'essence du concept, ce qui vous permettra de tester rapidement l'hypothèse et de vous efforcer de construire une meilleure solution.
La troisième étape est le test lui-même, auquel des centaines de milliers de spectateurs peuvent participer. Le prototype est déployé pour les participants à l'expérience pendant une période de temps donnée. Il peut avoir deux cohortes de test ou 20, chacune utilisant une approche différente ou mélangeant différents nouveaux éléments. Des dizaines de tests consommateurs différents peuvent être lancés à tout moment.
Même l'échec de l'hypothèse est considéré comme un résultat obtenu. Par conséquent, la probabilité que l'hypothèse suivante se révèle meilleure ne fait qu'augmenter. L'équipe de développement dispose d'une grande liberté pour appliquer des idées au produit sur une longue période.
Ibm
(
c )
La métrique la plus ancienne et la plus «évidente» pour le développement logiciel est de compter le nombre de lignes produites par un développeur ou une équipe et le temps passé dessus. Cette métrique a été utilisée pour la première fois par IBM. Dans le
film documentaire Triumphof the Nerds: The Rise of Accidental Empires, Steve Ballmer a noté que dans les années 1980, IBM semblait faire de la religion cette métrique.
En 2011, IBM a
introduit un outil pour analyser automatiquement le code source en termes de performances, de sécurité et de complexité technique. Les développeurs dont le code était le mieux noté ont reçu le score le plus élevé du système. Les faibles indicateurs de performance ont indiqué qu'il fallait prêter attention à la formation des employés (IBM a affirmé qu'un score final faible n'était pas utilisé comme sanction).
Néanmoins, des
publications ultérieures donnent l'impression d'un changement de paradigme - la méthodologie de construction d'hypothèses est déjà mentionnée au cœur du développement. Un développement hypothétique ne peut se passer d'une perte de temps et de ressources.
L'essentiel de cette mesure est la rétroaction des clients sur le produit. Nous devons nous concentrer sur ce qui est le plus important pour les clients, et abandonner les fonctions qui ne sont pas avantageuses, voire interférer avec les utilisateurs. Cette stratégie est illustrée dans le diagramme ci-dessus.
Spacex
(
c )
Il y a très peu d'informations sur le travail des développeurs de SpaceX, qui est associé au secret général des projets de cette société non publique. Mais selon
des informations indirectes, vous pouvez comprendre les contours approximatifs de l'image globale. Et cette image parle de l'importance des tests.
En science des fusées, les tests sont le fondement de la conception. Dans les logiciels de programmation de fusées,
les mêmes principes sont utilisés . Par exemple, si la fusée a atterri en toute sécurité, toutes les équipes responsables du développement ont terminé le KPI. Sans tests préliminaires, il n'est pas possible de mener à bien un tel projet.
Compte tenu des problèmes rencontrés par les équipes impliquées dans la préparation des équipements pour l'environnement spatial difficile, il n'est pas difficile de comprendre quelle responsabilité leur incombe.
SpaceX
essaie de paralléliser le code entre différents projets - avec ce paradigme de développement, la correction d'erreurs pour un projet (relativement parlant, fusées) s'étend automatiquement à d'autres projets.
La société a choisi C ++ comme langage de programmation principal. Tout d'abord, il vous permet d'embaucher de nombreux développeurs de haut niveau, car le langage est encore relativement populaire. Dans le même temps, le choix est souvent fait en faveur de développeurs de jeux habitués à écrire du code et à travailler dans des environnements à mémoire et puissance de calcul limitées.
Deuxièmement, ils bénéficient du vaste écosystème C ++. Il n'est pas nécessaire de créer un logiciel spécial lorsque vous pouvez utiliser des outils connus depuis longtemps, tels que gcc et gdb.
Et enfin, en cours de développement, une grande attention est accordée aux tests de métriques. Il est conseillé aux développeurs et aux ingénieurs de vérifier la sécurité et la tolérance aux pannes de tout ce à quoi vous pouvez penser.
Les données collectées pendant les tests sont stockées avec le code source qui a fonctionné pendant les tests. Si un dysfonctionnement se produit pendant les tests de fusée, SpaceX pourra recréer l'environnement de lancement exact, reproduire le problème et le résoudre.
L'intégration continue est utilisée pour tester automatiquement tout le code. Ils ont même des bancs d'essai avec tous les composants du moteur pour simuler pleinement le démarrage et détecter les problèmes potentiels.
Amazon
Amazon a l'une des stratégies les plus intéressantes décrites dans cette interview de 40 minutes avec le directeur d'AWS Developer Tools.
L'idée clé de la formation d'équipes de développement est la mise à l'échelle mitotique. Les équipes sont divisées en petits groupes, préservant pleinement la continuité et les fonctions des équipes «mères».
Jeff Bezos, PDG d'AWS Developer Tools,
estime qu'une équipe idéale ne devrait pas comprendre plus de personnes que deux pizzas peuvent remplir.
En petites équipes, la communication est beaucoup plus efficace, elles restent décentralisées, indépendantes, se développent plus rapidement et introduisent des innovations.
Amazon avait à l'origine une architecture monolithique et logicielle (Perl / Mason / C ++). Ensuite, l'architecture a été décomposée en services, et la structure d'organisation en équipes de pizzas. Le service cloud Amazon Elastic Compute Cloud (Amazon EC2) a donc été formé par un groupe composé de seulement deux «équipes de pizzas».
Amazon s'engage à automatiser entièrement tous les processus (génération, déploiement, transfert de validation, etc.). Au sein de chaque déploiement, plusieurs types de tests différents sont utilisés: intégration, navigateur, web et chargement. Ainsi, tout est contrôlé et mesuré.
La sécurité est surveillée tout au long du processus de lancement du produit, c'est pourquoi il est parfaitement normal qu'Amazon «pense comme un ingénieur en sécurité» dans n'importe quelle culture Amazon. Lors du lancement d'un nouveau projet, les développeurs travaillent principalement sur l'architecture et le modèle de menace.
Les validations sont intégrées à tous les pipelines via une combinaison de politiques d'approbation locales et mondiales. Le leader peut définir indépendamment la politique d'audit de son équipe (par exemple, avant le déploiement, chaque nouvelle validation doit être couverte par des tests unitaires de 70%).
Dans le même temps, il existe des règles générales d'Amazon qui couvrent chaque déploiement (par exemple, une interdiction de déploiement unique dans chaque région).
Ce sont les développeurs de l'équipe, et non l'architecte, qui sont responsables de l'architecture du projet. Et alors seulement, il est examiné par un architecte ou un ingénieur en chef. Même situation avec la sécurité et les tests: l'équipe gère l'ensemble du processus. Bien que cette approche ait un inconvénient, qui consiste en une longue période de formation.
Chaque année, les équipes préparent un plan opérationnel sur six pages (de tels «business plans» sont présentés à tous les niveaux d'Amazon). Le plan indique ce qui sera accompli l'année prochaine avec des ressources fixes et ce qui peut être réalisé avec des ressources supplémentaires. Les managers collectent des documents de six pages auprès de toutes les équipes qu'ils gèrent, créent leurs propres documents de six pages et les soumettent à leur direction - et ainsi de suite jusqu'à Jeff Bezos. En sens inverse, des ressources sont allouées aux équipes.
Qu'ont les startups
Grâce aux enquêtes
menées par Stackify (une plateforme cloud de surveillance et de dépannage des applications Web), il a été possible de connaître l'attitude vis-à-vis des métriques dans certaines start-up et entreprises bien connues de la «main de l'intermédiaire».
CircleCI est un service d'intégration continue populaire, y compris en Russie, avec des paramètres flexibles pour les applications Web et mobiles. Rob Zuber, CTO CircleCI, estime que la meilleure mesure pour mesurer la productivité et l'efficacité du développement logiciel est une mesure du temps nécessaire pour que le code passe de la validation au déploiement - Commit-to-Deploy Time (CDT).
L'objectif de la mesure de la CDT est de «repérer» les obstacles au déploiement. Idéalement, si vous utilisez une automatisation et / ou des tests de bonne qualité, vous pouvez passer au déploiement en quelques minutes (voire quelques secondes) pour un microservice. Si vous utilisez principalement le processus de contrôle qualité manuel, cela signifie probablement que le déploiement prendra plus de temps.
L'analyse CDT de CircleCI montre où trouver des opportunités d'amélioration. Les améliorations peuvent être plus techniques (par exemple, rendre les tests plus efficaces), plus orientées processus ou une combinaison des deux. Plus vos commits sont petits, plus ils peuvent être lancés rapidement, respectivement, plus vite vous pouvez corriger la situation en cas de problème.
Adeva est une société de recrutement et de formation d'équipes de développement toutes faites pour les startups. Pour offrir aux clients un meilleur service, elle recherche des mesures de performance des programmeurs depuis plusieurs années. La conclusion est simple: il n'y a pas de mesure formelle et objective de l'efficacité et de la productivité du développement logiciel.
Au lieu d'utiliser KPI, Adeva organise de courtes réunions avec les développeurs, au cours desquelles la direction écoute attentivement les histoires sur les réalisations et les échecs. Pour déterminer l'efficacité du département dans son ensemble, les développeurs sont invités à poser des questions sur l'utilité et la sensibilisation du reste de l'équipe. Lors de ces réunions, chacun peut exprimer des idées qui pourraient aider à la fois lui-même et les autres membres de l'équipe.
En plus des communications interpersonnelles, Adeva examine comment le code du développeur s'intègre à la base de code, vérifie ses performances, sa sécurité et détermine si le code aura un coût de service inférieur à long terme.
Scorchsoft, développeur anglais d'applications Web et mobiles, estime les délais de réalisation des projets. Étant donné que la plupart des clients de Scorchsoft s'attendent à recevoir un produit à un prix fixe, l'entreprise doit immédiatement identifier une spécification claire et sans ambiguïté. Les performances sont mesurées en termes de temps de développement sur la base des outils Toggl (time tracker) et Jira.
Un projet est considéré comme réussi si le client est satisfait et que l'équipe respecte le délai.
Conclusion
Parfois, avec l'évaluation des métriques, vous pouvez toujours arriver à un dénominateur commun - c'est un accent sur le confort de l'utilisateur. Au lieu d’essayer de mesurer directement la productivité du programmeur, l’accent est mis sur la mesure de tout ce qui empêche de progresser dans la création de valeur pour le client.
Lorsque le client final est le principal indicateur de réussite, il est beaucoup plus facile d'utiliser des statistiques issues du marketing: taux de conversion, comportement des utilisateurs ou avis sur les notes. Dans ce domaine, le succès dépend en grande partie de la direction, qui peut prendre la mauvaise décision. Par exemple, le développement d'une fonction qui n'est pas nécessaire pour le client a un impact beaucoup plus négatif sur l'entreprise qu'un développeur qui se démarque des «standards».