Les métriques logicielles dans les méthodologies agiles

Question

Les méthodologies agiles sont plutôt répandues de nos jours, mais je n'arrive pas à trouver beaucoup de documentation sur les métriques les plus utiles et pourquoi. J'ai trouvé beaucoup plus de choses disant que certaines métriques traditionnelles comme la couverture LOC et le code des tests ne sont pas appropriées, laissant deux questions principales:

1. Pourquoi ces deux métriques (et autres) sont-elles inappropriées?
2. Quelles métriques sont les meilleures pour Agile et pourquoi?

Même avec un processus Agile, ne voudriez-vous pas connaître la couverture de code que vous avez avec vos tests unitaires? Ou est-ce simplement que cette métrique (et d'autres) n'est pas comme utile comme d'autres métriques comme la complexité cyclomatique et la vélocité?

Answer 1

Agile est une chose orientée affaires, Agile est de maximiser la valeur client tout en minimisant les déchets pour fournir le retour sur investissement optimal.C'est ce qui devrait être mesuré. Et pour ce faire, j'utilise le système que Mary Poppendieck recommends. Ce système repose sur trois mesures globales qui doivent être prises comme un ensemble:

1. Cycle temps
   • Du concept de produit à la première version ou
   • De fonctionnalité demande à présenter le déploiement ou
   • De détection de bogue à la résolution
2. Réalisation de l'analyse de rentabilisation (sans cela, tout le reste n'est pas pertinent)
   • P & L ou
   • ROI ou
   • Objectif d'investissement
3. Satisfaction client
   • par exemple Net Promoter Score

Bien sûr, au niveau de l'équipe, vous pouvez suivre des choses comme la couverture des tests, la complexité cyclomatique, la conformité aux normes de codage, etc., mais de haute qualité ne sera pas une fin en soi, il est juste une moyenne. Ne me méprenez pas, je ne dis pas que la haute qualité n'a pas d'importance, la haute qualité est obligatoire pour atteindre un rythme soutenable (et nous incluons «aucune augmentation de la dette technique» dans notre définition de Done), mais l'objectif est apporter de la valeur au client de manière rapide et rentable.

Answer 2

1.1) LOC sont faciles à répondre

• Ils sont vraiment dépendants de la langue que vous utilisez! La même fonctionnalité peut avoir une grande différence lorsqu'elle est écrite sur JAVA ou sur Ruby, par exemple

• Un logiciel mal écrit peut avoir plus de lignes qu'une bonne!

1,2) Couverture de code

• à mon humble avis, vous devez utiliser métrique, bien que son pas parfait, il devrait vous donner une bonne compréhension de l'endroit où votre code a besoin d'autres tests.

• Juste un point que vous devriez prendre soin ici est que cela dépend aussi de la langue. Il pourrait y avoir des situations où vous avez une classe ou une méthode que vous n'avez vraiment pas besoin de tester! Par exemple une classe avec seulement des getters et setters.

2) A partir de (1) vous venez de mentionner les mesures de code, mais à en juger de votre question au sujet de la vitesse, vous êtes intéressé à des mesures sur l'ensemble du processus de création, donc j'énumérer quelques-unes:

• Velocity: La classique: si elle est bien utilisée, elle peut très bien améliorer une performance d'équipe agile, puisque vous saurez ce que votre équipe peut vraiment faire à un moment précis.

• Burn Up et incendier les cartes: ils peuvent vous donner une bonne idée sur la façon dont l'équipe effectue lors de l'interaction (sprint)

Il y a quelques articles sur InfoQ à ce sujet. Here et here.

Answer 3

Indépendamment de la méthodologie, il existe des métriques de base qui peuvent et doivent être utilisées.
Selon S. Kahn, les plus importants sont les suivants trois:

• taille du produit
nombre
• de défauts constatés dans la phase finale des tests
• et le nombre de défauts constatés sur le terrain.

Si ceux-ci sont tout ce que vous piste, il y a au moins cinq façons dont ils peuvent être utilisés:

• calculer le taux de défaut du produit (A)
• calculer le taux de défaut de test (B)
• déterminer un objectif souhaitable pour A et surveiller les performances
• déterminer un objectif souhaitable pour B et surveiller les performances
• évaluer la corrélation entre A et B
• si la corrélation se trouve, sous forme métrique d'efficacité de test (B/A * 100%)

Bien que pas nécessairement amusant à lire, Metrics and Models of Software Quality Engineering fournit une excellente en profondeur l'ingénierie logicielle et vue d'ensemble des paramètres.

Answer 4

