Pourquoi la série Fibonacci est-elle utilisée dans agile planning poker? [fermé]
Lors de l'estimation de la taille relative des user stories dans le développement de logiciels agiles, les membres de l'équipe sont censés estimer la taille d'une User story comme étant 1, 2, 3, 5, 8, 13, ... . Ainsi, les valeurs estimées devraient ressembler à la série de Fibonacci. Mais je me demande, pourquoi?
La description de http://en.wikipedia.org/wiki/Planning_poker sur Wikipedia détient la phrase mystérieuse:
La raison d'utiliser la séquence de Fibonacci est de refléter la incertitude dans l'estimation des articles plus importants.
Mais pourquoi devrait-il y avoir une incertitude inhérente aux articles plus importants? L'incertitude n'est-elle pas plus élevée si nous faisons moins de mesures, ce qui signifie que moins de personnes estiment la même histoire? Et même si l'incertitude est plus élevée dans les grandes histoires, pourquoi cela implique l'utilisation de la suite de Fibonacci? Est-il mathématique ou statistique raison? Sinon, l'utilisation de la série Fibonacci pour l'estimation ressemble à la science CargoCult pour moi.
6 réponses
La série de Fibonacci n'est qu'un exemple d'échelle d'estimation exponentielle. La raison pour laquelle une échelle exponentielle est utilisée vient de la théorie de l'Information.
Les informations que nous obtenons de l'estimation augmente beaucoup plus lentement 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 élevée pour les articles plus importants.
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 nombres de la séquence de Fibonacci, quatre sont premiers. Cela limite les possibilités de décomposer une tâche également en tâches plus petites pour que plusieurs personnes y travaillent en parallèle. Cela pourrait conduire à l'idée fausse que la vitesse d'une tâche pourrait évoluer proportionnellement 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 fait à réévaluer les petites tâches une par une.
Selon ce blog agile
"parce qu'ils grandissent à peu près au même rythme auquel nous, les humains, pouvons percevoir des changements significatifs d'ampleur."
Ouais, c'est ça. Je pense que c'est parce qu'ils ajoutent un air de légitimité (Fibonacci! maths!) à ce qui est essentiellement un exercice de dimensionnement de très haut niveau, à un stade précoce (pas de portée) (qui a de la valeur).
Mais vous pouvez obtenir les mêmes résultats en utilisant le dimensionnement des T-shirts...
Vous voulez certainement quelque chose d'exponentiel, de sorte que vous pouvez 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 se développe plus lentement. C'est dans goldratio^n, et goldratio = 1.61...
La séquence de Fibonacci est juste l'un des nombreux qui sont utilisés dans la planification de projet poker.
Il est difficile d'estimer avec précision les grandes unités de travail et il est facile de s'enliser dans les discussions des heures par rapport aux jours si vos chiffres sont trop "réalistes".
J'aime l'explication à http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/, à savoir la série de Fibonacci représente un ensemble de nombres que nous pouvons intuitivement distinguer entre eux comme des grandeurs différentes.
J'utilise Fibonacci pour plusieurs raisons:
- à mesure que la tâche devient plus grande, les détails deviennent plus difficiles à saisir
- Tâche d'estimer le nombre d'heures pour toute personne dans l'équipe pour compléter la tâche
- Tous les membres de l'équipe n'auront pas la même expérience pour une tâche particulière qui ajoute à l'incertitude aussi
- L'humain se fatigue sur une tâche plus grande et potentiellement plus complexe. Alors qu'une tâche deux fois plus complexe est résolue en double temps pour un ordinateur il peut prendre un peu plus pour un développeur.
Comme nous additionnons toutes les incertitudes, nous sommes moins sûrs de ce que les heures devraient être. Cela finit plus facile si nous pouvons juste évaluer si cette tâche est plus grande/plus petite qu'une autre où nous avons déjà donné une estimation. À mesure que 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'ai précédemment estimée à 5 heure.