Un anneau pour les gouverner tous
Jrtolkien
"Vous ne pouvez contrôler que ce qui peut être mesuré"
P. DruckerEn ce qui concerne les mesures, des dizaines, voire des centaines, d'options différentes viennent à l'esprit.
Quelles mesures n'ont pas été inventées!
Mais le problème, c'est que lorsque vous regardez ces belles images, il est souvent totalement incompréhensible de ce qu'elles signifient.
Et en général, il est complètement difficile de savoir si ces mesures ont été choisies correctement ou s'il vaudrait la peine d'en examiner des complètement différentes?
Je veux une sorte de métrique, telle que j'ai regardé, et tout est immédiatement devenu clair.
Mais existe-t-il? Ou n'y a-t-il pas de magie?
Jetons un coup d'oeil et regardons un exemple spécifique ...
Souvent, tout ce que nous avons, c'est juste un certain ensemble de données d'entrée avec lesquelles on ne sait pas trop quoi faire.
Jira et ses tâches
Imaginez que votre entreprise utilise le traqueur de tâches Jira et tous les développeurs sont obligés de marquer les événements de mise en œuvre des tâches et leurs solutions.
Vous pouvez obtenir un déchargement pour les tâches Jira, mais que faire ensuite?
Une bonne idée dans cette situation est de penser exactement à ce que vous souhaitez gérer et au résultat que vous souhaitez obtenir.
Lisez, par exemple, l'article "
Aperçu des métriques: si je comprends bien, quelles sont les métriques et quel est leur charme principal "
Et si nous ajoutons ici aussi les livres "Lean Analytics", "Running Lean" et Tao Toyota, alors il devient clair que dans le cas de Jira, il est plus correct de gérer et de mesurer le délai de livraison des fonctionnalités développées au bal.
Donc, l'objectif est choisi - nous voulons mesurer le temps de livraison du logiciel, mais vous pouvez le faire de cent manières différentes. Par exemple, vous pouvez mesurer la longueur de chacune des étapes de développement, et également ajouter à cette mesure la perte de temps d'attente, de correction des défauts, de redécouverte, etc. Même vskidku peut s'appeler environ 50 à 70 mesures différentes liées au développement de logiciels.
Comment être? Y a-t-il cette seule métrique par laquelle un coup d'œil peut tout comprendre?
Si vous avez vu de vos propres yeux ces dizaines de mesures discutées ci-dessus, alors je connais votre réponse à l'avance - vous direz: Non! Et donc je veux ...
Je voudrais une telle métrique, un coup d'œil sur lequel on pourrait comprendre avec succès le développement et s'il est nécessaire de faire quelque chose de plus avec.
Étonnamment, il semble qu'il existe une métrique digne pouvant revendiquer en toute sécurité le titre de
One and Only .
Examinons-le de plus près.
Il existe un tel rapport dans Jira comme le "Diagramme de flux total" ...
"Stop-stop-stop ... Tout le monde le connaît, - vous dites, je ne trouverai rien de nouveau ici"
En général, oui, le rapport est bien connu de tous, mais examinons-le un peu plus en détail. Je vous assure que vous trouverez plusieurs surprises "agréables".
Voici à quoi cela ressemble habituellement:
Quelques rayures. Pourquoi le sont-ils? Pourquoi? Que signifient-ils? Et voici ce que ...
Barre rouge foncé - le nombre de tâches terminées selon la
comptabilité d'
exercice . Bleu est le nombre de tâches dans le travail et jaune est les nouvelles tâches enregistrées dans le backlog.
Le total cumulé est lorsque les tâches effectuées sont toujours ajoutées au nombre de tâches effectuées plus tôt.
Par exemple, imaginez que vous avez effectué 2 tâches avant-hier. Sur le graphique d'avant-hier, on notera: 2.
Hier, vous avez fait 3 autres tâches. Le prochain point du graphique sera 2 (hier) +3 (hier) = 5.
Et aujourd'hui, vous avez fait encore une tâche. Le point du jour sur le graphique sera égal à 2 (hier) +3 (hier) +1 (aujourd'hui) = 6
C'est-à-dire le programme augmentera tout le temps.
Et donc, si vous placez sur le graphique le nombre de tâches effectuées, le nombre de tâches dans le travail et les nouvelles tâches, vous pouvez extraire la métrique One One and Only.
Prenons un exemple réel (déchargement de Kibana et Elasticsearch):
Tu vois?
En fait, nous pouvons calculer la vitesse (ou la productivité) du développement. 200 nouvelles tâches terminées en 17 jours. De là, nous obtenons que la vitesse de développement actuelle est de 11,76 tâches / jour, soit
0,085 jours par
tâche .
Ils sont jugés par le calendrier, le nombre de tâches en cours, la zone bleue, ne change pas (la largeur de la bande est presque la même partout), c'est-à-dire on peut supposer que la vitesse de développement est constante, contrairement au nombre de nouvelles tâches.
À la vitesse de développement actuelle, 800 nouvelles tâches créées le 17/06/2018 ne seront terminées qu'après 68,03 jours.
Ok? À mon avis, pas vraiment.
Parler? Certainement!
Voici un autre exemple concret (rapport Jira). Voici le calendrier d'exécution des tickets par le support technique:
De la même manière, nous calculons la productivité du service de support - 2,7 tâches / jour.
Il y a quelque chose à rechercher
Il ne suffit pas de connaître la vitesse actuelle. Vous devez également comprendre la valeur cible, c'est-à-dire voir ce pour quoi lutter.
En comprenant la vitesse d'une personne, vous pouvez calculer le nombre de personnes dont le service d'assistance aura besoin pour réaliser le nombre cible de tâches ou augmenter la productivité actuelle.
Le service d'assistance emploie 15 personnes. Il s'avère qu'il y a 0,18 tâches / jour par personne.
Supposons que vous vouliez augmenter la vitesse d'exécution et rendre le service capable de travailler non pas 2,7 tâches par jour, mais 10 (valeur cible).
Une personne effectue 0,18 tâches par jour, ce qui signifie que 56 personnes effectueront 10 tâches.
Eh bien, ou en option, vous pouvez augmenter la vitesse d'une personne.
À une vitesse de 1 tâche par jour, pour 10 tâches, vous n'aurez plus besoin de 56 personnes, mais seulement 10.
Nous gérons les délais de livraison
Il s'avère que la métrique vous permet, en fait, d'affecter le délai de livraison.
En comparant les performances actuelles avec la valeur cible, vous pouvez comprendre combien de fois vous devez accélérer le processus.
En variant les paramètres qui composent la productivité (le nombre de personnes et la vitesse de leur travail), vous pouvez contrôler le délai total de livraison.
Où cela est-il applicable?
En fait, des analogues de la métrique peuvent être observés dans de nombreux domaines.
Prenez DevOps par exemple. DevOps est utilisé pour raccourcir l'intervalle de temps entre la création d'un kit de distribution et son déploiement sur un bal, c'est-à-dire ici, comme dans les exemples ci-dessus, vous devez contrôler le délai de livraison.
De toute évidence, la métrique est également idéale pour DevOps. Comptez simplement le nombre de distributions (assemblys) qui ont atteint le bal dans un certain temps et obtenez les performances actuelles de votre pipeline.
En principe, la même métrique peut être utilisée dans les domaines liés à l'argent.
Par exemple, pour une boutique en ligne, on pourrait également calculer le nombre de commandes pendant un certain temps. Toute la question est: les magasins en ont-ils vraiment besoin?
Conclusion
Comme vous pouvez le voir, la One Only Universal Metric a toujours droit à la vie, au moins dans le domaine du développement logiciel et dans les divisions de service (service de support technique).
Il est facile à calculer, contient du sens et peut être utilisé pour comparer avec la valeur cible.
Bien sûr, il ne peut pas être utilisé sans réfléchir. Avant de commencer l'implémentation, pensez-y, mais vous en avez vraiment besoin.
Que pensez-vous de la métrique universelle?
Quelle métrique utilisez-vous comme universelle?