Bonjour ! Dans la leçon précédente, nous avons appris à décomposer un projet en morceaux plus petits et gérables, en utilisant soit le WBS pour une approche par livrables, soit les Epics et User Stories pour une approche orientée valeur utilisateur.
Maintenant que nous avons ces "briques" de travail, une question essentielle se pose : quelle est leur taille ? Ou, plus précisément, quel effort faudra-t-il pour les réaliser ? C'est le cœur de la leçon d'aujourd'hui. Répondre à cette question est indispensable pour toute forme de planification, de priorisation et de gestion des attentes.
Conformément à l'objectif de cette leçon, nous allons expliquer les principes de l'estimation de l'effort, en nous concentrant sur les deux grandes approches :
- L'estimation en temps (heures, jours), l'approche la plus traditionnelle.
- L'estimation en points de complexité (ou story points), l'approche privilégiée dans les méthodes Agiles comme Scrum.
Comprendre la différence fondamentale entre ces deux philosophies, et surtout pourquoi les équipes Agiles préfèrent les points, est une compétence clé pour tout futur Tech Lead ou chef de projet technique. En tant que développeur, vous avez probablement déjà été confronté à la fameuse question : "Alors, combien de temps ça va prendre ?". Aujourd'hui, nous allons vous donner un cadre pour répondre à cette question de manière plus robuste et collaborative.
1. L'estimation traditionnelle et ses limites : l'estimation en temps
La manière la plus intuitive d'estimer une tâche est de penser en unités de temps : "Cette tâche prendra 8 heures", "ce projet prendra 20 jours-homme". C'est ce qu'on appelle l'estimation absolue. Elle est simple à comprendre pour tout le monde, en particulier pour les interlocuteurs non techniques.
Cependant, cette approche présente des inconvénients majeurs dans le contexte du développement logiciel, un domaine par nature incertain et évolutif.
Pour bien comprendre les problèmes liés à l'estimation en temps, je vous propose de lire une section de l'excellent article d'Atlassian sur le sujet.
Que sont les story points dans Agile ? Comment les estimer ?
Cet article d'Atlassian, une référence dans le monde Agile, explique clairement pourquoi les équipes Agile se sont éloignées de l'estimation en heures. Concentrez-vous sur les raisons concrètes qui sont avancées.
Lisez la section intitulée "Story points et estimation horaire". Portez une attention particulière à la liste à puces qui détaille les raisons de préférer les story points aux estimations en temps.
Pour résumer et compléter cette lecture, voici les principaux défauts de l'estimation en temps :
- Elle ignore la réalité du travail : Une journée de 8 heures n'est jamais composée de 8 heures de code. Les réunions, les e-mails, l'aide à un collègue, les pauses... tout cela réduit le temps de développement "pur". Estimer en "jours idéaux" est une source constante de décalage avec la réalité.
- Elle est dépendante de l'individu : Un développeur senior et un junior ne mettront pas le même temps pour réaliser la même tâche. Si l'on estime en jours, doit-on le faire sur la base du senior ? Du junior ? D'une moyenne ? Cela crée des estimations qui ne sont pas stables si la composition de l'équipe change.
- Elle est chargée émotionnellement : Une date est un engagement. Si une tâche estimée à 3 jours en prend 5, cela peut être perçu comme un échec ou un manque de productivité, générant du stress et des discussions inutiles. On se focalise sur le respect du temps passé plutôt que sur la valeur livrée.
- Le cerveau humain est mauvais pour prévoir le futur : Nous sommes naturellement optimistes (biais d'optimisme) et nous avons tendance à sous-estimer la complexité et les imprévus.
Ces limites ont poussé les équipes Agiles à adopter une approche radicalement différente.
2. L'approche Agile : l'estimation relative en points de complexité
Plutôt que de se demander "Combien de temps ça va prendre ?", les équipes Agiles se demandent : "Quelle est la taille de cette tâche par rapport aux autres ?". C'est le principe de l'estimation relative.
L'unité de mesure pour cette taille relative est le point d'histoire (story point).
Qu'est-ce qu'un point d'histoire ?
Un point d'histoire est une unité abstraite qui représente l'effort global nécessaire pour réaliser une user story. Cet effort n'est pas seulement le temps de développement, mais un mélange de plusieurs facteurs.
Pour avoir une définition précise, je vous invite à regarder le début de cette vidéo.
Le Planning Poker et les ESTIMATIONS Agile - Scrum Life 24
La chaîne Scrum Life propose une excellente analogie pour comprendre les composantes d'un point d'histoire. L'acronyme présenté est très utile à mémoriser.
Regardez la vidéo de 00:00 à 01:25. Notez bien les différents éléments qui composent l'acronyme CURSE (ou CERP en français : Complexité, Effort, Risque, Périmètre).
Comme vous l'avez vu, un point d'histoire englobe :
- La Complexité : La difficulté intrinsèque de la tâche.
- L'Effort : La quantité de travail "brut" à fournir.
- Le Risque et l'Incertitude : Les inconnues techniques ou fonctionnelles. Une tâche utilisant une nouvelle technologie sera plus "chère" en points qu'une tâche similaire sur une technologie maîtrisée.
- Le Périmètre (Scope) : L'étendue de la tâche, le nombre de parties du code affectées.
Pourquoi utiliser une échelle non linéaire (Fibonacci) ?
Vous remarquerez que les cartes de Planning Poker (que nous verrons juste après) n'utilisent pas une suite linéaire (1, 2, 3, 4, 5...) mais souvent une suite de Fibonacci modifiée : 1, 2, 3, 5, 8, 13, 20, 40, 100.
Pourquoi ?
Parce que plus une tâche est grosse, plus l'incertitude qui l'entoure est grande. La différence d'effort entre une tâche à 1 point et une à 2 points est significative et nous pouvons la percevoir. En revanche, la différence entre une tâche à 20 points et une à 21 points est négligeable et relève de la fausse précision. L'écart grandissant entre les nombres (de 8 on passe à 13, pas à 9) nous force à faire des choix et à reconnaître cette incertitude. Une tâche estimée à 20, 40 ou 100 est de toute façon trop grosse et devra être redécoupée.
Le guide "Du Meilleur Scrum" synthétise très bien ces concepts.
Ce guide est une référence écrite par des praticiens Agiles. La section sur l'estimation résume les concepts clés que nous venons de voir.
Lisez la section 5 "Dimensionner les éléments du Carnet de Produit", et plus particulièrement le paragraphe commençant par "Reprenons quelques concepts clés de l'estimation agile".
3. Comment estimer en pratique : le Planning Poker
Maintenant que nous avons compris le "quoi" (les points) et le "pourquoi" (l'estimation relative), voyons le "comment". La technique la plus répandue et la plus efficace pour estimer en points est le Planning Poker. C'est un "jeu" collaboratif qui a pour but de créer une conversation et d'arriver à un consensus.
La vidéo de Scrum Life que nous avons commencée plus tôt explique parfaitement le déroulement de cet atelier.
Le Planning Poker et les ESTIMATIONS Agile - Scrum Life 24
Regardons la suite de la vidéo sur le Planning Poker. Elle détaille le processus étape par étape, les rôles de chacun, et les points de vigilance. C'est exactement ce que vous animerez ou à quoi vous participerez en tant que Tech Lead ou Scrum Master.
Regardez attentivement la section de 05:48 à 09:07 pour le déroulement d'une session. Puis, la section de 10:21 à 10:57 sur un point crucial : qui doit estimer.
Le processus du Planning Poker se déroule comme suit :
- Présentation : Le Product Owner présente une User Story, explique le besoin métier, le "pourquoi".
- Clarification : L'équipe de développement pose des questions pour s'assurer d'avoir bien compris le besoin fonctionnel. À ce stade, on évite de parler de la solution technique.
- Vote individuel : Chaque membre de l'équipe de développement choisit secrètement la carte qui correspond à son estimation.
- Révélation : Tout le monde montre sa carte en même temps.
- Convergence :
- Consensus : Si tout le monde a voté la même valeur (ou des valeurs très proches, ex: 3 et 5), on retient la valeur la plus haute ou on discute très brièvement pour se mettre d'accord, et on passe à la story suivante.
- Divergence : Si les votes sont très écartés (ex: un 2, un 5 et un 13), on ouvre la discussion.
- Discussion : On demande aux personnes qui ont mis la note la plus basse et la plus haute d'expliquer leur raisonnement. C'est le moment le plus important : les développeurs partagent leur vision de la solution technique, les testeurs évoquent les risques, etc. Cela permet de partager la connaissance et de découvrir des aspects que d'autres n'avaient pas vus.
- Re-vote : Après une courte discussion (time-boxée à 1 ou 2 minutes), on vote à nouveau. On répète le processus jusqu'à ce que l'équipe converge vers une estimation commune.
Un point crucial : seuls ceux qui font le travail (l'équipe de développement : développeurs, testeurs, ops...) votent. Ni le Product Owner, ni le Scrum Master, ni un manager externe ne participent au vote. Leur avis peut être sollicité, mais l'estimation reste la propriété de l'équipe.
Testez votre compréhension !
Pendant une session de Planning Poker, pour une nouvelle User Story, un développeur junior vote 3, un développeur senior vote 8, et un testeur vote 13.En tant que Scrum Master (ou Tech Lead facilitateur), que faites-vous ?
Show answer
C'est un cas typique de divergence. L'action à entreprendre est de faciliter la discussion.
- Je ne calcule pas de moyenne et je n'impose pas de valeur.
- Je demande au développeur junior (qui a voté le plus bas) d'expliquer pourquoi il pense que la tâche est relativement simple (vote 3). Il a peut-être vu une solution simple à laquelle les autres n'ont pas pensé.
- Ensuite, je demande au testeur (qui a voté le plus haut) d'expliquer pourquoi il perçoit beaucoup de complexité ou de risque (vote 13). Il a peut-être identifié de nombreux cas de tests complexes, des impacts sur d'autres parties de l'application (tests de non-régression) ou une incertitude sur la manière de tester.
- Le développeur senior peut aussi expliquer son vote intermédiaire de 8.
- Après une brève discussion (que je timeboxe), je demande à l'équipe de revoter. Les nouvelles informations partagées devraient les aider à converger.
Conclusion : À quoi servent ces estimations ?
Vous vous demandez peut-être à quoi servent ces points abstraits si on ne peut pas les traduire directement en jours. Ils sont le fondement de la planification prédictive en Agile.
En suivant le nombre de points que l'équipe réussit à terminer à chaque Sprint, on obtient une mesure appelée la vélocité. Par exemple, une équipe peut constater qu'elle réalise en moyenne entre 20 et 25 points par Sprint.
Cette vélocité, une fois stabilisée, devient un outil de prévision extraordinairement puissant. Si le Product Backlog contient 200 points de fonctionnalités priorisées, le Product Owner peut prévoir qu'il faudra probablement entre 8 (200/25) et 10 (200/20) Sprints pour tout réaliser. Cela permet de donner de la visibilité aux parties prenantes sans faire de promesses basées sur des estimations en jours peu fiables.
Les points clés à retenir :
- L'estimation en temps est absolue, simple à comprendre mais fragile et source de biais.
- L'estimation en points de complexité est relative, plus robuste car elle prend en compte l'effort global (complexité, risque, incertitude) et est indépendante des individus.
- L'échelle Fibonacci (1, 2, 3, 5, 8...) est utilisée pour refléter l'incertitude croissante des tâches plus grosses.
- Le Planning Poker est un atelier collaboratif pour estimer en équipe, favorisant le partage de connaissance et l'appropriation collective.
- Les points, combinés à la vélocité, permettent d'établir des prévisions de livraison fiables.
Et après ?
Maintenant que nous savons découper le travail et l'estimer, il nous faut l'organiser dans le temps. Même en Agile, l'ordre dans lequel on fait les choses a de l'importance. Dans la prochaine leçon, nous aborderons la gestion des dépendances et l'importance du chemin critique dans un planning, des concepts utiles que vous travailliez en mode prédictif ou adaptatif.