Dans le développement de logiciels, l’« estimation » habituelle comprend une évaluation quantitative du travail requis pour effectuer une tâche de développement donnée ; ceci est généralement exprimé en termes de durée (heure / jour) ou d’unité estimée (story point). L’objectif est de consolider un certain nombre de ces estimations individuelles afin d’obtenir une indication de la durée, du travail ou du coût global du projet logiciel.
Les pièges courants de l’estimation agile
Même dans une communauté agile , les gens trouveront de nombreuses écoles de pensée différentes sur l’évaluation de la théorie et de la pratique. Cependant, certaines des erreurs typiques que les équipes agiles rencontrent souvent lorsqu’elles effectuent des évaluations agiles, ainsi que ces pièges courants, ont fait l’objet d’un large consensus :
- Les estimations doivent contenir des « incertitudes » ; Les estimations « (story) point » sont généralement considérées comme inadéquates parce qu’elles ne reflètent pas cette incertitude.
- L’estimation est différente de la promesse ; par exemple, accusant le promoteur d’avoir passé 3 jours, il/elle estime que la réalisation des travaux en 2 peut être une attitude contre-productive, conduisant généralement au résultat d’une surestimation future.
- L’estimation n’est pas la réponse finale, elle ne fait que refléter les informations contenues dans la communication ; doit toujours permettre à la valeur estimée d’être mise à jour vers le haut ou vers le bas en fonction de nouvelles informations.