Points vs. heures

L'estimation traditionnelle aboutit à ce que l'on appelle brillamment "le cône d'incertitude". Le graphique montre que les estimations initiales du travail peuvent aller de 400 % au-delà du temps réellement pris à 25 % du temps pris. Les estimations basses et hautes

 

diffèrent d'un facteur de seize. Au fur et à mesure de l'avancement du projet, les estimations se rapprochent de plus en plus de la réalité, jusqu'à ce qu'il n'y ait plus d'estimations, mais seulement la réalité.

Il s'agit souvent d'un débat entre les points et les heures, mais en réalité il n'y a pas de débat. L'estimation en points reste une estimation, une supposition éclairée, mais elle donne des estimations beaucoup plus précises, prévisibles et stables. L'estimation en heures aboutira simplement à des estimations si éloignées de la réalité qu'elles seront inutiles. Il y a des raisons pour lesquelles les projets logiciels traditionnels sont si souvent en retard et dépassent le budget. L'insistance sur l'estimation en heures plutôt qu'en points est un facteur majeur.

Raison 1 : Les humains ne savent pas estimer en heures

L'homme est capable de mesurer le temps depuis des millénaires, mais jusqu'à il y a environ 150 ans (lorsque les horloges sont devenues plus précises et plus largement disponibles), mesurer le temps avec une précision supérieure à celle des jours était pratiquement inconnu. En fait, l'humanité a évolué pendant des centaines de milliers d'années en n'utilisant pas les heures et, par conséquent, elle n'est pas douée pour les estimer.

Ce que les humains savent faire, c'est estimer la taille relative. La recherche le confirme. Au début de la guerre froide, le ministère de la défense a demandé à la RAND Corporation de prévoir comment la technologie moderne modifierait la guerre. (Combien de temps faudra-t-il à un pays pour mettre au point une arme nucléaire ?) RAND a découvert que les estimations basées sur le temps présentaient des taux d'erreur importants et une grande variabilité, et que les humains étaient bien meilleurs pour estimer les tailles relatives, en particulier celles qui suivent le cycle de vie de l'animal. Séquence de Fibonacci. (La séquence est efficace pour l'estimation parce que la somme des quantités du plus grand nombre est égale au rapport entre le plus grand nombre et le plus petit. Et, comme le montre si bien la vidéo de gauche, il s'agit d'un schéma que l'humanité a observé partout dans le monde naturel depuis la nuit des temps).

Une étude récente de Microsoft analysant deux équipes Scrum (l'une estimant en heures, l'autre en points) a montré des résultats similaires. L'équipe estimant en points avait un taux d'erreur de +/- 25%, tandis que l'équipe estimant en heures avait un taux d'erreur allant jusqu'à +/- 400% (indiqué par la ligne gris clair dans la diapositive à votre droite).

Un autre avantage de l'estimation de la taille relative est qu'elle est plus rapide que d'essayer de planifier le nombre d'heures nécessaires à la réalisation d'un travail.

Raison 2 : L'utilisation des heures nuit à la vélocité

Dans Scrum, la vélocité est utilisée à la fois pour évaluer rapidement l'effort nécessaire à la réalisation d'un travail et pour déterminer l'impact d'un changement de processus sur la productivité. (Si la production augmente, maintenez le changement de processus, sinon revenez au processus précédent). Si une équipe mesure en heures, il lui sera impossible d'évaluer la production ou de mesurer la productivité.

Cela s'explique par le fait que les heures mesurent les intrants et que le Scrum est basé sur la mesure des extrants. Par exemple, s'il faut une heure à un membre de l'équipe pour effectuer un travail et deux heures à un autre membre de l'équipe pour effectuer le même travail, le résultat (le travail effectué) est le même malgré la différence de temps consacré au travail. L'estimation de la production doit être la même quelle que soit la personne qui effectue le travail. La vélocité mesure l'effort collectif de l'équipe et non l'apport d'un membre individuel de l'équipe.

Raison 3 : Le temps est compté

Une semaine de travail normale ne compte que 40 heures. Si l'effort est mesuré en heures, une équipe de 5 membres ne peut jamais dépasser 200 heures de travail par semaine. Hyperproductif Scrum Les équipes augmentent leur production de 400% ou plus. Pour réaliser ces gains en heures, il faudrait que chaque membre de l'équipe travaille 160 heures par semaine. Ce n'est pas possible et ce n'est certainement pas une Un rythme durable.

L'amélioration intervient lorsque l'ensemble de l'équipe devient plus efficace grâce à l'amélioration des processus et des pratiques. Si un membre de l'équipe mettait deux heures pour effectuer un travail et qu'il peut désormais le faire en une heure, sa production a doublé, mais le temps qu'il a consacré à ce travail a été réduit de moitié. Mesurer le nombre d'heures n'aurait jamais permis de rendre compte de cette amélioration.

Tant qu'elle sera conceptuellement liée au temps, la vélocité n'aura aucune valeur.

Souvent, les organisations sont réticentes à utiliser des points parce que la direction craint que les équipes ne gonflent artificiellement le nombre de points nécessaires à la réalisation d'un travail. Pourquoi ne pas estimer un travail à cinq points d'effort au lieu des trois qu'il vaut en réalité, ce qui créerait deux points d'inflation et augmenterait artificiellement la vélocité ?

Indépendamment de la validité de cette préoccupation, les équipes sont plus susceptibles de dégonfler la valeur des points.

Par exemple, le membre de l'équipe qui peut désormais effectuer son travail en une heure au lieu de deux pourrait être enclin à estimer ce même travail à une valeur de point inférieure lors d'une prochaine réunion de planification du sprint parce qu'il a l'impression que cela lui demande moins d'efforts maintenant qu'il a amélioré sa productivité. Il s'agit d'une déflation de points. Sa production étant la même, le travail doit être estimé à la même valeur en points.

Cependant, l'inflation et la déflation peuvent être mesurées et contrôlées à l'aide des paramètres de gestion Scrum.

(Les heures subissent également des pressions inflationnistes parce qu'elles sont souvent utilisées pour comparer l'effort des employés. En utilisant une technique appelée Cartographie de la chaîne de valeur montre que peu d'entreprises parviennent à une efficacité des processus supérieure à 15% sans efforts ciblés. Aucun employé ne veut admettre que sur une semaine de travail de 40 heures, il n'a accompli que 6 heures de travail effectif).

Points

Le Scrum Pattern Language of Programing : Le mouvement PLoP codifie des pratiques agiles bien connues qui ont été mises en œuvre avec succès à de nombreuses reprises.