Mesure de la productivité des logiciels

Qu'est-ce que la productivité logicielle

En gros, c'est simple, c'est une production au fil du temps.

Productivité = Résultats/Temps

Toutefois, la difficulté consiste à trouver une mesure appropriée des résultats. Les résultats dans le contexte d’un logiciel sont difficiles à standardiser. Dans la plupart des cas, nous pouvons considérer le résultat d’un projet logiciel comme une valeur commerciale et/ou des fonctionnalités reconnaissables par l’utilisateur.

Pourquoi de nombreuses entreprises souhaitent mesurer la productivité des logiciels

Les gestionnaires ont le devoir de rechercher une quantification et une certaine certitude quant au coût, au calendrier et à la portée d'une entreprise logicielle particulière. Ils rechercheront également des moyens et des mesures pour :

• Comparaison avec d'autres organisations
• Suivre les progrès au fil du temps
• Évaluer la productivité de l’équipe et de l’individu
• Utiliser la productivité pour déterminer les décisions de délocalisation
• Utiliser la productivité pour éclairer les décisions de priorisation

Mesures générales de productivité

Nous nous concentrons principalement sur la productivité des développeurs, car ceux-ci ont tendance à faire le plus et à coûter le plus cher sur un projet logiciel. Mais il est également utile de comprendre la productivité des autres personnes impliquées, notamment les testeurs, les analystes, les chefs de projet, les concepteurs, les architectes et autres personnes impliquées dans les projets logiciels.

Critères d'une bonne mesure de productivité logicielle

Il n’existe pas de mesure parfaite du « résultat » du travail logiciel, nous devons donc trouver des indicateurs substituts alternatifs qui peuvent nous aider à nous rapprocher de la quantification du « résultat ».

Idéalement, pour les logiciels, nous voulons une « métrique de sortie » qui permet d'obtenir les résultats suivants :

• est fortement corrélé à la valeur commerciale
• est impossible à jouer et cohérent, objectif, reproductible et vérifiable de manière indépendante
• est indépendant quel que soit le langage de programmation
• est valable pour comparer un projet à un autre.
• peut expliquer que le travail plus complexe soit confié à des membres de l'équipe plus compétents
• qui peuvent être collectés facilement et à moindre coût.

Notez que les mesures idéales pour la productivité individuelle diffèrent légèrement de celles idéales pour déterminer la productivité de l’équipe.

Classement des métriques logicielles

Le tableau suivant a été réalisé par Steve McConnell et est discuté dans cette présentation pour classer les mesures de productivité logicielle appropriées. Les points de fonction COSMIC étaient moins connus et le dimensionnement automatisé n'était pas disponible lorsque Steve a créé ce tableau pour la première fois. J'ai ajouté la colonne pour les points de fonction COSMIC. Cette colonne supplémentaire est subjective et, à notre avis, ne fait pas partie de l'évaluation initiale de Steve.

Dans l'évaluation originale de Steve, la conclusion était une évolution serrée entre plusieurs approches, avec « Cas de test réussis » comme la plus élevée. Maintenant, avec l'avènement a) d'une approche plus simple du dimensionnement fonctionnel (points de fonction COSMIC par rapport aux points de fonction IFPUG) et b) du dimensionnement automatisé, il semble y avoir une mesure claire pour évaluer la productivité – les points de fonction COSMIC.

Mesures de productivité trompeuses

Il n’existe pas de mesure unique parfaite pour le travail logiciel, mais certaines sont utiles et valables. Il y en a également qui sont susceptibles d'induire en erreur, de donner lieu à des abus ou d'inciter à des comportements inutiles.

Lignes de code

La mesure de productivité ici est le nombre de lignes de code écrites au fil du temps. Étant donné que le nombre de lignes de code pour une fonctionnalité donnée peut varier de 10x selon les développeurs, au mieux, le LOC délivré au fil du temps ne peut être qu'une approximation. C’est facile à mesurer mais ce n’est pas nécessairement une bonne mesure. Différents langages de programmation nécessitent différents nombres de lignes de code qui varient considérablement d'un langage de programmation à l'autre. Utiliser des lignes de code peut également inciter les développeurs à écrire des lignes supplémentaires superflues, juste pour être classés comme « productifs ». Cela a l’effet inverse de celui escompté, car cela peut générer des coûts de maintenance supplémentaires.

Points d'histoire

