Mais est-ce que je ne fais plus de conneries? Comment et pourquoi mettre en œuvre des mesures de qualité

Bonjour, Habr! Une fois que nous avons utilisé la mesure «Ça semble être mieux» pour évaluer la qualité de nos versions. Mais ensuite, nous avons décidé de faire confiance à quelque chose de plus fiable. Dans cet article, je vais parler de la façon dont j'ai recherché un guide métrique, ne l'ai pas trouvé et créé le mien.



Vous arrive-t-il que vous fassiez un travail apparemment utile pour un projet, mais ne comprenez pas si cela apporte des avantages? Nous avons donc écrit une fois des autotests, mais nous ne pouvions pas objectivement dire si les versions du monolith et d'autres services dans lesquels le développement actif est meilleur sont devenues.

Recherche de métriques


J'ai regardé sur Internet et pour une raison quelconque, je n'ai pas trouvé d'articles ou de guides prêts à l'emploi sur la façon de choisir les bonnes mesures, comment les collecter et que faire ensuite avec elles. Mais pendant que je cherchais des informations, j'ai trouvé des vidéos et des articles utiles qui m'ont aidé à faire face à cette tâche difficile. Des liens vers ceux-ci apparaîtront dans l'article.

J'espère que cet article sera utile à ceux qui envisagent de mesurer quoi que ce soit sur leur projet, mais ne savent pas par où commencer. L'article contient une expérience personnelle, des informations sur des articles, des vidéos et des cours payants.

