Estimation agile : Estimations relatives vs Estimations absolues

Précision de l’estimation de groupe par rapport à l’estimation individuelle

Que l’équipe travaille sur un produit ou sur un projet, nous devons répondre à la question « Quand aurons-nous terminé ? » Ou jusqu’où nous pouvons aller à un moment donné. Tout comme le développement traditionnel, nous devons estimer l’effort avant de démarrer le projet.

Qu’est-ce que l’estimation de projet ?

Une  estimation  est un calcul approximatif de quelque chose. Par exemple, l’estimation des coûts du projet est un concept général du modèle de prix du projet. Il vous aide à fournir un chiffre, espérons-le, plus réaliste lorsque vos clients ou d’autres parties prenantes du projet vous demandent d’évaluer le coût et le temps du projet.

Estimation agile vs traditionnelle

Traditionnellement, nous allouons du temps pour estimer les projets logiciels, alors que dans  les méthodes agiles , ils préfèrent fournir un point d’histoire pour un élément du backlog comme mesure du travail relatif. Cela permet à l’équipe de considérer d’autres travaux qu’ils ont effectués dans le passé et de les comparer avec le carnet de produit qu’ils estimeront. Les points d’histoire ne sont pas mesurés en donnant un temps absolu, mais en estimant la charge de travail nécessaire pour résoudre des tâches similaires en fonction de l’expérience passée.

L’ estimation agile  a les trois caractéristiques suivantes :

  1. Estimation collective d’équipe
  2. Estimation de l’effort relatif par rapport au temps absolu
  3. Estimer la vélocité de l’équipe

1. Estimation collective

Lors du développement de  Scrum , l’équipe a partagé la responsabilité et s’est engagée collectivement dans le travail de chaque  Sprint , de sorte que la charge de travail estimée pour l’équipe agile a utilisé une approche d’estimation collective. Les estimations collectives utilisent généralement le Planning poker comme outil, l’équipe fait une estimation collective en jouant à un jeu d’estimation. Le planning poker  est considéré comme la technique la plus efficace et la plus intéressante pour estimer la charge de travail en  Agile . Il se compose d’un ensemble de nombres similaires aux nombres de Fibonacci, y compris : 0, 0,5, 1, 2, 3, 5, 8, 20, 40, ?, ∞, chaque jeu de cartes de poker a 4 groupes de tels nombres de Fibonacci pour servir pour 4 personnes.

La précision de l’estimation de groupe par rapport à l’estimation individuelle

Selon une étude sur la précision de l’estimation de l’effort entre l’individu et le groupe dans une expérience pour un projet logiciel. 20 professionnels du logiciel de la même entreprise ont estimé individuellement l’effort de travail requis pour mettre en œuvre le même projet de développement logiciel. Les participants avaient des antécédents et des  rôles différents  et le projet de logiciel avait déjà été mis en œuvre. Après cela, ils ont formé cinq groupes. Chaque groupe s’est mis d’accord sur une estimation en discutant et en combinant les connaissances entre eux.

Résultat — Les estimations basées sur les discussions de groupe étaient plus précises que les estimations individuelles.

Étapes pour organiser un Planning Poker

  1. Chaque membre de l’équipe reçoit un jeu de cartes, comprenant 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞, un total de 12 cartes.
  2. Le  propriétaire du produit  lira soit la description d’une fonctionnalité à l’équipe.
  3. Les  membres de l’équipe  discutent de la fonctionnalité et posent des questions au propriétaire du produit si nécessaire.
  4. Lorsque les membres ont terminé leur discussion, chaque membre sélectionne une carte de poker pour représenter l’estimation. Les cartes sont ensuite révélées simultanément.
  5. Si l’équipe évalue différentes estimations. Sommes-nous d’accord ? Avons-nous des différences ? Y a-t-il quelque chose que je n’ai pas considéré? Ceux qui ont choisi la valeur la plus élevée ou la plus basse doivent partager leur raisonnement avec le groupe avant que chaque membre ne sélectionne une autre carte de poker.
  6. Après la discussion, vous pouvez estimer un autre tour et l’équipe doit parvenir à un accord.
  7. Revenez à la deuxième étape et commencez à estimer l’entrée suivante.

2. Effort relatif vs estimation du temps absolu

Une estimation n’est rien de plus qu’une supposition bien éduquée. Nous utilisons toutes les connaissances et l’expérience à portée de main pour faire une estimation du temps que cela va prendre. Ainsi, au lieu de regarder chaque nouvel élément de travail séparément, pourquoi ne pas le comparer à des éléments de travail déjà terminés ? Il est plus facile pour les humains de se rapporter à des objets similaires que de deviner la taille réelle des choses de toute façon.

Par exemple, est-ce plus proche de cette toute petite chose ? Ou est-ce plutôt cet article de taille normale ? Ou est-ce vraiment énorme comme ce travail que nous avons terminé le mois dernier ? Faire des estimations relatives réduira non seulement le temps passé à estimer le travail, mais augmentera également considérablement la précision des estimations.

Notre cerveau n’est pas capable de faire des estimations absolues ; nous mettons toujours cette nouvelle chose que nous devons estimer en relation avec des choses que nous connaissons déjà.

3. Estimer la vélocité — Enregistrez et faites la moyenne de la vitesse de l’équipe de chaque sprint

La  vélocité de l’équipe  est le nombre de  points d’histoire  que l’  équipe Scrum  complète réellement dans un Sprint. La vélocité de l’équipe vous indique à quelle vitesse l’équipe va. Un projet ou une équipe nouvellement estimée (sans référencer les enregistrements de vitesse dans le passé), nous pouvons faire 1  à 2 Sprint  pour mesurer une vitesse comme vitesse initiale. Dans le processus de mise en œuvre de Sprint, nous devons enregistrer la vitesse de chaque Sprint, pour les plans futurs.

Nous estimons le nombre total de  points d’histoire  pour le  backlog du produit , puis nous connaissons la vitesse moyenne de chaque sprint, puis nous pouvons déterminer le nombre de sprints dont nous avons besoin pour terminer, et donc le sprint devrait être requis pour le projet comme montré dans la figure ci-dessous.


Leave a Reply

Votre adresse e-mail ne sera pas publiée.