Quel est l'état de l'art?

Les méthodologies agiles gagnent aujourd'hui en popularité et sont devenues un courant dominant du développement logiciel en raison de leur capacité à générer une grande satisfaction client. Le conseil en estimation et métrique reçoit de plus en plus de «missions agiles» et est censé fournir des conseils précieux pour les environnements de projet agiles. Mais les méthodologies Agile diffèrent des méthodologies Waterfall traditionnelles, en particulier dans la manière dont l'estimation et la collecte des métriques sont effectuées.. Une enquête à travers la littérature et Internet pour ces sujets donne un aperçu des différences et élargira nos connaissances et peut renforcer nos capacités. De nouvelles approches sur la façon dont les techniques et instruments existants peuvent être appliqués dans des environnements Agiles ont été trouvées. Le résultat de cette enquête comprend trois articles. Ce premier article présente l'état de l'art des métriques dans le développement logiciel agile.

Métriques logicielles en général

La métrique logicielle ou la mesure logicielle est un concept de l'industrie du logiciel. Il peut être décrit comme suit: appliquer des valeurs à des propriétés de produits ou de procédés selon des principes définis afin de réaliser des analyses statistiques ou comparatives au nom d'une finalité préalablement définie.

Software Metrics prend généralement en charge trois domaines d'intérêt.

• Planification, prévision
• Surveillance & contrôler
• Amélioration des performances, analyse comparative

De nombreuses métriques logicielles sont utilisées pour différentes situations. Putnam et Myers soulignent magnifiquement de quoi il s'agit avec le ‘5 métriques de base‘ pour le développement de logiciels: on développe un produit d'acceptable qualité avec une certaine effort dans une certaine temps. La relation entre le produit, qualité, effort et temps, est déterminé par la productivité, qui doit donc aussi être mesuré. Nous examinons de plus près ces métriques de base.

Produit(Taille)
Mesure les propriétés quantitatives, qui détermine la taille du produit. A faire avant ou après.
Exemples: LOC, Points de fonction, nombre de cas d'utilisation, nombre de fonctionnalités, Histoires d'utilisateurs.

Qualité
Le produit doit posséder une certaine qualité, généralement déterminé au moyen du « nombre de défauts par période de temps », le temps moyen avant défaut (MTTD) et la "densité de défauts" (nombre de défauts par KLOC).

Effort
Mesuré en mois-personnes uniquement dédiés à son projet.

Durée
C'est le délai d'exécution sans interruption entre la date de début et la date de fin du projet (par exemple. en mois).

Productivité
C'est une propriété du processus, c'est à dire. le processus de développement logiciel dans l'organisation. Il est souligné que ce n'est pas la productivité d'une ou plusieurs personnes qui s'occupent de la réalisation! La productivité détermine la relation entre le produit (Taille), effort et temps dans la soi-disant équation logicielle dans sa forme de base:

Productivity = product size (with a known Quality) / (effort * time)
(refer to the book for explanation)

Ces mesures de base prennent en charge les éléments mentionnés précédemment (principal) domaines d'intérêt comme suit.
Planification et prédiction: productivité et taille du produit (à la qualité souhaitée) déterminer indirectement le coût, délai et effort.
Monitorage et contrôle: toutes sortes de mesures sont utilisées comme partie du produit, pourcentage d'effort dépensé par produit livré par rapport à la taille totale du produit à un moment donné, nombre d'erreurs trouvées lors du développement par rapport au nombre d'erreurs attendu. Ce type de mesures caractérise la performance de l'équipe projet.
Amélioration, analyse comparative: en construisant un historique avec des informations clés de ses propres projets terminés, un point de référence peut être déterminé avec lequel les projets futurs peuvent être comparés. De plus, la propre performance peut être comparée à une performance d'autres entreprises (analyse comparative). Avec cette deuxième comparaison, il peut être déterminé si l'organisation fonctionne conformément au marché.

Métriques dans les projets Agiles

Les méthodes agiles ont le même point de départ que la méthode en cascade, à savoir: on développe un produit d'acceptable qualité avec une certaine effort dans une certaine temps.

