Je constate souvent que les estimations dans les équipes agiles ne sont pas très bien faite, notamment parce que les principes de bases sont mal compris. Voici donc une proposition d’atelier, très simple à animer, pour mieux comprendre et mieux utiliser les estimations.
Cet atelier se pratique avec deux sachets de 100 cubes que vous pouvez acheter en ligne. Attention, commandez bien 100 cubes de chaque couleur. Vous les recevrez emballés dans 2 sachets de 100 cubes chacun.
Lors de l’atelier, sortez un des sachets, avec les cubes en vrac à l’intérieur.
Sortez environ 1/3 des cubes du sachet et faites-en un petits tas, comme sur la photo.
Demandez aux participants à l’atelier combien il y a de cubes dans le tas, sans les compter.
Certains proposeront des nombres. Vous pouvez leur dire à tous que c’est faux. Peut-être quelqu’un dira “je ne sais pas”, ou “à peu près 30”. Ce sont des réponses acceptables.
Maintenant, posez un second tas sur la table avec ce qui reste dans le sachet et redemandez au groupe d’estimer le nombre de cubes.
Toutes les estimations avec un nombre précis seront fausses. Quelqu’un dira peut-être “Plus que dans le premier tas”. C’est le moment d’arrêter la devinette. Vous pouvez alors expliquer que le cerveau humain n’est pas capable d’estimer correctement un nombre exact d’items dans un groupe. Cela est vrai pour les petits cubes, mais vous pouvez donner un grand nombre d’autres exemples : combien de cm entre la table et le mur ? Combien de grammes pèse la chaise ? Combien de fleurs dans un grand bouquet ?…
Demandez maintenant quel tas est plus gros que l’autre. Vérifiez si tout le monde est d’accord. Ce sera le cas, car notre cerveau est très fort pour comparer. Même un bébé sait que ce petit ballon est plus petit que ce gros ballon à côté. Demandez alors de combien le grand tas est-il plus grand que le petit tas. Là, vous pourrez avoir des divergences : 2 fois plus, 2,5 fois plus, 1,5 fois plus… On retrouve le problème du début, on sait très facilement comparer, mais pas donner d’estimation précise.
Faites une nouvelle expérience. Placer sur la table 2 ou 3 cubes et demandez combien de cubes vous avez posés. Tout le monde donnera la bonne réponse. Mettez-en 4, tout le monde donne la bonne réponse. Mettez-en 5 ou 6, en vrac. Il faudra plus de temps pour répondre. Il faudra compter. Organisez les 5 ou 6 cubes comme sur un dé. La réponse est immédiate. Mettez en 9, bien organisés en carré de 3X3, la réponse sera immédiate. Que voyons-nous ? Notre cerveau reconnait très facilement des petites quantités (jusqu’à 4 ou 5 unités), mais après ça se complique, il faut compter. Pourtant, lorsque les cube sont bien organisés, on peut facilement reconnaître 6, 7, 8 ou même 9 cubes.
En tant qu’humains, nous avons développé des capacités particulières qui nous permettent de dépasser nos capacités de base, soit en organisant bien les choses, soit en utilisant les mathématiques.
C’est là que vous pouvez sortir un sachet bien ordonné de 100 cubes, organisés en carré de 10X10. Une fois comptés les 10 cubes de chaque côté, tout le monde pourra dire que le sachet contient 100 cubes.
Il est très important de bien comprendre ces deux principes :
-
Nous ne savons pas évaluer de façon précise un grand nombre.
-
Nous savons très bien comparer deux items de même nature.
C’est là qu’intervient ce génie italien, Leonardo Fibonacci inventeur en 1225 de la suite de Fibonacci lors d’un jeu de devinettes mathématiques. J’avoue que mon livre de chevet, quand j’avais 12 ans était un livre “Les mathématiques” de la série Time-Life et que j’avais déjà alors un faible pour la suite de Fibonacci qui y était présentée. Il y a aussi dans ce livre un chapitre très inspirant sur la topologie, mais c’est une autre histoire !
Bref, j’avais depuis longtemps un faible pour Fibonacci lorsque j’ai découvert l’agilité, les estimations et les cartes de Poker Planning.
Pour ceux qui ne connaissent pas, je précise que dans les équipes Agile, il arrive un moment où il faut estimer les efforts nécessaires pour réaliser des tâches. Dans les équipes Scrum, il s’agira d’affecter un certain nombre de “Story points” pour chaque “User story”. Les estimations sont très utiles dans bien d’autres contextes, en dehors des équipes Scrum et même en dehors du développement informatique. On peut ainsi estimer les efforts nécessaires pour préparer des cours, pour recruter, pour organiser un événement, etc.
Cet exercice est basé sur la suite de Fibonacci. La suite de Fibonacci décrit les mathématiques de la croissance organique. Qu’il s’agisse de la croissance d’un coquillage ou de la reproduction des lapins, cette suite décrit un phénomène naturel et en cela elle résonne “juste” au plus profond de nous. Comment ça marche ? On commence avec 1 (Fibonacci commence avec 0, mais nous allons ignorer ce début car nous ne sommes pas intéressés à estimer des tâches où il n’y a rien à faire). Donc, on commence avec 1, puis encore 1. En les additionnant, on obtient 2. En additionnant 1 et 2, on obtient 3. En additionnant 2 et 3, on obtient 5, et ainsi de suite. On additionne chaque fois les deux derniers nombres pour obtenir le suivant. Croissance organique : on construit chaque étage sur ceux qui sont déjà là. Voir les images.
Juste pour le plaisir : toutes les spirales dans la nature se construisent en suivant la suite de Fibonacci. Comptez les spirales dans un ananas, une pomme de pin, un tournesol, les cheveux sur la tête (photo dans le livre de mathématiques de mon enfance), etc. Encore un indice qui montre combien cela résonne en nous, le ratio entre deux nombres de la suite, lorsqu’on arrive aux grands nombres, tend vers le nombre d’or. Ce fameux nombre d’or réputé être particulièrement harmonieux et tant utilisé par Léonard de Vinci et beaucoup d’architectes.
Donc, l’idée géniale des agilistes c’est d’utiliser la suite de Fibonacci pour faire des estimations, non pas en cherchant à donner une valeur précise à des choses impossibles à évaluer (du genre le nombre de jours homme pour faire un projet), mais en procédant par comparaison. Et, c’est là que c’est vraiment intéressant, on compare des blocs correspondant à la suite de Fibonacci, donc avec un ratio organique et harmonieux, adapté à nos capacité cognitives.
Le principe est celui-ci : on identifie une tâche relativement simple, pas très longue à effectuer, sur laquelle il n’y a pas d’ambiguïté, et on lui attribue une valeur de 3. Si ce travail est fait par une équipe, tout le monde doit être d’accord sur le fait que la tâche est simple et sans ambiguïté. Dès que c’est fait, le reste est d’une facilité déconcertante. On prend chaque tâche suivante et on se pose la question : cette tâche est-elle comparable, plus petite ou plus grande que notre tâche étalon à 3 points ? Si elle est comparable, on lui donnera la note de 3, sans chipoter. Si elle est plus petite, on se demandera “un peu plus petite ou beaucoup plus petite ?” Si c’est “un peu plus petite”, on lui donnera la note de 2. Si c’est “beaucoup plus petite”, on lui donnera 1. Si elle est plus grande, on posera la même question : “un peu plus grande” ou “beaucoup plus grande” ? C’est c’est “un peu plus grande”, ce sera 5. Si c’est “beaucoup plus grande”, ce sera 8.
Et on s’arrête là. Si la tâche est beaucoup, beaucoup plus grande, on ne cherchera pas à deviner si c’est 13, 21, 34 ou plus. En faisant cela, on reviendrait au problème des grands nombre et nous ne savons pas le faire. On coupera la trop grande tâche en plusieurs tâches plus petites, correspondant à nos étalons de 1 à 8. C’est très rapide à faire, l’exercice est plutôt amusant et les résultats sont remarquables. On ne discute pas des nombres, on discute de la tâche. Est-elle claire, sans ambiguïtés ? Une fois la tâche clarifiée, sa notation Fibonacci coule de source. Ce qui est si beau, c’est aussi que lorsqu’on coupe un nombre de la suite de Fibonacci, on retrouve toujours deux nombres de la suite.
Jetez la moitié de vos Poker Planning !
Une pratique issue de Scrum consiste à utiliser des cartes de “Poker Planning”, avec des nombres correspondant à la suite de Fibonacci (1, 2, 3, 5, 8…).
Sauf que dans les paquets de Poker planning généralement utilisés, il y a plus de cartes que dans cette photo, vous y trouverez aussi les nombre 13, 21 et plus. On y trouvera même des nombres qui ne sont plus issus de la suite de Fibonacci, comme 20, 40, 80, 100 et même, j’ai déjà vu des cartes avec un symbole de l’infini !
Jetez ces cartes ! Pourquoi ? Parce que toute la magie des estimations réussies vient de l’utilisation de la suite de Fibonacci et du principe de comparaison construit sur cette suite organique. Dès que l’on essaye d’estimer 20, 40 ou 100, tout le bénéfice de l’exercice disparaît et on revient à la question impossible, d’estimer une trop grande quantité.
Alors si vous travaillez en Scrum et que vous faites des Sprint Planning fastidieux, changez de méthode, jetez les grandes cartes et revenez aux base de Fibonacci. Et bien sûr, ne cherchez jamais à calculer une moyenne si les équipiers ne sont pas d’accord sur le nombre de points à attribuer à une carte. Si ce cas se présente, il y a peut-être une ambiguïté dans la tache et elle doit être levée. Les points Fibonacci seront évident dès que la tâche sera éclaircie. Ne discutez jamais des points, mais prenez le temps de décortiquer la tâche. Les points viennent alors tous seuls. Et n’oubliez pas de diviser les tâches trop grandes, qui dépassent les 8 points.
Toutefois, le problème peut aussi venir de ce que différentes personnes imaginent l’effort qu’elles doivent produire pour exécuter la tâche et qu’un développeur expérimenté n’a pas la même appréciation qu’un débutant. En utilisant correctement le principe des comparaisons, ce problème est évacué. En effet, la question n’est pas quel effort telle ou telle personne doit accomplir, mais comment l’effort de cette tâche se compare-t-il avec la tâche étalon de 3 points. Ainsi, les évaluations ne sont plus dépendantes des personnes mais uniquement basées sur les tâches elles-mêmes.
Cela implique, évidemment, de raisonner en Fibonacci et pas en jours hommes. Dès que l’on parle de jours, heures, etc., on ramène le problème à une question de personnes et tout l’intérêt d’utiliser la suite de Fibonacci disparaît. Vous pouvez, parallèlement, calculer le ratio entre les points Fibonacci et des heures ou des jours hommes, mais seulement après avoir accumulé suffisamment de tâches et en oubliant ce ratio lorsque vous faites vos estimations.
Amusez-vous bien 🙂