Pas de relevé du temps passé sur les tâches

Le temps qui passe ne se rattrape pas

Dans un commentaire récent, Rémy me dit à propos du relevé des heures sur les tâches :

Cela est utile pour le burdown chart (cf. greenhopper par exemple, www.greenpeppersoftware.c... ) et nécessaire dans la gestion de projets pour pouvoir imputer dans les outils de gestion d'entreprise.

Il dit plus loin :

cela est aussi utile pour identifier rapidement des problèmes (estimation erronée et/ou le développeur ne s'en sort pas) et donc de trouver des solutions au plus vite.

C'est un sujet qui revient régulièrement, je l'ai déjà abordé, comme dans ce billet Pas de relevé des heures avec Scrum.

Ce dont il est question, ce sont les tâches d'un sprint. Pour une équipe de taille moyenne, il peut y avoir environ une cinquantaine de tâches dans un sprint. Pour chaque tâche, Scrum demande d'estimer le reste à faire, éventuellement actualisé quotidiennement. Le burndown chart de sprint est simplement une courbe montrant l'évolution du total de cette valeur pour toutes les tâches.

Dans son commentaire, Rémy suggère qu'on peut aussi avoir en plus le temps déjà passé sur la tâche. Implicitement son commentaire implique aussi d'avoir une troisième valeur associée à chaque tâche : son estimation (de reste à faire) initiale. Pour une tâche T au jour j du sprint, on aurait, par exemple, estimation initiale 10h, temps passé 6h, reste à faire 5h. Et cela pour toutes les tâches.

Pour les projets que j'ai suivis, collecter ces 3 valeurs, pour chaque tâche, puis les analyser aurait représenté une perte de temps. Et j'ai des doutes sur les bénéfices que cela aurait pu apporter :

  • on n'en a pas besoin pour produire un burndown chart de sprint
  • quel intérêt de se rendre compte que le temps passé sur une tâche ne correspond pas à l'estimation initiale ? Qu'on a estimé à 10h et qu'on va peut-être y passer 11h ? Je n'y vois que de la perte de temps à se poser la question.

Reste le dernier argument : c'est nécessaire d'imputer le temps passé pour le contrôle de gestion. Bien sûr c'est important par exemple pour connaître le budget consommé, mais pour cela il n'est pas nécessaire de compter le temps passé à un niveau aussi fin que celui des tâches. Il suffit de relever, comme d'habitude, le temps passé sur le projet pour chaque personne. D'ailleurs faire le total des heures passées sur les tâches du sprint ne donnerait pas le total du temps passé sur le projet, puisque les réunions ne figurent pas dans les tâches du sprint.

Commentaires

1. Le lundi 09 juin 2008, 08:44 par David

Concernant ton dernier argument pour compter le temps passé sur un projet : Malheureusement, de nombreux développeurs sont dans des sociétés qui pensent que travailler sur plusieurs projets en // est plus productif. Il leur faut alors compter le temps passé sur chaque tâche de chaque projet pour savoir sur quel budget imputer leur travail.
Ca fait un argument de plus en défaveur du multi-tâche !

2. Le lundi 09 juin 2008, 09:16 par Alexandre Boutin

La mesure du temps passé permet de comparer de futures estimations à la réalité passée, sous condition que les tâches à réalisées soient similaires (ce qui arrive mais pas vraiment souvent). Donc c'est un 'petit' bénéfice pour ce qu'il me semble être une 'petite' contrainte (chacun sait ce qu'il à fait dans la journée et la ventilation des heures ne doit pas être une perte de temps - à la convivialité de l'outil de saisie prêt).

Pour ce qui est de comparer le temps passé par rapport aux estimations, c'est typiquement le comportement d'un manager ou d'un chef de projet NON AGILE. Mais je suis conscient que beaucoup d'entreprises utilisent encore et malheureusement cet indicateur comme mesure du résultat.

3. Le mardi 10 juin 2008, 15:51 par Rémy Sanlaville

Même si je suis d'accord sur le fait que l'estimation du temps qu'il reste à passé sur une tâche est plus importante que la mesure du temps qu'on y a passé, je continue à penser que de rajouter une troisième valeur pour indiquer le temps passer a un intérêt et n'est pas une perte de temps. J'ai vu cela dans plusieurs backlogs (dont une formation par une personne de Valtech qui est Scrum Master dans plusieurs projets importants) et dans certains outils. Ce n'est sans doute pas pour rien.

Pour l'avoir mis en place, j'ai vu certains avantages et je pense que cela a été plus un gain qu'une perte de temps. Entre autres pour améliorer mes estimations, pour prendre des décisions sur le fait qu'on a passé pas mal de temps sur une tâche et que le reste à faire n'a pas vraiment évolué (il y a un problème technique ou de compétence qu'on avait pas identifié), pour savoir où on en est (les deux informations, le reste à faire et le temps passé, m'ont été utiles)...

Si vous trouvez que cela n'est qu'une perte de temps alors c'est vrai qu'il vaut mieux pas le faire. Je suis intéressé justement par d'autres retours.

Rémy

4. Le jeudi 12 juin 2008, 12:29 par Frédéric Doillon

En mettant aux orties, ma vieille redingote percée de chef de projet traditionnel, pour enfiler mes habits de lumière de scrum master, j'ai abandonné en même temps toute idée de relevé du temps passé.
Il ne faut pas perdre de vue non plus que sur le task board, les estimations sont effectuées en heures effectives. Alors, comment effectuer un suivi d'heures effectives? Non, vraiment, cela ne sert à rien, sur un projet scrum.

5. Le mercredi 25 juin 2008, 16:58 par Jago

Pour moi c'est une perte de temps en effet. Une tâche peut avoir été ralentie pour diverses raisons, ce qui reste à la fin c'est juste un chiffre, savoir que l'on a passé du temps sans savoir à quoi ou pourquoi peut-être trompeur.
L'équipe sent bien quand elle a sous estimé une tâche dans un sprint et en tire naturellement les enseignements pour la suite (avec parfois une tendance à surestimer la fois d'après).
Et puis je trouve que cela donne un coté "surveillant" qui me dérange et qui peut aussi déranger certains membres de l'équipe qui se mettent en posture de se justifier. Je préfère les voir oser et entreprendre que culpabiliser.

La discussion continue ailleurs

1. Le lundi 09 juin 2008, 14:00 par Java Bien !

Actual vs Estimated

In Agile, there’s a never ending debate between the “Keep track of your estimates, compare them to actuals, use the deviaiton to improve your future estimates” family and the “DON’T track actuals” family. I’m f...