Points de Story - Pourquoi sont-ils préférables aux heures ?
Auteur : Jeff Sutherland
Source : Story Points: Why are they better than hours?
Date : 30/04/2010
Traducteur : Fabrice Aimetti
Date : 30/08/2012
Traduction :
|
|
| Cône d'estimation traditionnelle |
|
|
| Précision du Point de Story chez Microsoft |
Il est temps de mettre à jour ce billet puisque les résultats de nouvelles recherches intéressantes sont désormais disponibles. Le Standish Group a mis à jour ses résultats sur les taux de réussite des projets en s'appuyant sur les analyses de la dernière décennie comportant des dizaines de milliers de données. En outre, Microsoft a publié de nouveaux résultats de recherche montrant que le mode d'estimation agile est étonnamment plus précis que le mode d'estimation des projets traditionnels. Voir :
Scrum + Pratiques d'Ingénierie : Expériences de Trois Equipes MicrosoftLaurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
Prix du meilleur article décerné par IEEE
Beaucoup de gens qui ont géré des projets en heures ont du mal à comprendre pourquoi les points de story sont préférables. Ils n'ont pas réussi à comprendre certaines données fondamentales qui ont été publiées depuis plus de 20 ans dans la littérature ainsi que les résultats des dernières recherches.
Tout d'abord, penchons-nous sur les données les plus récentes concernant les projets qui ont échoué. Les taux d'échec ont augmenté pour les projets pendant la période actuelle 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 aux projets traditionnels. Jim Johnson recommande maintenant que la démarche agile soit utilisée sur tous les projets.
En fait, les récentes recherches du Groupe Forrester montre que :
Les métriques de gestion de projet traditionnelles condamnent les DSI à l'échec
Les capital-risqueurs avec qui je travaille disent qu'ils n'ont jamais vu un diagramme de GANTT correct dans une réunion de direction. Quand ils creusent le problème, ils disent qu'aucune de leurs équipes de management ne connaissait la vélocité de son équipe avant de mettre en œuvre Scrum. Ne pas connaître la vitesse de production des équipes est à l'origine de l'échec de 100% des plannings de livraisons, soit-disant précis et affichés lors des réunions de pilotage.
On pourrait penser que ces données auraient incité les gens à changer leur comportement, mais de nombreuses entreprises semblent préférer continuer à échouer, être rachetées ou faire faillite plutôt que d'améliorer leurs techniques de gestion de projet.
Rand Corporation a fait des recherches dans les années 1940 qui ont clairement montré que les êtres humains ne sont pas doués pour estimer en heures et les nombreuses expériences menées sur le terrain ont à plusieurs reprises confirmé ces résultats. En matière d'estimation, ils ont recommandé l'approche Delphi qui a été adoptée dans le développement logiciel sous le dénominatif de technique Delphi Wide Band. Cette même technique est désormais intégrée dans la pratique appelée Planning Poker adoptée par les équipes agiles.
La métrique pour la livraison du projet doit être une unité de production. La production conditionne nécessairement le chiffre d'affaires et les entreprises disent qu'elles sont dans le métier pour augmenter le chiffre d'affaires et les marges (même si lors de la planification de projets, elles font souvent le contraire). A minima, un groupe de capital-risque dira clairement que tout cela est une question d'argent et que l'argent vient de la vitesse de production combinée à la qualité du produit. Les heures représentent des coûts et doivent être réduites ou éliminées autant que possible.
Les meilleures données disponibles sur la performance individuelle d'un développeur proviennent de l'Université de Yale et ont été précédemment commentées sur ce blog. Le meilleur développeur sur un projet prend une heure pour accomplir une tâche alors que le pire développeur prend 10 heures (dans un projet) ou 25 heures (tous les 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 réalisées n'apportent au Product Owner aucune information sur le nombre de fonctionnalités qu'il peut déployer et quand il peut les déployer.
La métrique importante est le nombre de points de story que l'équipe peut livrer par unité de temps calendaire. Le nombre de points par sprint est la vélocité. Par conséquent, nous estimons tout en points pour le Product Owner afin qu'il crée un plan de versions basé sur la vélocité de l'équipe et qu'il ajuste le plan si la vélocité change.
La manière dont nous menons l'estimation en points de story produit de meilleures estimations que les estimations horaires car elles sont plus précises et subissent moins de variations. Une entreprise CMMI niveau 5 a déterminé que l'estimation en point de story réduisait le temps d'estimation de 80% et permettait aux équipes de faire plus d'estimation et de mesures qu'une habituelle équipe cycle en V. Une entreprise de télécommunications a remarqué que l'estimation en points de story avec le planning poker était 48 fois plus rapide que les pratiques d'estimation cycle en V utilisées dans cette même entreprise et qu'elle donnait d'aussi bonnes estimations voire meilleures.
L'estimation en points de story est donc plus rapide, meilleure et moins chère que l'estimation en heures. Les équipes les plus performantes ont complètement abandonné toute estimation en heures qu'elles considèrent comme du gaspillage et un frein.
