J’ai fait quelques petites lectures intéressantes dernièrement que j’aimerais bien partager avec vous. Je résume en fait une toute petite portion d’éléments provenant du cours en ligne « Agile Estimating & Planning » de Mike Cohn (Mountain Goat Software).
Indépendance des tâches
Il existe quelques raisons expliquant pourquoi les plans ne fonctionnent pas, notamment dans le domaine des technologies de l’information. La première est l’importance majeure qu’ont les dépendances entre les éléments du plan. Il est démontré que si chaque élément était TOTALEMENT indépendant des autres, alors les erreurs d’estimation (sur ou sous-évaluation) s’élimineraient entre elles et on aurait une distribution normale similaire à celle-ci :
Si c’était le cas, on pourrait alors avoir confiance aux estimés et aux plans.
Le problème, on le sait, c’est que les éléments sont beaucoup plus dépendants entre eux, comme nous le démontrent si bien nos merveilleux diagrammes de Gantt, dont voici un exemple très simple :
De plus, de façon générale, nous sommes plus souvent en situation de sous-estimation, car nous avons tendance à penser en « jours idéaux », alors qu’il est très rare que nous ayons des jours idéaux…
Nous sommes également plus souvent en retard qu’en avance, l’une des raisons pour cela étant expliquée plus bas (le syndrome de l’étudiant).
Alors, l’ancien programmeur en moi ne peut qu’être ému par la logique implacable des équations suivantes :
A. If IsDelayed(Task1) OR IsDelayed(Task2) OR IsDelayed(Task4) Then Delay(Task3)
B. If IsEarly(Task1) AND IsEarly(Task2) AND IsEarly(Task4) Then StartEarly(Task3)
Selon vous, est-ce que la condition A a beaucoup plus de chances d’être rencontrée que la condition B? Il ne faut qu’une seule des tâches (1, 2 ou 4) soit en retard pour que la dernière soit aussi affectée.
En revanche, il faudrait que l’ensemble des tâches (1, 2 et 4) soient en avance pour qu’on puisse devancer la dernière!
Lisez la section suivante et vous verrez que c’est peine perdue, on ne passera jamais dans la condition B…
Peut-on vraiment se battre pour éliminer TOUTES les dépendances? Pas vraiment, elles sont intrinsèques au développement logiciel. Même si on les identifie au maximum et qu’on peut en éliminer certaines, il en restera toujours.
Le syndrome de l’étudiant
Quel étudiant n’a pas déjà vécu cette situation : vous avez un rapport de 30 pages à remettre dans 15 jours. Vous évaluez que ça va vous prendre 5 jours, à raison de 3 heures par jour (donc environ 15 heures). Est-ce que vous commencez immédiatement vos 3 heures par jour? Il est beaucoup plus probable que vous attendiez vers la fin du délai, au 11e ou 12e jour (au minimum!) pour vous rendre compte que ça vous prendra plus de temps que prévu et vous finissez par travailler 20 heures en ligne la dernière journée pour compléter vos 30 pages.
Quand on nous demande d’estimer, on se donne généralement un certain lousse pour justement ne pas être trop serré, c’est naturel. Malheureusement, quand on a du lousse, l’humain le place naturellement avant, et non pas après. En plus, comme mentionné plus tôt, on est plus souvent en sous-estimation, alors on finit en retard.
Ce que l’on devrait faire :
Ce que l’on fait plutôt :
Ce comportement est humain et naturel, donc il est plutôt futile d’essayer de se battre pour l’éliminer.
L’important, c’est l’action de planifier, pas le plan lui-même!
Évidemment, combinez le problème de l’effet des interdépendances entre les tâches à celui du syndrome de l’étudiant et vous avez des plans qui ne tiennent jamais.
Voilà pourquoi il faut accepter d’être Agile dans nos planifications et mettre l’accent sur l’action de planifier, et non pas sur le plan lui-même, tout en s’appuyant sur les 6 niveaux de planifications d’une organisation Agile :
Chaque niveau intégrant des estimés avec des degrés de précision adéquats selon le niveau, tout en restant justes.
Précision et justesse
Mais parlons donc de précision et de justesse dans nos estimations. Quelle est la différence entre la justesse et la précision?
Disons que la date de naissance de ma conjointe est le 15 juillet (pour ceux qui la connaissent, ce n’est pas sa vraie date). Uniquement pour les fins de l’exemple, disons que je suis plutôt du genre à ne pas me rappeler de la date exacte (uniquement pour les fins de l’exemple!) En janvier, si vous me demandez : « C’est quand l’anniversaire de ta conjointe ? » et que je vous réponds : « En juillet », c’est une réponse juste. C’est aussi une réponse suffisamment précise en janvier si l’intention est de préparer un dîner pour son anniversaire. En juin, si à la même question, je réponds « À la mi-juillet », c’est encore une réponse juste et suffisamment précise. Par contre, le 10 juillet, je vous répondrai certainement « C’est le 15 », ce qui est toujours juste et très précis (car il est temps de réserver au resto!) Répondre « En juillet » à cette dernière question soulèverait probablement quelques doutes sur l’intérêt que je porte à l’anniversaire de ma conjointe!
Si la première fois, en janvier, j’avais répondu « C’est le 18 juillet à 12h », j’aurais été très précis (trop), mais incorrect.
« It is better to be vaguely right than exactly wrong. »
Carveth Read, philosophe et logicien anglais dans Logic: Deductive and Inductive (1920)
Il vaut mieux être « vaguement juste » que « précisément en erreur ».
Chaque niveau de planification requiert des estimations justes, mais également limitées à un degré de précision approprié selon le niveau.
En finissant, voici un commentaire d’un de mes collègues de Facilité (Frédérick Lussier) sur l’article que vous venez de lire, que je trouvais très pertinent d’ajouter:
Peut-être mettons-nous trop d’emphase sur la finalité de cette activité. Est-il possible de réunir une équipe, de comprendre ce que nous avons à réaliser et le réaliser? Car à la fin de la journée, nous ne sommes pas payé à la tâche, mais à la valeur que nous livrons.
Voilà, j’espère que mon résumé aura été aussi intéressant que Mike Cohn l’a été pour moi dans ses formations. Je vous encourage d’ailleurs à vous y inscrire, elles sont toutes très enrichissantes!