Une seconde avant de créer un système de mesure de la qualité
Avant de décider de créer un système de métriques de qualité, nous mesurions déjà de manière continue:

  • Le temps passé sur la libération du monolithe (depuis la création de la branche de libération jusqu'à la fusion de cette branche dans le maître).
  • Nombre de restaurations de versions monolithiques vers le maître en raison de bogues.
  • Temps passé à Stop the Line .
  • Le nombre de lancements de l'étage du pipeline monolithique dans TeamCity avec tous les autotests jusqu'à ce qu'il devienne vert.

Comme vous pouvez le voir, nous n'avons mesuré que ce qui est lié au monolithe. Pour les autres services, ils n'ont rien mesuré.

Nous mettons en place un système de mesure de la qualité en 11 étapes


Voici une liste de contrôle de 11 étapes qui vous aideront à tout mettre en œuvre et à ne rien manquer.

Étape 1. Définissez le but de vos mesures


Comprenez pourquoi vous voulez commencer à mesurer quelque chose. Mesurer comme ça, pour le plaisir de mesurer, n'a pas de sens.

Par exemple, nous voulions savoir comment nous nous dirigeons vers les objectifs de qualité que nous nous étions fixés plus tôt. Nous voulions également voir la dynamique des indicateurs après l'effort. En eux-mêmes, les chiffres de l'état actuel ne veulent rien dire. Ce ne sont que des chiffres. Mais, en observant les chiffres dans la dynamique, nous pouvons voir l'influence de nos actions.

Étape 2. Définir les cibles


Vous devez comprendre ce que vous recherchez. Réduisez le temps de test? Réduire le nombre de bogues critiques dans la prod? Augmentez la couverture des tests?

Dans mon cas, la définition d'indicateurs cibles n'a posé aucun problème, car notre entreprise a des objectifs de qualité. Ces objectifs sont devenus la base de futures mesures. Nos objectifs:

  • Une libération de monolithes ne prend pas plus de 4 heures.
  • 0 correctifs et annulations dans les applications monolithiques, de site et mobiles.

Étape 3. Décidez des mesures


Réfléchissez à la façon dont vous réalisez que vous vous dirigez vers vos objectifs.
À ce stade du travail, l'article « Les mesures d'AQ les plus importantes » m'a aidé.

Pour notre système, j'ai choisi de tels indicateurs
  • Il est temps de libérer . Cet indicateur mesure le temps (en heures ouvrables) entre la fusion de la branche de version précédente dans le maître et la fusion de la version actuelle dans le maître.

    Nous avons divisé ce temps en 4 étapes: préparation du stand, aménagement paysager de l'étage du pipeline, tests de régression manuelle, déploiement sur le prod.

    Nous avons divisé ce temps en étapes afin de voir en détail les conséquences de nos actions et de pouvoir déterminer avec précision le goulot d'étranglement de notre processus.

    Étapes de la mesure du temps de sortie
  • Le coefficient de "problèmes de libération" pour tous les services . Il s'agit du rapport entre les «versions problématiques» et le nombre total de versions, le tout multiplié par 100%. Une «version problématique» est une version dans laquelle il y avait un retour en arrière d'une version, d'un correctif ou d'un correctif de données.
    Ratio des versions problématiques par rapport aux versions totales
  • La densité de correctifs pour un service pour un monolithe est le rapport du nombre de correctifs pour un service au nombre total de correctifs.
  • Temps de régression manuelle pour l'application mobile . Il s'agit du temps entre le début de la régression manuelle et son achèvement.


Important! Ne prenez pas plusieurs mesures à la fois. Trois ou quatre suffisent pour commencer. Lorsque le processus s'améliore, vous pouvez en ajouter plus si nécessaire.

De nombreuses mesures sont difficiles à gérer. La probabilité augmente que le système ne décolle pas. Et si le processus ne décolle pas la première fois, la prochaine fois, il sera plus difficile de commencer, car vous et les employés aurez une expérience négative.

Étape 4. Décidez des unités


Différents indicateurs peuvent être lus dans différentes unités. Vous devez immédiatement choisir afin que toutes les mesures aient une unité de mesure, sinon vous risquez de rencontrer des malentendus et des interprétations erronées.

Nous avons des problèmes avec cet article. Nous avons compté le temps de sortie en heures, y compris les heures de nuit, mais à l'exclusion des week-ends. Dans le même temps, la valeur cible a été libérée en 4 heures. Très souvent, il y a eu des situations où nous avons créé la branche release-xxx à 16h00 aujourd'hui et avons terminé à 10h00 le lendemain. Dans notre métrique, il était considéré comme 18 heures, mais en fait, les actions actives n'ont été effectuées que 3 heures, sinon moins.

Si nous continuions à compter de cette manière, nous n'aurions jamais atteint l'indicateur «4 heures» dans notre métrique. Après avoir confronté le choix, porter l'objectif à 12 heures ou ne prendre en compte que les heures de travail, nous avons choisi la seconde.

Étape 5. Analyse des métriques sélectionnées pour l'adéquation


Dans la vidéo « Simple Practice Testing Metrics », le conférencier a suggéré une façon intéressante d'analyser les mesures d'adéquation. Vous devez répondre à 9 questions pour chaque mesure et prendre une décision.

Délai de publication de l'analyse métrique sur l'adéquation
  • Le but de la mesure . Cet indicateur doit être lié à l'objectif commercial. La métrique "Time to Release" est liée à l'objectif commercial - libération en 4 heures.
  • À qui cette mesure est destinée . Qui examinera cette métrique? Oouner produit, développeurs, managers, testeurs, scrum masters?

    L'once du produit (car il est important pour lui de comprendre combien de versions par sprint nous parvenons à déployer), les développeurs (parce qu'ils veulent comprendre quand leur code sera sur la prod) et les testeurs (puisque le temps est écoulé) test affecte directement cette métrique).
  • À quelle question répond la mesure de l'utilisateur . Formulez les questions auxquelles vous obtenez une réponse avec cette métrique. La mesure «Release Time» répond à la question «À quelle fréquence publions-nous?»
  • Énoncez l'idée de la métrique et sa description. Décrivez brièvement mais clairement la métrique. J'ai décrit la mesure «Time to Release» comme suit: «Nous voulons être publiés le plus souvent possible, cette mesure montrera à quelle vitesse nous sortons. Le temps de sortie est le temps en heures ouvrables de 9h00 à 18h00, hors week-end et jours fériés. Le début d'une version est considéré comme la création d'une branche de version ou la fusion de la version précédente dans le maître, la fin de la version est l'injection de la branche de version dans le maître. Divisez le temps en différentes étapes, par exemple: préparation à la publication, réussite des autotests, tests manuels, calcul pour la production »
  • Conditions nécessaires . Énumérez ici les conditions ou restrictions de collecte des métriques. De qui, quand, d'où proviendront les données des mesures. Dans mon cas, je sais où regarder les sorties de toutes les pièces. Monolith - fusionne les branches release-xxx dans le maître. Site Web - pommes de terre dans Kaiten.io sur le tableau de sortie. Applications - je ne sais pas encore, mais je vais découvrir "
  • Mesures initiales. Mais je n'ai pas compris ce point et je ne sais pas comment le décrire. Qui a compris ou sait ce qui peut être discuté ici, écrivez dans les commentaires.
  • Indiquez la formule de calcul de la métrique. Pour la métrique «Time to Release»: combien de temps en heures de travail s'est écoulé depuis la fusion de la version précédente vers le maître jusqu'à la fusion de la version actuelle vers le maître (hors week-end et jours fériés). En conséquence, nous obtenons les heures de travail que nous avons consacrées à la sortie.
  • Critères de décision. Déterminez ce que vous ferez lorsque vous verrez des modifications à cette mesure. Décrivez votre réaction. Ma réponse sur la métrique est "Time to Release": "Vous devez répondre à la métrique en recherchant les goulots d'étranglement et en éliminant ces goulots d'étranglement"
  • Fréquence. À quelle fréquence allons-nous collecter la métrique. Nous allions vérifier notre métrique chaque semaine, mais en fait nous le faisons plus souvent.


Après une analyse aussi simple, il devient immédiatement clair si vous avez besoin de cette métrique ou non. Il y a une compréhension plus profonde de la métrique elle-même et de sa valeur pour l'entreprise et pour vous.

Étape 6. Aligner les métriques avec les parties prenantes


Affichez les mesures sélectionnées à celles qu'elles affecteront. Discutez des limites que vous avez découvertes au cours de la phase d'analyse, ainsi que des moyens de les éliminer, ou du moins de les réduire. Il est particulièrement important d'obtenir le consentement et l'approbation de ceux qui collecteront et rempliront ces mesures.

J'ai discuté de mes mesures en 3 étapes: avec des testeurs, des développeurs et des superviseurs de produit. Ce n'est qu'après que tout le monde a convenu explicitement que ces mesures montrent la qualité du système que j'ai pu passer à l'étape suivante.

Étape 7. Visualisez les résultats


Les gens ne liront pas les tableaux et ne regarderont pas la dynamique par eux-mêmes. Par conséquent, vous devez faire attention à la visibilité.

J'ai créé un tableau dans Google Sheets, rédigé des formules et j'ai eu le plaisir de présenter le tableau à mes collègues. Notre CTO a suggéré de visualiser ces mesures. Plus précisément, pour s'assurer que l'état actuel du système est clair en 15 secondes: est-il devenu meilleur par rapport au sprint précédent ou la qualité a-t-elle diminué?

Ensemble, nous avons visualisé les indicateurs. Ensuite, j'ai demandé aux gens de dire ce qu'ils ont vu sur ce tableau. À en juger par les réponses, nous avons atteint l'objectif.



Voici à quoi ressemble la visualisation de la métrique de qualité de publication. Tout est clair, vous pouvez immédiatement voir comment c'est maintenant et comment c'était, que le nombre de problèmes dépasse le nombre de versions, c'est devenu meilleur ou pire par rapport aux versions précédentes. Dans un horaire idéal, la ligne bleue devrait tendre à l'infini et la ligne rouge devrait aller à 0.


Visualisation de la relation entre les «versions problématiques» et le nombre total de versions

Étape 8. Observez la fréquence de collecte des métriques


Il est important d'établir le processus de collecte des métriques, de travailler sur la fréquence. S'il n'y a pas de processus, votre tableau de bord perdra sa pertinence et mourra. Il est important qu'il y ait des parties prenantes qui le feront. Mais si cela vous inquiète, la personne concernée est déjà là.

Étape 9. Informez encore et encore les gens sur les résultats.


Quelle que soit la beauté de votre tableau de bord, les gens n'iront pas là-bas et regarderont les mesures. Une fois que tout le monde verra, car c'est quelque chose de nouveau, mais pas sur une base continue.

Nous résolvons ce problème de trois manières.
  • Une histoire de métriques sur la partie commune de notre revue de sprint.
  • Conclusion de graphiques sur le moniteur dans le couloir, que tout le monde voit tous les jours, afin que les chiffres et les graphiques soient toujours sous vos yeux.
  • Publier le résumé du tableau de bord Slash. L'essentiel est de montrer la dynamique lors de la publication de tels rapports: elle est devenue meilleure ou pire par rapport au sprint précédent. Et si vous publiez ceci avant l'équipe rétro, cela peut donner aux gars des sujets de discussion.


Étape 10. Analyser et prendre des décisions


Vous devez regarder les métriques, prendre des décisions en fonction de celles-ci. Vous pouvez utiliser des métriques comme argument supplémentaire en faveur de la rédaction de tests supplémentaires ou de la concentration sur la dette technique plutôt que sur les fonctionnalités métier, etc.

Étape 11. Automatiser


Automatisez la collecte des métriques autant que possible. Si vous utilisez les systèmes de contrôle de version TaskMS et TestMS populaires, les systèmes CI / CD, ils ont probablement tous une API ouverte avec laquelle vous pouvez facilement extraire ces informations. Si vous ne pouvez pas le faire vous-même, demandez de l'aide aux développeurs. Vous devrez peut-être modifier certains processus pour cela. C'est normal. Et c'est un prix bas pour les avantages que vous obtenez en commençant à collecter des mesures.

Par exemple, nous avons un bot qui aide les releasemen roll release et réduit leur routine.

Résumé et conclusions


Prendre des décisions qui affectent la qualité du produit en fonction de vos sentiments intérieurs est une mauvaise idée. Les sentiments peuvent tromper et vous pousser à la mauvaise décision. Il vous suffit donc d'obtenir les métriques et le système d'évaluation de la qualité.

Mais rappelez-vous qu'un établissement métrique est comme un établissement pour animaux de compagnie. En plus du bénéfice de la communication avec un nouvel ami, vous obtenez une certaine responsabilité et des obligations envers lui. Par conséquent, commencez les mesures consciemment, en comprenant leur besoin et leur volonté de surmonter les difficultés qui vous attendent sur le chemin.

Source: https://habr.com/ru/post/fr468007/


All Articles