L'approche et les processus peuvent différer, mais en principe c'est une autre route qui mène à la même destination. Il n'est pas surprenant que dans un environnement agile les métriques logicielles aient leur place. pourtant, il y a quelques différences notables avec l'approche en cascade. En premier lieu, il convient de préciser que les méthodes agiles ont leurs plus grands succès dans les projets de petite à moyenne taille pour des applications commerciales.

L'accent mis sur les métriques agiles est en ligne avec cette taille limitée et se concentre principalement sur l'équipe, l'itération en cours, la version actuelle. Moins sur le projet et peut-être pas du tout sur tout un programme de projets. En bref, l'accent est mis sur l'intérieur. Ceci est important à remarquer car sur ce point agile diffère clairement de l'approche cascade. Une deuxième différence frappante entre les métriques agiles et les métriques en cascade est la différence dans les unités de mesure utilisées. Métriques agiles pour le produit(Taille) et la productivité sont exprimées en unités subjectives (points d'histoire et points d'histoire par itération ou vélocité) qui s'appliquent uniquement à ce projet et à cette équipe. Cela rend la comparaison entre les équipes, projets et organisations impossibles. Les métriques en cascade sont spécialement exprimées en unités standardisées à des fins d'analyse comparative.

La matrice suivante montre les métriques de base de Putnam et Myers dans les deux environnements.

Métrique de base	Agile	Cascade
Produit(Taille)	caractéristiques, histoires	FP, Appel à propositions, UCP
Qualité	défauts/itération, défauts, MTTD	défauts/libération, défauts, MTTD
Effort	points d'histoire *)	mois-personnes
Temps	durée (mois)	durée (mois)
Productivité	rapidité (points d'histoire/itération) **)	heures/FP ****)

*)	Les story points sont subjectifs et ne s'appliquent qu'à ce projet et à cette équipe
**)	La vélocité est subjective et ne s'applique qu'à ce projet et à cette équipe, étalonnage impossible.
***)	FP et CFP sont objectifs et sont des normes internationales pour exprimer la taille fonctionnelle.
****)	Heures/FP est utilisé par plusieurs estimations & outils de mesure à des fins d'analyse comparative.

 

Un tour sur le Web pour l'utilisation des métriques dans la communauté Agile donne un tableau varié. Certains consultants proposent des métriques qui « restent proches de la manifeste '. Dans cette catégorie, les objectifs apparaissent comme «un aperçu de la confiance du sponsor», ‘ compréhension de la satisfaction client » et « motivation de l’équipe ». La perspective à partir de laquelle les « agilistes’ regarder les métriques, est bien illustré par la présentation sur Métriques agiles par Mike Griffith. Outre les « agilistes », il existe des consultants qui se concentrent sur les métriques traditionnelles, bien que ces métriques utilisent des concepts et des unités agiles comme des fonctionnalités, itérations, points d'histoire et vélocité.

Un document remarquable dans ce contexte, le récent thèse de Hanna Kulas. Ce document explique pourquoi Agile est si spécial et comment certaines métriques de produit peuvent être incorporées dans des projets agiles. De plus, ce qui sera mesuré et quels avantages peuvent être établis. L'application de ces métriques de produit peut conduire à une augmentation de la satisfaction client en raison d'une qualité de produit supérieure et de coûts de développement inférieurs, ce qui à son tour est le résultat d'une meilleure compréhension du processus de développement logiciel..

Remarquable et caractéristique pour agile est l'absence de métriques pour le benchmarking ou toute autre forme de comparaison externe. Les unités de mesure utilisées pour le produit (Taille) et la productivité sont subjectives et s'appliquent exclusivement au projet et à l'équipe en question. Du point de vue d'un responsable de l'acquisition ou d'un sponsor, il n'y a aucune possibilité de comparer les équipes de développement ou les entrepreneurs soumissionnaires sur la productivité. Ainsi, le processus de sélection d'un entrepreneur pour des raisons rationnelles (productivité) est pratiquement impossible.

Ci-après sont résumées les métriques « agiles » rencontrées sur le Web; leur but et comment ils sont mesurés. Notez que la majorité des métriques prennent en charge la « surveillance & contrôle'. De toute évidence, en ce qui concerne ce domaine d'intérêt, l'environnement agile ne diffère pas beaucoup de l'environnement traditionnel en cascade..

Métriques « agiles », résultats d'un sondage sur le Web

Les tableaux suivants présentent les métriques recommandées par divers « consultants agiles » dans de nombreux cas en fonction de leur propre pratique. Les mesures sont regroupées autour des domaines d'intérêt mentionnés précédemment dans ce document.

Métriques pour Planification, prévision

Métrique	But	Comment mesurer
nombre de fonctionnalités	1. Aperçu de la taille du produit (et l'intégralité de la sortie). 2. Lorsque l'état s'applique aux fonctionnalités: perspicacité en cours.	Le produit comprend des fonctionnalités qui à leur tour comprennent des histoires. Les fonctionnalités sont regroupées en "à faire", 'en cours', et "accepté".
nombre d'histoires planifiées par itération/version	1. Aperçu de la taille du produit (et l'intégralité de la sortie). 2. Lorsque le statut s'appliquait aux histoires: perspicacité en cours.	Le travail est décrit dans des histoires, qui sont quantifiés en story points. Les histoires sont regroupées en "à faire", 'en cours', et "accepté".
nombre d'histoires acceptées par itération/version	Pour suivre la progression de l'itération/version	Enregistrement formel des histoires acceptées.
Vélocité de l'équipe	Reportez-vous à Surveillance & Contrôler
LOC	Indique la quantité de travail achevé (le progrès), calcul d'autres mesures, c'est-à-dire. densité de défauts.	Selon les règles convenues, quels COL doivent compter.

Métriques pour Surveillance & Contrôler (progrès et performances)

