KPI pour les équipes de développement de logiciels – Arragonán – Dani Latorre

Dans le cadre de mon travail au cours de la dernière année, j’ai essayé de pousser la culture de l’amélioration continue des différentes équipes avec lesquelles j’ai travaillé. . À la fois sur des questions d’outils techniques et de compétences, telles que celles de la communication et de la coordination, avec certaines restrictions et dépendances qui tombent de notre marge d’influence.

Nous partons de l’hypothèse que ce que l’équipe pratique Sont une meilleure capacité de livraison aura. Cela se traduit par une plus grande adaptabilité aux changements, un entretien meilleur du logiciel avec le passage du temps et éventuellement une plus grande motivation de l’équipe avec son travail.

En plus des sensations subjectives typiques d’effet d’amélioration, Nous avons dû penser aux indicateurs qui nous permettent de l’obtenir vraiment. À un moment donné, il commencerait également à vouloir avoir une visibilité de l’extérieur des équipes, alors j’ai dû me retourner et commander des idées.

Je préparais une présentation pour expliquer en interne comment nous travaillions, où je pensais que nous devrions passer à travers une amélioration continue, les différents KPI que nous pouvions observer et les besoins qui seraient couverts d’une bonne capacité de livraison.

diapositive d'une présentation avec le vision de quoi, comme une équipe devrait être couverte: adaptabilité en ce qui concerne les affaires, en évitant bientôt, éviter la reprise, une bonne ux et éviter les insectes autant que possible

« Dis-moi comment je me procure et Je vais vous dire comment je me comporterai « 

Je ne connais pas l’origine, mais avec ces choses, je me souviens toujours de ce dicton. Vous devez marcher avec un œil avec quels indicateurs (pas objectifs) nous mesurerons . De plus, nous devrons utiliser plusieurs pour compenser la promotion de comportements étranges qui fausses ces métriques.

avec utilisation Normal des outils, n’acceptant que certaines conventions, l’exploitation ultérieure des données peut être facilitée pour extraire des métriques. Les sources de données pour les indicateurs sont les suivantes:

  • le code
  • le référentiel d’automatisation et le serveur
  • Les outils de gestion
  • le Produit lui-même

indicateurs de code

Les outils d’analyse de code statique nous donnent des chiffres sur la dette technique qui existe. Nous ne devrions pas perdre de vue ces indicateurs et consacrer du temps à analyser et à nettoyer spécifique de temps en temps. Parfois, ils sont résolus avec des solutions simples et d’autres cachent des problèmes de conception qui ne sont pas si évidents.

La couverture de test est l’un des indicateurs les plus courants, le plus intéressant dans ce cas est de voir ce qui n’est pas couvert. Et comme il est généralement discuté, nous devons marcher avec précaution, car c’est un indicateur facile de falsifier s’il est recherché comme une cible.

à un moment donné, en outre, des tests de mutation peuvent être utilisés (chèque qu’un test est brisé lors de la modification du code de production) pour avoir un indicateur de la qualité des tests de l’unité.

indicateurs de référentiel et serveur d’automatisation

Il existe des indicateurs assez intéressants pouvant être supprimés Des référentiels et des serveurs d’automatisation, bien que surtout dépendent des conventions d’utilisation.

Cependant, un indicateur toujours valide et que je pense que cela devrait être observé est la fréquence d’intégration.

L’intégration continue est une pratique (qui aucun outil) aussi populaire que mal interprétée, depuis que le travail que vous avez fait ou fait une personne avec la principale branche de développement et une construction est terminée, nous ne le faisons pas.

Jusqu’à ce que vous ayez fini correctement La construction d’un artefact logiciel, nous ne savons pas si tout est correct. Plus de fréquence, retour d’information plus tôt et moins incertitude.

En cas d’utilisation de branches, il est également intéressant de voir la durée de la vie des branches. Plus de temps, un risque accru de conflits ou d’autres problèmes lors de l’intégration.

et si des demandes de traction / fusion sont utilisées, il existe également une poignée d’indicateurs qui peuvent à tout moment tirer des odeurs liées à la capacité de livraison : Nombre de commentaires, temps restant, nombre de rejets …

