Estimation agile

Je n'ai jamais été un fan des techniques d'estimation des coûts classiques (CoCoMo), ni d'ailleurs des estimations en général. Estimer le nombre de lignes de code ou le temps qu'on va passer sur une tâche qui se déroulera (peut-être) dans plusieurs mois, c'est le plus souvent du temps perdu. De plus c'est trop souvent perçu comme un engagement plutôt qu'une hypothèse à réévaluer.

En revanche je suis un grand supporter de l'estimation agile par les "story points". J'ai découvert cette technique dans le livre de Mike Cohn, Agile Estimating and Planning. Depuis, je l'ai utilisée et fait pratiquer sur 3 projets et j'en suis très satisfait. Bien sûr, elle nécessite d'avoir au préalable une liste de "user stories".
Elle demande aussi de l'accompagnement auprès des équipes lors des séances d'estimation (collective) pour choisir la meilleure façon de procéder et lever les inhibitions au démarrage. Elle donne alors des résultats spectaculaires. Les équipes s'habituent vite à estimer de façon relative, ce qui limite les ré-estimations. On arrive facilement à calculer la vélocité (le nombre de points gagnés par itération). On obtient la mesure de l'avancement du projet (le nombre de points restant à faire). Le management a une excellente visibilité grâce à un graphe de tendance (qui s'appelle dans Scrum le Burndown Chart), comme celui-ci, obtenu sur un projet client que je coache, qui est remis à jour après chaque itération :

rbcsmall.jpg Avec une simple règle de 3, on peut savoir combien d'itérations sont nécessaires pour finir le projet.

Commentaires

1. Le lundi 24 avril 2006, 17:35 par Freddy Mallet

Je n'ai jamais travaillé avec des points. Je me dis qu'au bout d'un moment implicitement dans l'esprit de l'équipe 1 point équivaut à une charge temporelle du style 1 journée ou 1/2 journée et que ça revient finalement à travailler en jour idéal. Au vue de ton expérience Claude, qu'en est-il sur le long terme ?

2. Le lundi 24 avril 2006, 18:28 par claude aubry

En fait non. C'est seulement la première fois que l'équipe a tendance à estimer en jours. Pour lancer le travail d'estimation en équipe, je prends en général une user story déjà réalisée (développement partant d'un existant) ou alors bien connue (si développement nouveau) de taille moyenne et je la fixe arbitrairement à 2 ou 3 points. Après on procède par comparaison et on oublie vite les jours.

D'ailleurs je viens de faire le calcul -a posteriori- pour un projet que je coache : un point a nécessité en moyenne 2,5 jours de travail. Sur un autre, c'est plutôt autour de 1,5.

En revanche, il est préférable de disposer des estimations avant la revue de planification de début de sprint. Sinon pour les user stories sélectionnées dans le sprint courant, l'équipe fait à une heure d'intervalle l'estimation (en points), puis l'estimation en heures des tâches associées à la story et là, ça pertube.

3. Le mardi 25 avril 2006, 11:49 par gianfranco

Bonjour,
Nouveau dans le monde de l'agilite, je n'ai jamais travaille ni avec les ideal days ni avec les story points mais je dois avouer qu'instinctivement j'adopterais volontier la version Story Point - Velocity plutot que la version Ideal Days - Load Factor. J'aime bien l'idee que l'estimation temporelle soit derivee et non pas un point de depart. Comment faites-vous en general, partez-vous d'une Story evaluee a X points puis les autres en decoule? ou bien par example commencez-vous par une premiere categorisation des user stories, chaque categorie ayant une representante d'apres laquelle les autres dans la meme categories seront evaluees? Il me semble difficile d'evaluer l'ensemble sur la base d'une seule representante mediane. Je pense que c'est vraiment une question de feeling de l'equipe et qu'avec la technique des iterations frequentes les deux techniques devraient donner des resultats similaires.
Je travaille actuellement dans une societe russe a St Petersbourg ou il utilisent la version ideal days et disent en etre satisfait.

4. Le mardi 25 avril 2006, 17:18 par claude aubry

Comme c'est une estimation relative, le nombre de points donnés à une user story n'a pas d'importance. La seule chose qui compte, c'est qu'une user story qui vaut 2 points doit apparaître 2 fois plus longue à réaliser qu'une user story à 1 point.

J'utilise comme liste de points possibles la suite de Fibonacci: 1, 2, 3, 5, 8 et 13. La toute première fois il suffit donc d'avoir à l'esprit ce domaine de variation.