Métrique	But	Comment mesurer
Burn-down d'itération	Performances par itération, " Sommes-nous sur la bonne voie?».	Effort restant (en heures) pour l'itération en cours (l'effort dépensé/prévu exprime la performance).
Vélocité de l'équipe par itération	Pour apprendre la vitesse historique de certaines équipes. Ne peut pas être utilisé pour comparer différentes équipes.	Nombre de points d'histoire réalisés par itération dans cette version. Velocity est spécifique à l'équipe et au projet.
Libération Burn-down	Pour suivre la progression d'une version d'itération en itération "sommes-nous sur la bonne voie pour l'ensemble de la version" ?.	Nombre de points d'histoire "à faire" après l'achèvement d'une itération dans la version (l'extrapolation avec une certaine vitesse montre la date de fin).
Libération Burn-up	Quelle quantité de « produit » peut être livrée dans le délai imparti.	Nombre de points d'histoire réalisés après l'achèvement d'une itération sur le nombre total de points d'histoire (de la sortie). Sur une ligne de temps, il montre la progression de «l'achèvement de la portée».
Nombre de cas de test par itération	Pour connaître la quantité de travail de test par itération. Pour suivre la progression des tests.	Nombre de cas de test par itération enregistrés comme « soutenus », « raté » et « à faire ».
Temps d'un cycle (Capacité de l'équipe)	Pour déterminer les goulots d'étranglement du processus; la discipline avec la capacité la plus faible est le goulot d'étranglement.	Nombre d'histoires pouvant être traitées par discipline au sein d'une itération (c'est à dire. analyse- UI-design-coding - Test de l'unité- test syst.).
Loi de Little - "les temps de cycle sont proportionnels à la longueur de la file d'attente".	Aperçu de la durée; nous pouvons prédire le temps d'achèvement en fonction de la longueur de la file d'attente.	Travail en cours (# histoires) divisé par la capacité de l'étape du procédé.

Métriques pour Amélioration (amélioration de la qualité des produits et des processus)

Métrique	But	Comment mesurer
Nombre cumulé de défauts	Pour suivre l'efficacité des tests.	Enregistrement de chaque défaut dans le système de gestion des défauts.
Nombre de séances d'essais	Pour suivre l'effort de test et le comparer au nombre cumulé de défauts.	Extraction des données du référentiel de défauts.
Densité des défauts	Pour déterminer la qualité du logiciel en termes d'"absence de défauts".	Le nombre cumulé de défauts divisé par 1000LOC (BLOC).
Répartition des défauts par origine	Décider où allouer les ressources d'assurance qualité.	En enregistrant l'origine des défauts dans le référentiel des défauts et en extrayant les données au moyen d'un outil automatisé.
Répartition des défauts par type	Pour savoir quels types de défauts sont les plus courants et aider à les éviter à l'avenir.	En enregistrant le type de défauts dans le référentiel de défauts et en extrayant les données au moyen d'un outil automatisé.
Temps de cycle de défaut	Aperçu dans le temps résoudre un défaut (vitesse de résolution des défauts). Plus la résolution est rapide, le moindre codage « sur le dessus » sera produit.	Date d'ouverture du défaut moins la date de résolution (généralement la date de clôture dans le référentiel des défauts).

Note: il y a aussi des « métriques’ a constaté que la mesure «un aperçu de la confiance du client ‘ et ‘ aperçu de la satisfaction des clients ». Cependant, pour ces métriques, la communauté agile ne parvient pas à rendre plausible pourquoi ces aspects s'appliquent spécifiquement à agile et ne sont donc pas inclus. Se référant à ma propre expérience de plus de 30 années, ces aspects sont mesurés dans tous les types d'environnements de projet. Plus ou moins la même chose s'applique à l'utilisation de la méthode de la valeur acquise.

conclusion

Ce tour du Web et des publications conduit aux conclusions suivantes.

1. Les métriques utilisées dans les méthodes Agiles et les unités utilisées (points d'histoire, rapidité) ne sont pas normalisés. Cela rend le benchmarking problématique, sinon impossible.
2. Lorsque les story points réalisés sont exprimés en LOC, une correspondance peut être établie avec des unités de taille fonctionnelle standardisées (FPn); même la productivité d'une organisation ou la productivité d'une équipe peut être déterminée.
3. Les méthodes agiles pourraient bénéficier de l'intégration de métriques de produit en conséquence d'une augmentation de la satisfaction client grâce à une meilleure qualité du produit et à des coûts de développement inférieurs grâce à une meilleure compréhension du processus de développement logiciel.
4. Au sein de la communauté Agile de nombreuses métriques sont développées, qui sont essentiellement les mêmes que les métriques de la méthode en cascade, bien qu'ils utilisent des unités et des concepts agiles.
5. Les méthodes agiles ne reconnaissent pas la « taille fonctionnelle ». La « taille » d'une version est exprimée en nombre de fonctionnalités ou d'histoires. La mesure des « points d'histoire » ne donne pas une (fonctionnel) Taille, mais plutôt une quantité d'efforts requis.

Liens vers certains sites Web

• Grand Visible – Métriques et diagnostics agiles
• Cadre Agile à l'échelle – Métrique
  Ce site Web de Dean Leffingwell prend une position particulière. Le Scaled Agile Framework est une philosophie et une méthodologie qui encadrent le développement agile dans une stratégie d'entreprise « lean ».. Certaines des mesures « Art » mentionnées dans le diagramme sont incluses dans les tableaux ci-dessus.
• Institut de génie logiciel – Sept catégories de métriques Agiles
• Principales réponses – Gestion de projet qualité

 

 

A propos de l'auteur

John Kammelar est consultant en métrique chez metrieken.nl, qui aide les organisations à mieux comprendre et contrôler les coûts et le temps de développement et de gestion de logiciels. Ils quantifient la fonctionnalité avec Function Point Analysis. Sur la base de cette analyse, une estimation réaliste peut être faite pour le temps et les coûts. Ce blog fait partie d'une série de trois articles résultant d'une vaste enquête. Cette première partie présente l'état de l'art des métriques dans le développement logiciel agile. Tous les articles sont téléchargeables sur metrieken.nl site Internet.

Un article de blog représente l'opinion personnelle de l'auteur
et ne coïncide pas nécessairement avec les politiques officielles de Nesma.