indicateurs d’outils de gestion

Outils de gestion, en plus de servir de radiateur d’informations pour connaître la situation de la construction actuelle du produit et aidez à coordonner les travaux, ils constituent une bonne source d’informations sur les indicateurs du processus de travail.

Pour observer la capacité de l’ensemble de l’équipe dans un ensemble de tranches verticales est très utile, connaît le temps de cycle . À un moment de cycle plus court, plus notre capacité de livraison est grande. C’est le temps qu’il faut depuis qu’il commence à travailler sur quelque chose qui contribue à une valeur (par exemple, une histoire d’utilisateur) jusqu’à ce que cela se produise.

Il est habituel qu’à un moment donné dans les outils de gestion, vous pouvez observer les différents déploiements qui ont été apportés, où nous pouvons obtenir la fréquence du déploiement. Évidemment, plus fréquemment, mieux.

Bien que notre temps de cycle était court et la fréquence du déploiement élevé, il serait possible que notre produit soit fragile en raison de bugs. C’est pourquoi l’indicateur des bugs détectés et résolus par version / déploiement est une autre métrique à être prise en compte toujours.

Selon le moment et le scénario dans lequel un produit est trouvé, je pense aussi que l’indicateur de Le délai imparti, le temps passé depuis quelque chose de nouveau est demandé jusqu’à ce qu’il soit déployé en production. Ce serait une conséquence des 3 indicateurs précédents et de la taille de la pile de produits.

Comme je suppose qu’il y a quelqu’un qui peut manquer les indicateurs sur les estimations, tapez l’itère des points de l’histoire. À mon avis, ils ont une composante très subjective et variable à utiliser comme indicateur de changement de la capacité de livraison d’un ordinateur.

indicateurs du produit lui-même

en plus de Un autre type d’instrumentation principalement plus méticuleuse que les membres de l’équipe de gestion des produits ou de la conception ont besoin, l’équipe de développement devrait pouvoir respecter le nombre et le pourcentage d’utilisation de la fonctionnalité, ce qui définit à la fin le succès ou non du travail de tous.

La chose la plus intéressante à propos de cet indicateur est que combinée avec d’autres métriques peut aider à prendre des décisions concernant l’évolution du produit. Comme par exemple, ce scénario:

  1. a détecté des problèmes de performance très graves dans une partie du produit.
  2. Nous notons que le pourcentage d’utilisation de la fonctionnalité affectée par ces problèmes est Résiduel.
  3. Nous avons décidé de ne pas le résoudre pour le moment, mais nous le reflètent dans la pile de produits comme une petite priorité.
  4. Nous configurons une alerte pour détecter une augmentation de la pourcentage d’utilisation de cette fonctionnalité.

Un autre indicateur important est le taux de crash du produit, combien de fois une défaillance ou une erreur est détectée par une quantité d’utilisation, ce qui nous permet de savoir à quel point une stable a Le produit est. Et mélangé avec la fonctionnalité Utilisez un indicateur de numéros, il nous permet de détecter les points problématiques.

Selon le contexte du produit et de l’entreprise, nous pouvons éventuellement supprimer d’autres indicateurs pertinents d’opérations et de soutien qui sont Une conséquence de l’utilisation du produit.

mesure sans perdre la mise au point

Ce sont de nombreux KPI différents. Il est intéressant de les observer car ils peuvent être utilisés pour détecter les odeurs sur les problèmes et les opportunités d’amélioration, mais ils sont trop nombreux pour essayer d’améliorer tout à la fois.

Pour éviter de diluer et de ne pas se retrouver du tout , nous devrions choisir et se concentrer dans un couple de ces indicateurs à chaque fois, en fonction de la situation de chaque équipe.

et même s’il est tentant de le faire, il éviterait de bonheur avec ces indicateurs pour marquer les objectifs , ainsi que pour évaluer différents équipements.

n’oublions pas que le but de mesurer ces indicateurs est d’observer l’évolution au moment d’une équipe travaillant sur un produit et un contexte particulier.

Leave a Comment

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *