Découper les tâches comme un gnome
Par Amaury le mercredi 18 novembre 2009, 12:55 - Organisation personnelle - Lien permanent
Peut-être connaissez-vous l'auteur anglais Terry Pratchett, connu ses romans de science-fiction et de fantasy à succès.
J'aime beaucoup son ouvrage Le grand livre des gnomes. Et entre autre, il contient une phrase toute simple, pensée par le héros principal :
“ Pour accomplir une tâche impossible, on la débite en petits bouts de tâches simplement très difficiles, qu'on divise ensuite en tâches horriblement pénibles, qu'on segmente à leur tour en travaux délicats et ainsi de suite... ”
Pour le coup, Masklinn (c'est le nom du gnome) se fait cette réflexion en réfléchissant à la manière de découper et ramener à sa tanière un rat qu'il vient de tuer... Mais c'est en appliquant la même méthode qu'il finit par sauver son peuple en l'emmenant dans l'espace.
Je répète sans cesse que les listes sont à la base de toute organisation personnelle. Mais avant même de pouvoir placer des tâches sur une liste, il faut déjà définir le niveau de granularité nécessaire.
Pourquoi découper
Trop souvent, j'ai vu des gens qui se satisfaisaient d'une todo-list contenant des tâches dont les intitulés résumaient à eux seuls un projet entier. C'est complètement insensé !
Ce type de comportement a plusieurs effets pervers :
- On a une mauvaise vision de l'ensemble des actions nécessaires pour la réalisation du projet. Cela laisse la porte ouverte à de mauvaises interprétations. Arrivé aux trois-quart de la réalisation de la tâche, on peut découvrir qu'elle nécessite un développement imprévu, qui va durer à lui seul 3 fois plus longtemps que la tache initiale. Si on l'avait anticipé, cette tâche aurait peut-être été planifiée différemment, voire même abandonnée.
- Cela participe à l'effet tunnel : Comme on ne sait pas précisément ce qu'il va falloir faire, il est impossible d'évaluer la charge de travail correctement. Ça va peut-être prendre 3 jours, peut-être 3 semaines...
- Et quand on ne voit pas le bout d'un projet, on se démotive rapidement.
Comment découper
Si tout le monde s'accorde habituellement sur la nécessité de découper ses tâches, on ne sait pas toujours comment s'y prendre. Ce n'est pourtant que du bon sens :
- Pour découper un ensemble d'actions en tâches réalisables, il faut tout d'abord analyser finement les actions en question. Sans forcément nécessiter la rédaction d'une spécification technique de 300 pages, il est impossible d'imaginer les implications d'une réalisation si on ne sait pas un minimum comment on va la réaliser.
- Chaque tâche doit être "atomique". Elle doit pouvoir être réalisée seule, sans dépendre d'une autre réalisation. Si ce n'est pas le cas, re-découpez.
- Chaque tâche doit être suffisamment rapide à accomplir. Idéalement, une définition à la journée ou à la demi-journée permet de mettre un place un rythme de travail efficace.
- Si les tâches sont faisables en moins d'une journée, cela permet de se motiver en se donnant des objectifs atteignables.
- Lorsqu'une tâche prend plus de temps que prévu à être accomplie, il vaut mieux s'en rendre compte au plus tôt. Une définition à la journée aide à cela.
Par contre, il y a deux écueils à éviter :
- Comme je l'ai dit plus haut, une tâche ne doit pas être simplement un résumé pour un projet complet. Vous pouvez avoir une todo-list "macro", qui permet de suivre d'un coup d'œil la liste des projets en attente. Mais vous ne devez pas commencer à travailler sur un projet qui n'aura pas été correctement analysé et tronçonné.
- Il ne faut pas tomber dans le piège du découpage extrême et irraisonné qui conduit à gérer (ou plutôt, à tenter de gérer) des micro-tâches. Il faut évidemment lister l'intégralité des choses que l'on a à faire, pour ne rien oublier. Mais si vous commencez votre journée avec un planning horaire comportant des tâches qui doivent durer 3 minutes, mélangées à d'autres qui devraient prendre 2 heures, vous risquez surtout de rester frustré en fin de journée, parce que vous n'aurez pas réussi à faire la moitié des tâches prévues.
Commentaires
La ou je bosse on utilise scrum avec une unité de temps d'une heure (sprint d'une semaine, 4h effectives par jour).
Je ne pensais pas qu'il etait efficace, voir possible de descendre a ce niveau de granularité (mon ordre d'idée du mini c'etait plutot la journée) mais en fait ca marche pas mal.
On va ptet passer a des sprints de 2 semaines pour faciliter le boulot des testeurs, c'est tout.
Je pense en effet qu'il est difficile d'enchaîner des sprints corrects d'une semaine sans qu'aucun aspect du projet n'en pâtisse. C'est quand même court.
Pour la durée des tâches, une résolution d'une heure me semble difficile à tenir. Il suffit alors de peu de chose pour sortir du planning : mauvaise évaluation, mauvaise spécification, découverte de bug, micro-refactoring, gastro-entérite, ...
Pour moi, la granularité moyenne se situe à la demi-journée, voire au quart de journée. C'est à la fois réaliste et facile à porter sur un planning.
D'un autre côté, si tu comptes 4 heures efficaces par jour avec une résolution d'une heure, et que moi je compte des journées de 8 heures avec une résolution au quart de journée, on arrive un peu au même résultat.