Dans ce chapitre, nous examinerons quelques-unes des unités de mesure les plus utilisées par les équipes qui utilisent l’estimation relative :
Temps idéale
Story points
Taille de T-shirt
NUTs (Nebulous Units of Time)
Ces unités de mesure sont souvent utilisées pour les récits utilisateur (user story ? ).
L’une des erreurs courantes lorsqu’on décompose des fonctionnalités en tâches pour estimer leur durée est que cette approche repose sur de nombreuses hypothèses.
L’une des principales hypothèses est que, puisque l’équipe technique travaille 40 heures par semaine, il est possible d’attribuer 40 heures de tâches de développement à chaque membre.
Cependant, voici quelques éléments qui peuvent survenir dans une journée typique d’un développeur :
Il participe à des réunions.
Un collègue développeur lui demande de l’aide.
Il prend une pause déjeuner.
Des collaborateurs du service business lui posent des questions, ce qui lui prend 15 minutes pour y répondre.
Il prend quelques pauses aux toilettes.
Il doit enquêter sur un bogue étrange apparu sur le site en production.
Dans une section précédente, nous avons estimé le temps nécessaire pour lire un livre en évaluant d’abord sa taille, puis la durée de lecture. Le concept de temps idéal permet de faire exactement cela.
Estimer une tâche en utilisant des jours nécessite un calcul complémentaire pour déterminer le nombre réel de jours calendaires nécessaires à la livraison d’une fonctionnalité à une date précise.
L’un des principaux avantages du concept de temps idéal ou de jours est sa simplicité. Si vous expliquez à une partie prenante que les développeurs passent quatre heures par jour à coder, et les quatre autres heures à planifier, assister à des réunions, déjeuner, prendre des pauses, répondre aux questions, etc., cela rend les estimations plus compréhensibles pour eux.
Story points
Si vous utilisez le cadre de gestion de projet Agile appelé Scrum, l’estimation se fait en story points . Ces points sont attribués à chaque fonctionnalité lors d’une session d’estimation.
Les story points simplifient généralement la suite de Fibonacci en allant jusqu’à 21, puis en incluant le nombre 100 comme valeur maximale.
Bien que 100 ne fasse pas partie de la suite de Fibonacci, ce nombre est utilisé pour indiquer qu’une fonctionnalité est trop grande pour être estimée et qu’elle doit être décomposée.
Les story points donnent une idée de la complexité de la fonctionnalité (sa taille), mais pas du temps qu’il faudra pour la réaliser.
Exemples :
Imaginez une équipe Scrum travaillant sur une nouvelle application e-commerce. Lors d’une réunion de planification de sprint, elle attribue les estimations suivantes :
Histoire d’utilisateur A : En tant qu’utilisateur, je veux créer un compte pour effectuer des achats. (Estimé à 5 story points).
Histoire d’utilisateur B : En tant qu’utilisateur, je veux rechercher des produits par leur nom. (Estimé à 3 story points).
Histoire d’utilisateur C : En tant qu’utilisateur, je veux ajouter des articles à mon panier. (Estimé à 8 story points).
Ces estimations sont basées sur des facteurs tels que :
La complexité des tâches.
La quantité de travail nécessaire.
La compréhension des exigences par l’équipe.
Si l’équipe peut accomplir environ 16 story points par sprint, elle pourrait inclure les histoires d’utilisateur A et B dans le sprint à venir, leur total étant de 8 points, ce qui laisse de la place pour du travail supplémentaire ou pour gérer des imprévus. L’histoire d’utilisateur C pourrait être planifiée pour un sprint ultérieur, car l’inclure dépasserait la quantité typique de points que l’équipe peut gérer par sprint.
En utilisant les story points, l’équipe peut prendre des décisions plus éclairées sur ce qu’elle peut réaliser pendant un sprint et mieux gérer sa charge de travail.
Autre exemple, la première tâche consiste à modifier une ligne de code, tandis que la dernière implique de migrer une base de données entière, ce qui représente des heures de travail et des centaines de lignes de code.
La différence entre deux récits utilisateurs n’est pas une simple multiplication par 13 de la complexité, mais une évaluation relative de leur complexité. Par exemple, migrer une base de données représente beaucoup plus de travail que le récit utilisateur consistant à modifier une seule ligne de code.
💡 L’estimation par story points est la méthode privilégiée par la plupart des équipes Scrum.
Elle offre plusieurs avantages, tels que :
Estimation relative : Les points d’histoire permettent une estimation relative plutôt qu’absolue. Autrement dit, les équipes estiment la taille d’une tâche en la comparant à d’autres tâches, sans utiliser d’unités de temps comme des heures ou des jours. Cette approche est généralement plus fiable, car il est plus facile pour les humains de comparer des éléments que de prédire des valeurs absolues.
Se concentrer sur la complexité et l’effort : L’utilisation des points d’histoire permet aux équipes de prendre en compte plusieurs facteurs : la complexité, les zones d’ombre, ainsi que l’effort requis. Cette vision d’ensemble conduit souvent à des estimations plus réalistes que si l’on considérait uniquement le temps nécessaire.
Un consensus d’équipe et plus de collaboration : L’attribution des points d’histoire se fait en général avec la participation de toute l’équipe. Cela encourage les échanges et la recherche d’un consensus, ce qui permet une meilleure compréhension des tâches et un effort collectif plus cohérent.
Le dimensionnement T-shirt consiste à attribuer une taille de T-shirt à chaque fonctionnalité :
S : Petit
M : Moyen
L : Grand
XL : Très grand
XXL : Très très grand
💡 L’un des avantages majeurs de cette méthode est sa simplicité. Presque tout le monde peut déterminer si une tâche semble petite, moyenne ou grande. (Cela peut même vous rappeler l’exemple des tasses de café vu plus tôt dans le cours.)
Cependant, qualifier une fonctionnalité de "moyenne" ne vous indique pas combien de jours seront nécessaires pour la compléter. Cette question sera examinée dans un exercice distinct utilisant les récits utilisateur et les story points pour affiner l’estimation.
Les NUTs sont une abréviation pour des unités de temps fictives. C’est une autre appellation pour une unité de mesure relative.
Le terme "NUT" met l’accent sur le caractère arbitraire et "fabriqué" de cette unité de temps. Il s’agit d’une unité clairement artificielle et non d’une mesure réelle de temps.
Lorsque vous utilisez l’estimation relative, évitez d’estimer en jours. Préférez des unités abstraites.
💡 Les unités populaires pour l’estimation relative incluent :
Temps idéal
story points
Tailles de T-shirt
NUTs
Si vous utilisez le cadre de gestion Agile Scrum, l’estimation se fera en story points.
Un article intéressant sur l’utilisation des story points dans le développement Agile.
Vous vous demandez comment organiser un atelier de Planning Poker ? Découvrez tout cela dans le prochain chapitre !