Estimation logicielle : comment réconcilier agilité et Points de Fonction ?

Estimation logicielle : comment réconcilier agilité et les Points de Fonction ?

Le Point de Fonction (PF) est une mesure de taille du logiciel utilisée depuis de nombreuses années.
L’utilisation de Points de Fonction comme unité de mesure pour les projets agiles présente des avantages et des défis.

Plusieurs raisons expliquent le succès des PF pour l’estimation des charges des projets logiciels. En particulier, lorsque le périmètre est décomposé pour le comptage des PF et que cela aide à mesurer le code partagé.

Un gros avantage : le comptage des PF est une norme internationale, sa définition ne varie donc pas. C’est bien sûr la raison pour laquelle la norme a été élaborée. De nombreuses entreprises investissent dans la formation des compteurs de PF. En fait, il existe plusieurs façons de mesurer la taille des projets logiciels en Points de Fonction. Elles sont cependant toutes similaires.

Pourquoi les équipes agiles rechignent-elles à utiliser les Points de Fonction ?

Les équipes agiles ont souvent du mal à adopter les PF car elles les considèrent comme obsolètes. Elles pensent donc qu’ils ne sont pas compatibles avec l’agilité. Cette dernière étant supposée comme plus moderne.

De plus, contrairement aux Story Points (SP), l’équipe agile n’aura pas à utiliser les PF au-delà de l’estimation. Ils ne font de fait pas partie de la méthode Agile. De plus, les EPICS et les Story Points ne correspondent pas à la décomposition du périmètre de comptage PF d’un projet. Vous ne pouvez pas compter les PF dans chaque Story et les additionner, étant donné qu’un seul composant peut chevaucher plusieurs Stories. Ceci peut être atténué en comptant les PF en parallèle des SP. D’autres techniques peuvent être utilisées pour planifier les itérations. L’utilisation des PF est alors limitée à l’estimation de la version et au suivi global du projet.

Auparavant, il n’était pas rare que des aficionados d’agilité se servent des Points de Fonction. Cependant, il y avait moins de pression pour recompter le nombre réel de PF à la fin d’un projet.

L’estimation en amont avec peu d’exigences connues

Les deux raisons majeures qui freinnent l’utilisation des Points de Fonction dans le cadre de projets agiles sont : l’apparition des exigences au cours du projet et le manque de précision du périmètre lors de l’estimation de la version ou du projet. La méthode des Story Points et le « Big Rock Sizing » permettent de surmonter ces obstacles. Elles mettent en avant des problèmes qui devront être surmonter pour utiliser les Points de Fonction.

La méthode de comptage FP exige un niveau de détail des exigences qui n’est habituellement pas disponible au début d’un projet agile. Par exemple, il convient de comptez les données qui seront utilisées et d’attribuer une valeur de PF en fonction du nombre approximatif de données.

Ces informations ne sont pas disponibles au début d’un projet agile. Dans certains cas, il est possible de les deviner. Si vous construisez le site de réservation d’une compagnie aérienne, vous savez que vous aurez des données concernant les aéroports, les vols, les places disponibles, les réservations et d’autres. Mais la liste des données s’étoffe au cours du projet, quand les « Big Rocks » s’affinent itération par itération. Même pour les données que l’on peut deviner, il est impossible de connaître, même approximativement, le nombre d’éléments lors du comptage PF. Demander à l’équipe de réfléchir à ces détails en début de projet n’est pas compatible avec le principe même de l’agilité. Même une « bonne hypothèse » pourrait biaiser l’équipe au moment où les éléments détaillés seront nécessaires.

Solutions

Certains experts proposent deux solutions pour atténuer ce problème. Tout d’abord, il y a les techniques de comptage rapide, y compris pour attribuer les PF basés sur la complexité détaillée de chacun des éléments. Il faut alors faire l’hypothèse que chaque élément possède une complexité moyenne. Il est également possible de compter les éléments évidents sans biaiser les futures exigences. Les éléments moins évidents seront comptés ultérieurement.

La seconde est de faire un comptage en parallèle. Cela atténue la réticence des équipes envers l’utilisation de Points pour leurs activités quotidiennes. Cette technique est particulièrement utile pour le suivi d’avancement du projet et la prévision d’achèvement en cours de projet. Un comptage initial des PF est réalisé sur les exigences de haut niveau (Epics), avec une approche de comptage rapide. Lorsque les exigences sont plus détaillées (Story), un comptage séparé des points de fonction est maintenu, au fur et à mesure de l’évolution du backlog.

Lignes de Code Source pour l’Estimation Agile

Tous les autres projets de développement logiciel, agilité ou non, ont pour produit fini, du code. Compter le code permet de donner une indication sur la taille. Il s’agit d’ailleurs certainement de la méthode de mesure la plus concrète pour déterminer la taille d’un projet. Contrairement aux PF et aux SP, il existe une définition standard d’une ligne de source unique du code. Elle est d’ailleurs étonnamment complexe.

De nombreuses équipes ont abandonné le comptage des lignes de code bien avant la popularité des méthodes agiles. Il y a plusieurs raisons à cela. Certaines sont bonnes, d’autres sont plus émotionnelles que logiques.

Compter les lignes pour déterminer la taille du code reste cependant un moyen viable de comparer la taille des projets. C’est d’ailleurs peut-être la meilleure façon d’obtenir des données normalisées provenant de nombreuses sources différentes. C’est particulièrement utile pour benchmarker votre organisation par rapport aux données du secteur. Et puisqu’elle est indépendante de la façon dont est exprimée le périmètre du projet, le comptage du nombre de lignes de code livrées permet de comparer les projets agiles aux autres projets.

Le principal inconvénient du comptage de lignes de code pour l’estimation initiale n’est pas spécifique à l’agilité. Les membres de l’équipe projet n’ont aucune idée du nombre total de lignes de code. Demandez à la plupart des développeurs, « combien de lignes de code pensez-vous qu’il y aura ? », vous n’obtiendrez qu’un regard étonné.

Pour compter les lignes de code des projets terminés, vous pouvez utiliser des compteurs automatisés qui fonctionnent avec les fichiers sources, ou avec les systèmes de gestion de version que votre équipe utilise. Ainsi, vous pouvez obtenir des dénombrements de code « après coup », à utiliser pour calibrer vos estimations à l’aide d’autres méthodes de mesure, comme décrit plus haut.

Résumé

Comme pour les projets s’appuyant sur d’autres méthodes, les PF peuvent être appliqués aux projets agiles, il s’agit d’une norme internationale. Les équipes agiles peuvent être cependant réticentes, à cause de l’image désuette dont souffrent les PF. Plus important encore, l’absence d’exigences détaillées en début de projet représente un défi pour mener un comptage rigoureux des PF.

Le nombre de lignes de code source est une mesure concrète qui peut être utilisée de façon constante et peut aider à faire du benchmarking. Vous pouvez automatiser le comptage de la taille des projets achevés, et obtenir ainsi une bonne base de données historiques pour les estimations futures. Cependant, le manque d’expérience dans cette mesure rend son utilisation difficile pour l’estimation d’un nouveau projet.

Découvrez les offres de produits et de services Estimancy permettant de mesurer ou d’estimer des projets logiciels à partir des exigences utilisateurs rédigées en langage naturel.