Combien de temps faut-il pour faire ça ?

Tous les développeurs connaissent cette question favorite de leur chef de projet.
Aucun ne sait y répondre sans une crainte, et par avance un sentiment de culpabilité.
Et c’est normal.

En fait il y a deux questions en une

• « Faire Ça », ça veut dire quoi ?


• Et une fois que l’on sait, « comment l’estimer »

Personne ne sait estimer réellement une activité si elle n’est pas clairement définie.
Bien qu’une estimation reste par définition une valeur changeante, l’approche Agile fait (et non pas seulement veut) qu’elle soit le plus juste possible.

Une fois l’activité décomposée en tâches précisément définies, il est plus facile d’identifier la charge associée.
Développer une fonction, c’est une multitude de micro tâches (voir notion de « Done » en Agile) ; C’est écrire la spéc détaillée, la coder, côté serveur, côté client, écrire les tests unitaires, exécuter les tests unitaires, faire la peer review, l’intégrer, …
Sur chaque projet, une sorte de checklist peut aider les développeurs à identifier les tâches unitaires à produire pour développer une fonction. Elle permet de construire le backlog d’itération.

Une fois chaque tâche élémentaire défini, l’estimation de la charge en revient à :

Celui qui va la faire.

Pour être au plus juste des estimations, la logique veut (en Agile) que ce soit celui qui va la faire qui l’évalue en fonction de ses propres bases : expérience, compétence, assurance, connaissance …

Et celui qui va la faire , c'est la Scrum team

C’est ce principe Agile qui permet de responsabiliser dans le bon sens du terme chaque membre de l’équipe.

Voir l’article de Martin Fowler Programmers are Responsible Professionals