Pourquoi la série Fibonacci est-elle utilisée dans le poker agile planning?

Lors de l’estimation de la taille relative des user stories dans le développement logiciel agile, les membres de l’équipe sont censés estimer la taille d’une user story comme étant 1, 2, 3, 5, 8, 13, …. Les valeurs estimées doivent donc ressembler à la série Fibonacci. Mais je me demande pourquoi?

La description de http://en.wikipedia.org/wiki/Planning_poker sur Wikipedia contient la phrase mystérieuse:

La raison d’utiliser la séquence de Fibonacci est de refléter l’incertitude inhérente à l’estimation d’éléments plus grands.

Mais pourquoi devrait-il y avoir une incertitude inhérente aux plus gros articles? L’incertitude n’est-elle pas plus grande si nous faisons moins de mesures, c’est-à-dire si moins de personnes estiment la même histoire? Et même si l’incertitude est plus grande dans les grandes histoires, pourquoi cela implique-t-il l’utilisation de la séquence de Fibonacci? Y a-t-il une raison mathématique ou statistique pour cela? Sinon, l’utilisation de la série Fibonacci pour l’estimation ressemble à la science CargoCult.

    La série Fibonacci n’est qu’un exemple d’une échelle d’évaluation exponentielle. La raison pour laquelle une échelle exponentielle est utilisée provient de la théorie de l’information.

    Les informations que nous obtenons hors estimation sont beaucoup plus lentes que la précision de l’estimation. En fait, il se développe comme une fonction logarithmique. C’est la raison de l’incertitude plus grande pour les articles plus gros.

    Déterminer la base la plus optimale de l’échelle exponentielle (normalisation) est difficile en pratique. La base correspondant à l’échelle de Fibonacci peut ou non être optimale.

    Voici une explication plus détaillée de la justification mathématique: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html

    Sur les six premiers numéros de la séquence de Fibonacci, quatre sont premiers. Cela limite les possibilités de décomposer une tâche en tâches plus petites pour que plusieurs personnes travaillent en parallèle. Cela pourrait conduire à penser à tort que la vitesse d’une tâche peut être proportionnelle au nombre de personnes qui y travaillent. La série 2 ^ n est la plus vulnérable à un tel problème. La séquence de Fibonacci oblige en effet à ré-évaluer les petites tâches une par une.

    Selon ce blog agile

    “parce qu’ils croissent à peu près au même rythme que nous, les humains, pouvons percevoir des changements significatifs dans leur ampleur.”

    Oui en effet. Je pense que c’est parce qu’ils ajoutent un air de légitimité (Fibonacci! Math!) À ce qui est essentiellement un exercice de dimensionnement (et non de cadrage) de très haut niveau et à un stade précoce (qui a de la valeur).

    Mais vous pouvez obtenir les mêmes résultats en utilisant les tailles de t-shirts …

    Vous voulez certainement quelque chose d’exponentiel, de sorte que vous puissiez exprimer n’importe quelle quantité de temps avec une erreur relative constante. La précision de votre estimation est également très probablement proportionnelle à votre estimation.

    Donc, vous voulez quelque chose: a) avec des entiers b) exponentielle c) facile

    Maintenant, pourquoi Fibonacci au lieu de, 1 2 4 8? Je suppose que c’est parce que fibonacci ralentit. C’est dans goldratio ^ n, et goldratio = 1,61 …

    La séquence de Fibonacci n’est que l’une des méthodes utilisées dans la planification de projets de poker.

    Il est difficile d’estimer avec précision de grandes unités de travail et il est facile de s’embourber dans des discussions sur des heures ou des jours si vos chiffres sont trop “réalistes”.

    J’aime l’explication de http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/ , à savoir que la série Fibonacci représente un ensemble de chiffres que nous pouvons distinguer de manière intuitive entre eux comme des grandeurs différentes.

    J’utilise Fibonacci pour deux raisons:

    • À mesure que la tâche augmente, les détails deviennent plus difficiles à saisir
    • L’estimation de tâche est le nombre d’heures pendant lesquelles une personne de l’équipe complète la tâche.
    • Tous les membres de l’équipe n’auront pas la même expérience pour une tâche particulière, ce qui ajoute à l’incertitude
    • L’humain est fatigué par une tâche plus vaste et potentiellement plus complexe. Bien qu’une tâche deux fois plus complexe soit résolue en un temps double pour un ordinateur, cela peut prendre un peu plus de temps pour un développeur.

    Comme nous ajoutons toutes les incertitudes, nous sums moins sûrs de ce que les heures devraient réellement être. Il devient plus facile si nous pouvons simplement évaluer si cette tâche est plus grande / plus petite qu’une autre où nous avons déjà donné une estimation. Comme nous augmentons la taille / complexité de la tâche, l’effet de l’incertitude est également amplifié. Je serais heureux de prendre une estimation de 13 heures pour une tâche qui semble deux fois plus grande que celle que j’avais précédemment estimée à 5 heures.