Comme pour la question 1, je ne vois aucune raison pour que ces mesures soient mauvaises dans un processus Agile.

LOC vous fournit une mesure de taille relative. Bien qu'il ne soit pas toujours utile de comparer les nombres entre les projets, cela peut vous fournir un taux de croissance au sein du projet. Si vous pouvez l'obtenir, le nombre de lignes modifiées dans un sprint peut également être utile pour suivre un taux ou un refactoring.

La couverture de code (de lignes de code) vous donne une idée générale de la conformité ou non de votre équipe à une barre minimale de tests automatisés dans un projet.

Quant à la question 2, garder les éléments ci-dessus et voici quelques autres:

• LOC par rapport à nombre de tests. Si vous le pouvez, maintenez des ratios séparés pour les tests d'unité, d'intégration et de système.
• Nombre moyen de critères d'acceptation par rapport aux scénarios de test (ou tests) pour chaque histoire. Cela peut vous aider à déterminer si vos tests sont conformes à l'intention de l'histoire.
• Nombre de défauts découverts
• Quantité de travail découverte (souvent saisie par le logiciel de suivi Agile) qui ne faisait pas partie des estimations initiales. Cela vous aidera à juger si vous faites une planification «suffisante».
• Suivi des consistances, ou l'absence de celles-ci, de la vitesse sprint au sprint
• Bien que probablement pas populaire et probablement potentiellement dangereux, les estimations de suivi à travailler terminé pour chaque développeur. Alors que les équipes sont supposées s'auto-organiser et être dirigées, toutes les équipes ne sont pas capables de gérer les problèmes humains.

Answer 5

Juste pour ajouter

Pourquoi LOC et la couverture du code des tests ne sont pas idéales:

Agile met l'accent sur les résultats, pas de sortie (voir Manifeste Agile). Ces deux suivent simplement la sortie. En outre, ils ne mesurent pas correctement le refactoring, qui est un aspect essentiel des processus Agile.

Une autre mesure à prendre en compte serait l'exécution de fonctionnalités testées. Je ne peux pas décrire mieux que cela: http://xprogramming.com/articles/jatrtsmetric/

Answer 6

Je vais répondre à cette question très ancienne ...

LOC et la couverture de test sont, à mon avis, de bonnes mesures, mais ils ont un gros problème: si vous les poussez, vous pouvez les faire grandir rapidement, mais le résultat sera terryifing: des tonnes de code non-sens, ou dans la couverture de test, vous pouvez invoquer tout votre code dans un bloc try-catch et pas écrire un seul affirmer ... Ou pire encore, il suffit d'en écrire un pour des raisons de «conformité», mais sans aucun sens face au business ou au code ...

Donc, ce type de métrique est très bon s'il aide l'équipe à évaluer honnêtement leur résultat , mais sont un outil diabolique si elles font partie de certaines règles de «conformité», car les utiliser de cette façon cause plus de dégâts (code mort, mauvais tests!) que ce que vous vouliez atteindre. Donc, avec chaque métrique, pensez à comment vous tromperiez si vous deviez atteindre une certaine valeur, et pensez aux conséquences ... Ce n'est pas un problème de couverture LOC ou de test, de nombreuses autres mesures peuvent avoir résultat similaire, même complexité cyclomatique ...Si vous divisez votre code d'une mauvaise manière, vous pouvez réduire la complexité cyclomatique, mais cela ne signifie pas que vous obtenez le code plus lisible ou mieux!

Donc, ce genre de mesures sont tout à fait bon de voir ce qui se passe à l'intérieur d'une équipe, mais toute mesure que vous prenez doit être fondée sur des objectifs concrets, et non sur la métrique elle-même ... Par exemple:

couverture de test est faible: vous implémentez le codage dojos une fois par mois pour aider les gens en train d'écrire du code testable, vous trouverez ce code a la pire couverture de test et essayer de mettre en œuvre une meilleure/architecture plus testable qui aide/motive les développeurs à écrire test, etc.

Comme vous pouvez le voir, vous ne dire à l'équipe d'atteindre une certaine valeur de la couverture de test, il suffit d'utiliser la métrique pour voir où vous pouvez améliorer et rechercher des mesures qui profitent à votre Au bout d'un certain temps, vous vous attendez à ce que la couverture des tests augmente, mais vous ne forcez pas les gens à le faire! Vous évaluez les changements afin de voir si les mesures aident. Si après un certain temps, vous découvrez que la couverture de test n'a pas changé avec vos mesures, il est temps de chercher d'autres idées, et ainsi de suite ...