Article publié par ISBSG et traduit par nos soins.
De nombreuses entreprises ont troqué les méthodes de gestion de projet traditionnelles (cascade) pour des approches agiles ou DevOps. Ce type de développement logiciel a pour effet de valoriser les équipes agiles. Il permet de mener les développements de manière centralisée, plutôt que de se focaliser sur ce à quoi pourrait ressembler le projet et cela demande moins de contrôle de gestion parce que :
- Il est plus difficile de mesurer la productivité à cause de l’adoption des Story Point au niveau de l’équipe.
- Beaucoup d’organisations sont dans l’incapacité de mettre en place une méthode standardisée pouvant être utilisée pour le mesurage et l’amélioration de la productivité, le benchmarking, les estimations à long terme, ainsi que les KPI contractuels.
Ce court article explique pourquoi de nombreuses organisations ont perdu le contrôle de ces activités primordiales après avoir basculé dans le monde agile. En guise de résumé, nous déboulonnerons quelques idées reçues souvent entendues.
La nécessité de mettre en place des normes
Le principal problème, c’est la nécessité d’un outil de mesure normé, objectif, répétable, vérifiable, et si possible, pouvant être facilement mis en place ou automatisé. Jusqu’à maintenant, la norme internationale ISO/IEC pour la mesure de la taille fonctionnelle est la seule pouvant être utilisée pour mesurer les développements logiciels de manière objective, répétable, vérifiable et défendable. Les méthodes IFPUG, Nesma et COSMIC se conforment toutes à cette norme ISO, en plus de répondre à leurs propres normes. Ces méthodes peuvent généralement être appliquées par la plupart des équipes agiles, étant donné qu’elles permettent de mesurer sans problème les User Stories malgré le manque de temps et de moyens. Cependant, il y a plusieurs raisons pour lesquelles les Points de Fonctions sont encore peu utilisés par les équipes agiles :
- Le comptage des Points de Fonction, qu’il s’agisse de la méthode IFPUG, Nesma ou COSMIC, demande l’expertise d’un spécialiste. De nombreuses organisations ne disposent pas des connaissances nécessaires pour saisir l’intérêt d’un tel comptage ou n’ont ni les compétences, ni l’expérience permettant de mener à bien ce genre d’activités.
- On pense souvent que le comptage des Points de Fonction est onéreux. Or, des études récentes, appuyées par l’expérience de chefs de projets/Scrum masters, montrent qu’il est très facile et rapide de mesurer les Users Stories en Points de Fonction COSMIC.
- Les estimations reposant sur les Points de Fonctions COSMIC seraient plus précises que les études reposant sur les Story Points.
- Les équipes agiles considèrent souvent que les Points de Fonction relèvent du « vieux monde traditionnel », et qu’ils n’ont pas leur place dans le monde moderne. Cependant, les Points de Fonction sont une norme du concept universel de la taille. Tout comme le mètre ou le pied, la taille ne dépend ni de la méthodologie ou des matériaux utilisés pour le développement, ni des exigences non fonctionnelles.
Étant donné que les équipes agiles utilisent les Story Points, elles ne ressentent pas le besoin d’utiliser d’autres méthodes de mesure. Elles ont même réussi à convaincre leurs directions que c’était la seule méthode. En revanche, les directions n’ont plus la capacité de contrôler la livraison des fonctionnalités. Elles ne peuvent pas appréhender les capacités de leurs équipes et les comparer avec celles du marché. Alors, des activités cruciales telles que la mesure et l’amélioration de la productivité ou encore le benchmarking sont passées à la trappe, ce qui constitue un gros risque pour beaucoup d’organisations.
Mettons fin aux idées reçues
Pour résumer, quelques idées reçues sont démontées dans ce tableau :
| Idée reçue | Vérité |
| Les graphiques d’avancement montrent les progrès d’une équipe de manière objective. |
Tout comme les Story Points, les graphiques d’avancement ne répondent pas à une norme. Ils peuvent être facilement manipulés, surtout avec les KPI contractuels. On parle généralement du concept d’inflation du Story Point. |
| Les Points de Fonctions étaient utiles uniquement pour mesurer les logiciels en Cobol fonctionnant sur des ordinateurs centraux. |
Le comptage des Points de Fonction est une norme standard permettant de mesurer les fonctionnalités que le logiciel fournit à l’utilisateur, peu importe l’environnement technique et les exigences non fonctionnelles. Les mètres sont utilisés depuis des centaines d’années pour mesurer les longueurs. De la même manière, les Points de Fonction peuvent toujours être utilisés aujourd’hui pour mesurer les fonctionnalités qu’un logiciel fournit à un utilisateur. |
| Les Points de Fonction coûtent cher et ils sont peu précis. | Les Scrums masters, les analystes des exigences ou les autres membres des équipes peuvent apprendre en quelques jours les méthodes de comptage de Points de Fonction de haut niveau. Le comptage des Points de Fonction par sprint est plus rapide que les sessions de planification des sprints. Il fournit en plus des résultats plus précis et fiables. |
| Les équipes agiles ne doivent pas utiliser les Points de Fonction, c’est considéré comme un gâchis (pour reprendre les termes Lean). |
Au niveau de l’équipe, le comptage des Points de Fonction peut être considéré comme étant du gâchis, car les Story Points lui donnent assez d’indices sur sa performance. Cependant, les directions ont besoin de comprendre les budgets, les contrats, la performance, en plus de prendre des décisions concernant la taille de l’équipe. Comme ce n’est pas possible avec les Story Points, le comptage Points de Fonction ne représente certainement pas un gâchis pour la direction. |
| Même avec les Points de Fonction, il n’y a pas de données disponibles pour comparaison. Cela prendra donc un certain temps pour mettre en place des indicateurs. |
Le référentiel ISBSG comprend les données de plus de 8 000 projets de développements logiciels, de livraisons et de sprints sous format Excel, ce qui permet de débuter. Les sprints étant généralement relativement courts (2 ou 3 semaines), l’accumulation de données se fait rapidement. |
![[Replay webinaire] Spécification des projets logiciels : estimer les projets agiles](https://www.estimancy.com/wp-content/uploads/Copie-de-Copie-de-Webinaire-21-octobre-2021-768x480.jpg)