Les Story Points sont un proxy subjectif et non standard pour l'estimation de l'effort. Certains diront qu’ils « mesurent » la complexité. Au mieux, ils peuvent donner une indication de la difficulté d’une tâche particulière. Il s’agit essentiellement d’une indication des « journées idéales pour le personnel ». Ceux-ci ne conviennent pas au travail sous contrat et ne peuvent pas être utilisés pour comparer une équipe à une autre ni un projet à un autre. Il n’y a pas d’« apprentissage » ou d’« amélioration continue » réalisable en adoptant des story points.

L'histoire compte

La taille de la user story peut varier considérablement, que vous estimez la taille en points de fonction COSMIC ou en jours de personnel idéaux. Une histoire peut être une tâche technique de 10 minutes, tandis qu'une autre histoire peut nécessiter un mois entier de travail d'équipe. D'après notre expérience, la taille des histoires varie de 0 CFP à 120 CFP.

Autres mesures de productivité de l'équipe

L'évaluation de la productivité basée sur la carte de score peut être utile dans certaines circonstances, en particulier si les valeurs des cartes sont à la fois normalisées entre les équipes et choisies pour refléter tous les critères que l'organisation souhaite utiliser.

Il est important de choisir des critères axés sur les valeurs de l'organisation (pour la qualité et le résultat). Il est également important d’aligner les équipes sur les véritables objectifs de l’entreprise.

Recommandation

Points de fonction COSMIQUE

Notre mesure de sortie recommandée est constituée de points de fonction COSMIC (CFP). Nos raisons pour cette recommandation sont :

1. CFP est ancré dans les principes fondamentaux du comportement logiciel (entrées, sorties, lectures et écritures)
2. CFP est axé sur l'utilisateur : il s'aligne sur ce qui est nécessaire pour apporter de la valeur à l'utilisateur.
3. Le CFP est un indicateur raisonnable de la valeur commerciale.
4. Le CFP s’aligne très bien sur l’effort réel.
5. CFP a une définition pour une unité de taille individuelle.
6. Le CFP fournit une mesure de la taille qui est le facteur le plus important pour déterminer le coût et la durée d'un projet.
7. CFP permet aux gestionnaires de gérer des activités non liées au développement en utilisant également CFP comme mesure de base.
8. CFP est ouvert, gratuit et indépendant.
9. Les CFP sont adaptés aux exigences incomplètes (c'est-à-dire Agile)
10. Les CFP sont adaptés à presque tous les types de logiciels
11. L'estimation précoce du CFP est en grande partie automatisée (par ScopeMaster®)

La mesure de la productivité du développement logiciel est l'activité d'enregistrement des mesures et des attributs d'une entreprise logicielle à des fins de comparaison.

Dans quelle mesure nos développeurs de logiciels sont-ils productifs ?

Souhaitez-vous savoir si votre équipe est plus productive qu’une autre ou que les normes de l’industrie ?

Vous pouvez comparer les activités d'une équipe par rapport à une autre au sein d'une organisation, benchmarking interne. La comparaison avec une autre organisation similaire est appelée analyse comparative externe.

Bien que les références sectorielles puissent être intéressantes, les références locales/internes sont les plus fiables.

Analyse comparative de la productivité du développement logiciel : évaluez votre équipe

Si vous avez une équipe formidable, pourquoi ne pas publier votre indice de productivité, cela vous aidera peut-être à remporter des travaux de développement ?

Tout ce dont vous avez besoin est un ensemble de user stories d'un projet précédent, environ 1 heure et un accès à ScopeMaster.

1. Prenez un ensemble d’exigences d’un projet récent. Téléchargez-les dans ScopeMaster. Laissez l'analyseur déterminer la taille.
2. Ajoutez au calculateur de productivité l'effort total nécessaire (en jours-personnes), la durée (en mois) et la suppression des défauts que vous avez obtenue.
3. Il déterminera ensuite le indice de productivité de votre équipe.

Et c'est tout ce qu'il y a à faire.

Si vous êtes au-dessus de la moyenne, disons 6+ pour une équipe Web, alors vous êtes sur la voie de la grandeur. Si vous le souhaitez, nous publierons l'indice de productivité de votre équipe sur notre classement.

Méfiez-vous des mesures trompeuses

Les story points, les lignes de code, les tailles de T-shirts, les jours-homme sont tous jouables ou faciles à manipuler, techniques généralement utilisées pour estimer l'effort et le temps. Ils sont invariablement manipulés à leurs propres fins. Seules les méthodes de dimensionnement fonctionnel standard ISO sont difficiles à maîtriser.