Dans la gestion et le développement de projets agiles, on n'estime pas les User Stories en méthode d'évaluation traditionnelle en "Jour homme", mais plutôt il est recommandé l'utilisation des "Points de complexité ou ce qu'on appelle "Point d'Histoire" basée sur la suite numérique de "Fibonacci", car les développeurs estiment généralement la difficulté et le complexité de mettre en oeuvre une histoire d'utilisateur donnée et pas le temps nécessaire. Il s'agit d'une mesure de l'effort requis que l'équipe va fournir pour réaliser et mettre en place la demande.
On peut déduire tout simplement que l'estimation en point d'histoire est une valeur numérique permettant d'indiquer à l'équipe de développement le niveau de difficulté de cette "User Story", et pas le nombre de jours nécessaires pour finaliser la réalisation.
De point de vue développement et réalisation, la définition d'un point de complexité est étroitement liée à plusieurs facteurs, en occurrence :
L'effort à fournir par l'équipe de développement lors de la réalisation.
La difficulté de la demande (facile, moyenne, difficile, ou très difficile).
L'ensemble des risques potentiels (Blocage, stabilité des environnements, fréquence de changement du besoin, ...Etc.).
L'incertitude (Nouveau algorithme à utiliser, nouvelle solution technique, ...Etc.).
La notion des dépendances internes et externes (fonctionnelles et techniques).
L'équipe de développement peut identifier et estimer une demande de référence qui sera la demande du "Product Backlog" la plus simple à réaliser, en lui affectant la valeur 1. Du coup on aura une estimation relative utilisée comme référence lors de l’estimation des autres demandes du Product Backlog, Comme ça et avec l'expérience, l'équipe peut construire au fur et à mesure ce qu'on appelle un "Catalogue de Référence" contenant une User Story par complexité.
Le choix de l'utilisation de la suite numérique de Fibonacci (0 1 1 2 3 5 8 13 21 34 55 89) plutôt qu'une autre suite numérique s'explique tout simplement par le fait que sa croissance exponentielle illustre et explique bien le lien entre la complexité et l'incertitude d'une demande, en plus par ce que tant que les estimations sont hautes, tant qu'elles sont imprécises, c'est à dire que par exemple si une demande est de complexité 13 alors ça sera la même chose que pour une autre de complexité 14, vu que les développeurs ne peuvent pas identifier la différence en détail entre 13 et 14, par contre ils peuvent expliquer clairement et facilement la différence entre deux demandes de complexités 1 et 2.
Dans un projet agile en Scrum, il est fortement recommandé de limiter les valeurs de la suite Fibonacci à utiliser lors des estimation, par exemple 8 ou 13, comme ça dès qu'une demande dépasse la valeur maximale on va penser automatiquement à un découpage, et du coup toutes les "User Stories" à embarquer dans les sprints auront des valeurs entre "1 et 8" ou "1 et 13" selon le choix fait.
Conclusion :
Toute équipe de développent en agile a le droit de choisir la suite numérique à utiliser lors des estimations, que ça soit la suite de "Fibonacci" ou autre, l'essentiel c'est d'avoir la possibilité de donner des valeurs correctes et crédibles.
Le "Planning Poker" reste parmi les meilleur outils d'estimation des "User Stories", vu qu'il présente l'avantage d'avoir des estimations personnelles d'une manière collaborative sans aucune influence et impact, ainsi que tout le monde va participer lors de cette cérémonie.
Comments