Les story points donnent des estimations plus précises, ils réduisent considérablement le temps de planification, ils prédisent plus précisément les dates de publication et ils aident les équipes à améliorer leurs performances. Les heures donnent de moins bonnes estimations, introduisent de grandes quantités de déchets dans le système, handicapent la planification des versions de la Product Owner et troublent l'équipe quant aux améliorations de processus qui ont réellement fonctionné.
Stratégie d'estimation de Microsoft
Stratégie d'estimation traditionnelle
Une nouvelle étude intéressante vient d'être publiée. Le Standish Group a mis à jour ses conclusions sur les taux de réussite des projets en se basant sur l'analyse des données de la dernière décennie avec des dizaines de milliers de points de données. En outre, Microsoft a publié de nouveaux résultats de recherche montrant que l'estimation agile est étonnamment plus précise que l'estimation traditionnelle des projets. Voir :
Scrum + Pratiques d'ingénierie : Expériences de trois équipes Microsoft
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
Lauréat du prix IEEE Best Industry Paper
De nombreuses personnes qui ont géré des projets avec des heures ont du mal à comprendre pourquoi les story points sont meilleurs. Elles n'ont pas compris certaines données fondamentales publiées depuis plus de 60 ans dans la littérature spécialisée ainsi que dans les recherches les plus récentes.
Tout d'abord, examinons les données les plus récentes sur les échecs de projets. Les taux d'échec augmentent pour les projets informatiques dans le contexte actuel de perturbation du système financier mondial. La dernière analyse du Standish Group montre que les projets agiles ont un taux de réussite trois fois supérieur à celui des projets traditionnels. Jim Johnson recommande désormais l'utilisation universelle de la pratique agile pour tous les projets.
En fait, la dernière étude du groupe Forrester montre que.. :
Les mesures courantes de gestion de projet condamnent les services informatiques à l'échec
Les investisseurs en capital-risque avec lesquels je travaille disent qu'ils n'ont jamais vu un diagramme de GANTT correct lors d'une réunion du conseil d'administration. Lorsqu'ils se penchent sur le problème, ils constatent qu'aucune de leurs équipes de gestion ne connaissait la vitesse de production de leurs équipes avant la mise en œuvre de Scrum. Le fait de ne pas connaître la vitesse de production des équipes est la cause première de l'échec de 100% en ce qui concerne l'exactitude des plans de mise en production lors des réunions du conseil d'administration.
La stabilité d'une histoire d'utilisateur est essentielle pour la planification. Une histoire en trois points aujourd'hui est en trois points l'année prochaine et constitue une partie mesurable de la version du produit pour un Product Owner. Le nombre d'heures nécessaires à la réalisation d'une histoire dépend de la personne qui la réalise et du jour où elle la réalise. Cela change tous les jours. Le diagramme de GANTT suppose un nombre fixe d'heures pour une personne fictive (qui n'est souvent pas la personne à mettre en œuvre) et suppose des dépendances fixes (qui changent constamment). Une étude portant sur 80 projets de plusieurs millions de dollars chez GSI Commerce (aujourd'hui propriété d'eBay) a montré que les meilleurs experts de l'entreprise étaient totalement incapables d'estimer le temps que prendrait un projet par les personnes qui l'ont réellement mis en œuvre.
On pourrait penser que ces données amènent les gens à changer de comportement, mais de nombreuses entreprises semblent préférer continuer à échouer et à être rachetées ou à faire faillite plutôt que d'améliorer leurs techniques de gestion de projet.
Les recherches menées par la Rand Corporation dans les années 1940 ont clairement montré que les humains ne sont pas doués pour estimer les heures de travail et l'expérience pratique n'a cessé de confirmer ces recherches. La Rand Corporation a recommandé l'approche Delphi pour l'estimation, qui a été adoptée dans le développement de logiciels en tant que méthode d'estimation des heures de travail. Delphi à large bande La même technique est maintenant intégrée dans la pratique appelée Planning Poker pour les équipes agiles. Cette même technique est désormais intégrée dans la pratique appelée Planning Poker pour les équipes agiles.
La mesure de gestion pour l'exécution du projet doit être une unité de production. La production est la condition préalable au revenu et les entreprises disent qu'elles sont en affaires pour augmenter le revenu et les marges (même si, dans la planification du projet, elles font souvent le contraire). Au moins un groupe de capital-risque est clair sur le fait qu'il s'agit avant tout d'argent et que l'argent provient de la vitesse de production combinée à la qualité du produit. Les heures sont des dépenses et doivent être réduites ou éliminées dans la mesure du possible.
Les meilleures données sur les performances individuelles des développeurs proviennent de l'université de Yale et ont été présentées précédemment sur ce blog. Le meilleur développeur d'un projet met une heure pour accomplir une tâche, tandis que le moins bon prend 10 heures (au sein d'un même projet) ou 25 heures (pour l'ensemble des projets). Pour les équipes, la différence est d'un ordre de grandeur supérieur. Les données publiées par Larry Putnam montrent qu'une heure pour l'équipe la plus productive se transforme en 2000 heures pour l'équipe la moins productive.
Les heures complétées ne disent rien au Product Owner sur le nombre de fonctionnalités qu'il peut expédier et sur le moment où il peut les expédier.
La mesure importante est le nombre de points de récit que l'équipe peut livrer par unité de temps calendaire. Le nombre de points par sprint correspond à la vélocité. C'est pourquoi nous estimons tout en points pour le Product Owner afin qu'il puisse créer une feuille de route basée sur la vélocité de l'équipe et ajuster le plan si la vélocité change.
La façon dont nous procédons à l'estimation par story points donne de meilleures estimations que les estimations horaires, car elles sont plus précises et présentent moins de variations. Une entreprise CMMI de niveau 5 a déterminé que l'estimation des story points réduit le temps d'estimation de 80%, ce qui permet aux équipes de faire plus d'estimation et de suivi qu'une équipe typique de waterfall. Une entreprise de télécommunications a remarqué que l'estimation des story points avec le planning poker était 48 fois plus rapide que les pratiques d'estimation en cascade dans l'entreprise et donnait des estimations aussi bonnes, voire meilleures.
Les points de récit sont donc plus rapides, meilleurs et moins chers que les heures, et les équipes les plus performantes abandonnent complètement toute estimation horaire, qu'elles considèrent comme un gaspillage qui ne fait que les ralentir.
Pour une analyse complète du débat sur les points et les heures, voir Scrum Inc.'s webinaire sur le sujet.
French 
English 
Spanish