L'estimation des projets de développement logiciel n'est pas une mince affaire. Une approche traditionnelle de type « cascade » implique un long travail de recueil des besoins, qui aboutit à une documentation complexe et à un plan de projet comprenant des estimations en heures et en euros. Aujourd’hui, les méthodologies de développement agiles sont largement devenues la norme, leur principal avantage étant de permettre d’évaluer rapidement la durée nécessaire à la réalisation d’un projet et son coût estimatif.
Chez Randstad Digital, nous préconisons d’établir rapidement une liste de fonctionnalités de haut niveau et d’utiliser l’estimation relative en points d’histoire pour évaluer plus précisément les coûts et le niveau d’effort
Qu’est-ce que l’estimation relative en points d’histoire ?
L’estimation relative en points de story utilise un « nombre sans unité » pour estimer les user stories en regroupant les exigences en fonction d’une difficulté équivalente. En termes simples, il s’agit d’une manière de classer les user stories les unes par rapport aux autres. Un point d’histoire est une mesure arbitraire de l’effort nécessaire à la mise en œuvre d’une histoire utilisateur ; c’est un chiffre qui indique à l’équipe le degré de difficulté de l’histoire. La « difficulté » peut être liée à la complexité, aux inconnues et/ou à l’effort requis. Dans la plupart des cas, un story point utilise l’une des échelles suivantes :
- 1, 2, 4, 8, 16
- X-Small, Small, Medium, Large, Extra-Large (système dit « T-Shirt Sizing »)
- Séquence de Fibonacci : 1, 2, 3, 5, 8, 13, 21
Comme les points d’histoire ne correspondent pas à un nombre d’heures réel, cela permet aux équipes Scrum d’envisager de manière plus abstraite l’effort nécessaire à la réalisation d’une histoire.
Voici comment cela fonctionne :
Étape 1 : Créer un backlog produit.
Le backlog produit est l’endroit où sont stockées les exigences d’un projet Agile sous la forme d’histoires utilisateur. Les histoires utilisateur doivent être des épopées et contenir les fonctionnalités de haut niveau du système.
Étape 2 : Déterminez l’échelle.
On utilise généralement les nombres de la suite de Fibonacci, tels que 1, 2, 3, 5, 8, 13 et 21, pour exprimer un niveau d’effort.
Étape 3 : Estimer le backlog.
Répertoriez les éléments qui ne nécessitent pas de réflexion approfondie dès le départ ; cela permettra d’obtenir une estimation approximative de l’étendue du backlog.
Étape 4 : Établir des estimations pour la planification des versions.
Déterminez la vélocité de l’équipe (en supposant que vous ayez accès à des données historiques) et les dates de livraison approximatives.
Étape 5 : Précisez les choses en attribuant, en équipe, des points aux stories pour le développement, les tests et l’élaboration.
Le Planning Poker est une méthode simple et collaborative permettant d’évaluer la taille de votre backlog en équipe.
Étape 6 : Établir les estimations pour la planification de sprint.
Il s’agit des éléments dont nous avons discuté et que nous avons décomposés en détail en groupe ; cela fait partie de la planification de sprint. C’est à ce stade que les tâches peuvent être planifiées en termes d’heures et de sprints, puisque nous disposons désormais de plus de détails.
L’estimation relative en points d’histoire offre les avantages suivants :
C’est rapide.
L’objectif de l’estimation en points de story n’est pas de déterminer un niveau d’effort exact, car il y a trop d’incertitudes et pas assez de temps. L’objectif est plutôt d’estimer rapidement un niveau d’effort, et vous pouvez le faire bien plus vite qu’avec les approches d’estimation traditionnelles.
Elle est plus précise.
Planifier chaque sprint en termes d’heures ou de dollars nécessaires à sa réalisation peut être une méthode précise, mais si vous prenez ne serait-ce qu’un léger retard, la portée de l’ensemble de votre projet peut s’en trouver bouleversée. C’est ce que l’on appelle le « cône d’incertitude ». En organisant le backlog, vous redimensionnez et élaborez des estimations rapides de l’effort de manière agile. Lorsque le travail commence, vous pouvez fournir une estimation plus détaillée, réduisant ainsi le cône d’incertitude. Les classifications approximatives de l’estimation relative par points de story constituent un moyen plus précis et plus flexible de déterminer les priorités et le calendrier.
Cela s’améliore avec le temps.
Au fil du temps, vous pouvez observer le nombre de points que votre équipe réalise généralement au cours d’un sprint, et vous améliorer de plus en plus dans l’estimation relative. Cette vision de la vélocité permet d’évaluer l’effort de l’équipe de développement au fil du temps, de déterminer quelle est habituellement votre capacité de sprint, et constitue un bon outil pour prévoir les estimations futures.
C’est spécifique au projet.
Il est pratiquement impossible de prédire le nombre exact d’heures nécessaires pour une story donnée, car les heures sont des chiffres relatifs. La généralisation à quelques chiffres significatifs vous permet d’obtenir une « vue d’ensemble » plus précise de la vélocité, liée au projet spécifique en cours.
Le développement logiciel est caractérisé par un haut niveau de complexité et d’incertitudes. Bien qu’il n’existe pas de méthode parfaite pour estimer le temps nécessaire à la réalisation d’une fonctionnalité particulière, nos équipes agiles chez Randstad Digital ont constaté que l’estimation relative offre de nombreux avantages grâce à un processus de développement agile simple et élégant.
Prêt à optimiser votre processus de développement agile grâce à l’estimation relative en points d’histoire ? Découvrez comment Randstad Digital peut vous aider à rationaliser vos projets.