Le suivi des temps déchaîne rarement l’enthousiasme dans les équipes et bien des managers traditionnels peinent à le mettre en place. Cependant il trouve un nouveau sens et se renouvelle en mode agile en devenant une source précieuse de feedbacks pour toute l’équipe, principe fondamental de l’Agilité.
Feedback et Suivi des temps (Time Tracking)
En matière de gestion de projet, le processus d’estimation reste un exercice difficile et approximatif, alors qu’il est essentiel pour déterminer la viabilité du projet. Et le suivi des temps est le seul moyen d’obtenir un feedback pertinent sur ce processus critique.
Dans le domaine du développement logiciel, les tentatives de rationalisation du processus d’estimation ont abouti à des résultats médiocres malgré la complexité des modèles analytiques développés (points de fonction, Cocomo etc.). En général, estimer un projet reste un processus empirique basé sur l’intuition et l’expérience des équipes, agrémenté de techniques de recherche de consensus. Mais la fiabilité des processus empiriques est soumise à caution et on constate en pratique des marges d’erreur importantes.
En mode Agile, on a la chance de pouvoir vite améliorer le processus d’estimation empirique. Il suffit de fournir à l’équipe le feedback adéquat: les écarts entre les estimations et le temps réellement passé au niveau de chaque item du backlog.
Alimenter en informations chiffrées les rétrospectives (SCRUM) est le premier objectif du suivi des temps en mode Agile. L’équipe fournit un retour qualitatif et humain, le suivi des temps le complète par un feedback quantitatif et objectif.
L’indicateur de Vélocité seul ne permet pas d’identifier les causes des problèmes. En effet, calculé au niveau du Sprint (= itération), c’est un indicateur trop macroscopique influencé par de nombreux facteurs. De plus, la Vélocité n’est pas une mesure mais le paramètre d’un modèle linéaire simple entre complexité et charge de travail.
Le suivi des temps permet aussi d’avoir une mesure précise du facteur de concentration (focus factor) pour ceux qui l’utilisent.
Pour être utile, le feedback doit se faire au même niveau de détails que le processus d’estimation (i.e. backlog item, user story, la fonctionnalité…). C’est à ce niveau que le suivi des temps prend toute sa valeur (et non au niveau des tâches). Il permet de mesurer la fiabilité de chaque estimation, prise séparément. Il est alors possible d’ajuster le processus d’estimation pour prendre en compte d’autres facteurs que ceux du modèle générique.
Voici quelques leçons apprises chez Time Performance grâce au suivi des temps avec TimePerformance:
- Nous passons environ 30% du temps sur des sujets qui ne font pas partie de la feuille de route du produit.
Dans ces 30%, on retrouve les refactorings, les corrections d’anomalies, les petites améliorations, les tests utilisateurs…
Le suivi des temps nous a permis de budgéter pour les itérations suivantes ce qui n’était pas dans la feuille de route.
- Les tâches les plus complexes ne sont pas celles qui relativement prennent le plus de temps.
Certaines tâches sont très simples techniquement mais prennent néanmoins du temps. Et la relation entre complexité technique et charge de travail n’est pas linéaire.
Par exemple, il peut être nécessaire de faire de nombreuses retouches avec des allers-retours avec les utilisateurs. Il y a aussi des «coûts fixes», car même pour une fonctionnalité simple, il faut écrire des tests et de la documentation.
Attention donc à ne pas sous-estimer le temps nécessaire sous prétexte que c’est simple techniquement.
- Notre perception du temps est très subjective, bien plus qu’on ne le pense.
Certaines heures paraissent être des minutes et certaines minutes paraissent durer des heures. Tout dépend si ce qu’on fait nous plaît ou non.
Par exemple, certains se font une montagne de devoir remplir une feuille de temps alors que cela ne prend que quelques minutes par semaine. Et on retrouve les mêmes à la machine à café en train de discuter depuis 45 minutes sur le temps qu’il fait. L’exemple fonctionne aussi avec l’écriture des tests, de la documentation… Tout le monde se reconnaîtra, nous les premiers.
Le suivi des temps peut permettre à chaque individu d’objectiver le temps qu’il passe réellement sur les tâches.
- Notre marge d’erreur sur les estimations était plus importante sur les nouvelles fonctionnalités que sur les évolutions.
En y réfléchissant, c’est assez logique. D’abord le risque est plus important pour une fonctionnalité importante et totalement nouvelle. La solution imaginée au moment de l’estimation peut ne pas marcher et nécessiter plusieurs ajustements. Les impacts sont aussi plus importants et des refactorings du code et des tests existants sont très probables.
Un suivi des temps efficace est absolument essentiel pour les équipes agiles pour maîtriser leur processus d’estimation. Cela mérite bien qu’on y passe quelques minutes par semaine.
Suivi des temps et gestion du projet
Traditionnellement, la feuille de temps sert principalement à suivre les coûts réels du projet en comptabilisant le nombre de jours travaillés.
En mode Agile, il est recommandé des équipes stables et des affectations à plein temps, ce qui rend la feuille de temps inutile.
Cependant la réalité des entreprises est souvent bien différente du cas idéal:
- les personnes participent à la vie de l’entreprise (réunion de service, aider un collègue, veille, réorganisation…);
- les personnes travaillent sur le projet mais peuvent être appelées en urgence sur d’autres sujets;
- la spécialisation d’une personne ne permet pas une affectation à plein temps;
- Une compétence rare est réclamée par de nombreux projets …
En pratique, le suivi des temps est indispensable pour connaître le temps réellement passé sur le projet. Il permet notamment de constater un écart entre affectation prévue et affectation réelle, qui explique dans de nombreux cas les retards dans les projets.
Même en mode Agile, le suivi des temps est en général nécessaire pour gérer le projet.
Vaincre les résistances
La mise en place du suivi des temps dans une équipe est un moment délicat où il faut faire preuve de leadership pour porter la vision.
Voici les 3 clés pour réussir la mise en place du suivi des temps:
- Donner du sens. C’est l’objet de cet article et la principale mission du manager ou du SCRUM Master.
- Faciliter la saisie par l’équipe. C’est ce que nous avons fait chez Time Performance avec notre logiciel TimePerformance en proposant 2 moyens complémentaires pour suivre facilement son temps: une feuille de temps (déclaration a posteriori) et une liste de tâches avec une fonction type «chronomètre» (suivi au fil de l’eau).
- Montrer des résultats, c.-à-d. exploiter les informations et communiquer les résultats à l’équipe. C’est sans doute le plus important et ce qui permettra de convaincre les plus sceptiques.
Il y a encore quelques années, écrire des tests ou documenter le code n’étaient pas plus populaires que le suivi de temps parmi les développeurs. Aujourd’hui, c’est le quotidien des équipes agiles qui s’en font une fierté. Dans quelques années, un bon suivi des temps pourrait devenir le signe de maturité et d’autogestion d’une équipe…
Le mode Agile ne s’intéresse pas au suivis du temps
Le mode Agile ne s’intéresse pas au suivis du temps mais à la production effective de fonctionnalités validées et testées.
@Vickoff
Pourriez-vous préciser votre pensée ?
Le temps est très important dans une approche Agile avec notamment le concept de timeboxing. Le burndown chart indique la charge restante. L’objet de l’article est de présenter l’intérêt de connaître le temps passé, et pas seulement le temps restant, sur les sujets pour obtenir un retour d’expérience. C’est de l’Agilité.
Beaucoup de contresens
[i]La lecture des « règles d’utilisation » m’inciterait à ne pas poster de commentaire car vous vous octroyer le droit de le modifier sans mon accord. Je trouverais plus honnête de ne pas le publier (c’est acceptable) ou le publier entièrement, mais pas de le modifier !
Quoiqu’il en soit, je tente quand même[/i]
Malheureusement vous utilisez le terme AGILE à l’envers … et du coup vous croyez justifier la collecte des temps passé … que d’erreurs en un seul article !
Quelque exemples :
– La vélocité est bien une mesure (de la quantité de travail terminé)
– La Story/Fonctionnalité ne s’estime PAS en temps passé (justement c’est ce que l’agilité veut éviter)
– Le refactoring fait partie intégrante du la réalisation d’une fonctionnalité
– Les points d’effort ne mesurent pas uniquement la complexité, mais plutôt un compromis entre complexité et durée de réalisation (avoir pratiqué 1 fois dans sa vie un XP game permet de bien comprendre ce concept)
– Si les 45′ passées au café sont consignés dans le suivi des temps d’une tâche … en quoi le suivi des temps est-il juste ?
– Comprendre que les nouvelles fonctionnalités doivent avoir une estimation en points plus grande peut se faire sans avoir besoin de traquer le temps passé
– « … nécessaire pour gérer le projet. » : Pouvez-vous me rappeler QUI gère le projet ?
D’une façon générale, le suivi des temps se rapproche plus du contrôle par manque de confiance … et c’est entre autre la confiance qui fait la force de l’Agilité
Pas de contresens
@Agilex Votre opinion est la bienvenue sur ce blog et nous vous remercions de votre participation.
Pour répondre aux exemples de prétendues erreurs:
1) la vélocité n’est pas une mesure d’un point de vue scientifique car il n’existe pas de mètre-étalon du Story Point. Par contre elle se calcule.
2) la story peut s’estimer en temps (cf le concept de «jour idéal»). L’estimation en point est cependant préférable. Quel que soit l’unité choisie, l’objectif reste de définir la charge de travail acceptable pour le sprint, c’est à dire le temps de travail qui y sera passé.
3) tout à fait d’accord pour certains refactorings. Mais d’autres refactorings, comme par exemple la montée de version du framework, dépasse largement le cadre d’une story.
etc…etc…
Je suis désolé de ne pas vous avoir convaincu mais je crois que vous avez lu mon post avec un fort a priori sur le suivi des temps.
Personnellement, j’associe suivi des temps avec auto-gestion, transparence et feedback. (plus de détails ici: http://www.timeperformance.com/blog/16-generalites/148-suivi-des-temps-flicage
Merci encore pour votre contribution
L’agilité pose la question d’une préparation adéquate
En effet pour les projets importants, la gestion de projet agile doit s’accompagner d’une analyse des risques en profondeur pour pouvoir anticiper les différentes éventualités. Des outils gratuits d’analyse de risques et de macro-planning Excel sont disponibles sur notre site.
Hormis ce point, félicitatios pour un post complet et original.
Cordialment.