fbpx

Points d'histoire: Pourquoi sont-ils meilleurs que des heures? – Déménagement


Les récits fournissent des estimations plus précises, ils réduisent considérablement le temps de planification, ils prédisent plus précisément les dates de sortie et ils aident les équipes à améliorer les performances. Les heures donnent des estimations moins bonnes, introduisent de grandes quantités de déchets dans le système, handicapent la planification des versions du Product Owner et confondent l'équipe sur les améliorations de processus qui ont vraiment fonctionné.

Microsoft Estimation Strategy

Traditional Estimation Strategy

De nouvelles recherches intéressantes sont devenues disponibles. Le Standish Group a mis à jour ses conclusions sur les taux de réussite des projets sur la base de l'analyse de la dernière décennie de données avec des dizaines de milliers de points de données. En outre, Microsoft a de nouveaux résultats de recherche montrant que l'estimation agile est étonnamment plus précise que l'estimation de projet traditionnelle. Voir:

Scrum + Engineering Practices: Experiences of Three Microsoft Teams
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
IEEE Best Industry Paper award award

De nombreuses personnes qui ont géré des projets avec des heures ont du mal à comprendre pourquoi les points d'histoire sont meilleurs. Ils n'ont pas réussi à comprendre certaines données fondamentales publiées depuis plus de 60 ans dans la littérature de l'industrie ainsi que les dernières recherches.

Tout d'abord, regardons les dernières données sur les échecs des projets. Les taux d'échec augmentent pour les projets informatiques pendant la perturbation actuelle du système financier mondial. La dernière analyse du groupe Standish montre que les projets agiles ont trois fois le taux de réussite des projets traditionnels.

En fait, les dernières recherches du groupe Forrester montrent que:
Les métriques communes de gestion de projets font échouer les départements informatiques

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. Quand ils creusent le problème, ils disent qu'aucune de leurs équipes de gestion ne connaissait la vitesse de leurs équipes avant d'implémenter Scrum. Le fait de ne pas connaître la vitesse de production des équipes est à l'origine de l'échec à 100% des plans de publication à être précis lors de leurs réunions du conseil d'administration. Une histoire en trois points aujourd'hui est trois points l'année prochaine et constitue une partie mesurable de la version du produit pour un propriétaire de produit. Les heures pour faire une histoire dépendent de qui le fait et du jour où cette personne le fait. Cela change tous les jours. Le diagramme de GANTT suppose un nombre d'heures fixe pour une personne fictive (qui n'est souvent pas la personne à implémenter) et suppose des dépendances fixes (qui changent toujours). Une étude de 80 projets de plusieurs millions de dollars chez GSI Commerce (maintenant détenue par eBay) a montré que les meilleurs experts de l'entreprise étaient totalement incapables d'estimer le temps qu'un projet prendrait par les personnes qui l'ont réellement mis en œuvre.

On pourrait penser ces données inciteraient les gens à changer leur comportement, mais de nombreuses entreprises semblent préférer continuer à échouer et être acquises ou faire faillite plutôt que d'améliorer leurs techniques de gestion de projet.

Les recherches de Rand Corporation dans les années 40 ont montré clairement que les humains ne sont pas bons à l'estimation des heures et de l'expérience pratique confirme à plusieurs reprises la recherche. Ils ont recommandé l'approche Delphi de l'estimation qui a été adoptée dans le développement logiciel comme technique Delphi à large bande. La même technique est maintenant intégrée dans la pratique appelée Planning Poker pour les équipes agiles.

La métrique de gestion pour la livraison du projet doit être une unité de production. La production est la condition préalable aux revenus et les entreprises disent qu'elles sont en affaires pour augmenter leurs revenus et leurs marges (même si dans la planification de projets, elles font souvent le contraire). Au moins un groupe de capital-risque est clair qu'il s'agit de l'argent et l'argent vient de la vitesse de production combinée à la qualité du produit. Les heures sont des dépenses et devraient être réduites ou éliminées autant que possible.

Les meilleures données sur les performances des développeurs individuels proviennent de l'Université de Yale et ont été rapportées précédemment sur ce blog. Le meilleur développeur d'un projet prend une heure pour terminer une tâche tandis que le pire développeur prend 10 heures (au sein d'un projet) ou 25 heures (entre 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 terminées ne disent rien au Product Owner sur le nombre de fonctionnalités qu'il peut expédier et quand il peut les expédier.

La métrique importante est le nombre de points d'histoire que l'équipe peut livrer par unité de temps calendaire. Les points par sprint sont la vitesse. Par conséquent, nous estimons tout en points pour le Product Owner afin qu'il crée une feuille de route de sortie basée sur la vitesse de l'équipe et ajuste le plan si la vitesse change.

La façon dont nous faisons l'estimation ponctuelle donne de meilleures estimations que les estimations horaires car elles sont plus précises et ont moins de variation. Une entreprise CMMI de niveau 5 a déterminé que l'estimation du point d'histoire réduit le temps d'estimation de 80%, ce qui permet aux équipes de faire plus d'estimation et de suivi qu'une équipe de cascade typique. Une entreprise de télécommunications a remarqué que les points d'histoire estimés lors de la planification du poker étaient 48 fois plus rapides que les pratiques d'estimation de cascades dans l'entreprise et a donné des estimations aussi bonnes que meilleures. abandonner complètement toute estimation horaire car ils la considèrent comme un gaspillage qui les ralentit simplement.

Pour une analyse complète du débat points contre heures, voir le webinaire de Scrum Inc. sur le sujet.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *