Estimer la durée d’un projet ou la durée d’un artefact de développement, qu’il s’appelle histoire, composant, fonctionnalité ou autrement, voila un exercice bien difficile ! Longtemps confiné au rôle de chef de projet, l’agilité a délégué ce rôle à l’équipe. Et bien oui, qui mieux que l’équipe est à même d’estimer une tâche puisque c’est elle-même qui va la réaliser ? Oui, mais voila. L’équipe ne sait pas bien le faire. Et en se retournant vers le chef de projet, elle découvre que ce n’est pas mieux pour lui, hormis avec la technique du doigt mouillé, c’est à dire un chiffrage basé sur le sens du vent au moment même du chiffrage. Un moyen comme un autre…

Estimer, c’est aussi compliqué car le quoi à réaliser est plus ou moins vaste selon les points de vues. Le chef de projet est celui qui verra la version la plus simple du besoin alors que le responsable de la sécurité y verra une charge énorme, les développeurs se positionnant souvent un peu entre les deux, à savoir entre un mois et un an, à peu près…

A tel point qu’il existe même un mouvement de pensée pour la suppression totale des estimations. Selon eux, estimer est une perte de temps pour aboutir à un résultat de toutes manières aléatoire. Ils ont raison à un certain point. De mon humble avis, la seule estimation possible est comparativement à une autre situation similaire : avec une équipe à peu près équivalente et une fonctionnalité à peu près semblable.

Pour les personnes qui ne comprennent pas pourquoi estimer est aussi compliqué, je vous propose de lire un article de Michael Dubakov, malheureusement uniquement en anglais, expliquant toute la problématique de cette complexité. A lire avec attention, même si vous n’allez pas jusqu’au bout…