De l'estimation en heures

Toute la semaine dernière ou presque, il y eut une discussion sur la liste Yahoo(!) scrumdevelopment.

Christofer Jenning demandait si les gens utilisaient l’estimation en heures pour les tâches, en disant qu’il avait souvent trouvé cela inutile, surtout lorsque vous avez un tableau de tâches montrant comment les choses se passent. Christofer disait qu’il avait trouvé l’estimation en heures utile pour décider de la quantité de travail que cela représente, mais il revint sur ses sujets de préoccupations principales, en parlant notamment de la “mauvaise” chose (les heures plutôt que le travail) ou simplement sans y prêter attention.

Certaines personnes étaient favorables à l’estimation des tâches en heures et disaient qu’elles la pratiquaient elles-aussi généralement. Certains trouvaient cela utile pour de nouvelles équipes, comme d’ailleurs Christofer.

D’autres y étaient beaucoup moins favorables en ce qui concernait les tâches, à l’estimation des tâches en heures, à l’estimation des tâches du tout, ou à toute forme d’estimation. Je ne veux pas dire que la notoriété implique nécessairement d’avoir raison, mais dans une grande majorité les gens qui y étaient le moins favorables étaient des personnes présentes sur la liste depuis longue date et dont les noms m’étaient familiers.

Peut-être voulaient-ils simplement que les personnes sortent de leurs prés carrés, mais je ne le pense pas. Je crois que l’expérience collective tend à révéler des choses qui sont probablement exactes, et qu’il est probable que l’estimation en heures soit loin d’être l’idéal.

Dis-nous ce que tu en penses, Ron !

(Demande toujours quelqu’un.)

Limitons notre discussion aux pratiques de la décomposition des items du sprint backlog en tâches, du travail en tâches, de l’estimation de ces tâches en heures, des heures passées, et du suivi du travail planifié par rapport aux heures effectives passées afin de voir comment vous avez travaillé. Nous partirons de cette dernière pratique pour remonter vers la première.

Suivi du travail planifié par rapport au travail effectif

Suivre le travail effectif par rapport au travail planifié conduit aux ennuis

Si nous avons estimé les tâches en heures, nous pouvons suivre les heures effectives. Si elles diffèrent, il y évidemment quelque chose qui s’est mal passé. La question qui suit naturellement est “qu’est-ce qui s’est mal passé lors de votre estimation ?”. La réponse qui suit naturellement est devenir meilleure en estimation.

Étant donné que ce sont des chiffres dont il est question ici, il est très tentant pour l’encadrement, ou pour les personnes ayant une inclination pour le pilotage, d’essayer de piloter par les chiffres. L’attention est mise sur la concordance des chiffres entre le réel et le prévisionnel. C’est même pire, l’attention sera portée de telle manière afin d’être certain que les chiffres réels soient toujours en deçà de ceux de l’estimation. Ce sera bien d’arriver plus tôt ; ce ne sera jamais bien d’être en retard.

Vous obtenez alors ce que vous avez demandé. Ce que vous obtiendrez ce sont des estimations suffisamment grandes afin d’être dépassées rarement. Cela aura comme conséquence que moins de travail sera pris en charge par l’équipe et que vous serez ralentit.

Faire le suivi des heures effectives par rapport aux heures estimées tend à entraîner des difficultés. Est-ce si inévitable que cela ? Certainement pas. De la même manière, il n’est pas inévitable que vous soyez percutez par un camion si vous jouez au milieu de la route.

Les heures effectives

Suivre les heures effectives n'est pas une manière efficace de faire du suivi

Bien. Donc nous n’essayons pas de faire s’aligner le prévisionnel et le réel, mais nous utilisons l’estimation en heures du travail restant pour suivre les tâches de notre backlog. Si vous prêtez suffisamment attention, vous pouvez lire quelque chose de ce genre dans le guide scrum vous disant de faire quelque chose comme ça.

Si vous le faites, vous saurez avec certitude si les tâches ont été faites, et si celle-ci ou celle-là se traîne toujours et encore.

Il existe des moyens connus et plus faciles pour le savoir. Le plus connu est le tableau de tâches montrant toutes les tâches réparties par simple statut d’avancement comme par exemple Non démarrée, En cours, et Finies. Si quelque chose indique En cours depuis un certain temps, vous avez un problème. Impossible de s’en rappeler d’un jour à l’autre, diriez-vous ? Mettez une marque rouge sur une carte présente dans la colonne En cours tous les matins. Vous voyez beaucoup de points rouges ? Problème.

Suivre les heures effectives c’est correct, mais inefficace. Et avoir les heures conduit à les suivre à la fin du sprint, ce qui est loin d’être l’idéal comme nous l’avons vu à la section précédente.

(Note de l’éditeur (dans le texte original - NdT) : lorsque Ron dit “loin d’être l’idéal”, il veut dire mauvais. Il est tout simplement gentil pour certaines raisons que nous ne comprenons pas.)

Estimer les tâches en heures

L'estimation des tâches en heures ne paye pas.¹

Selon l’argument précédent, nous n’avons pas besoins de tâches en heures quel que soit l’objectif déclaré : elles ne sont pas bonnes que ce soit pour gérer au jour le jour ou de sprint en sprint. Ont-elles d’autres avantages, de telle sorte que nous devrions les utiliser et peut être ensuite les jeter ?

Si nous parlons de l’estimation des tâches, il y a quelques arguments en faveur de l’estimation pour des besoins internes : nous avons déjà eu une discussion (de quelque nature que ce soit) sur la conception qui a fait en sorte que nous ayons pris connaissance des tâches (à faire - NdT).

Ce n’est pas vraiment une contrepartie à l’estimation des tâches en heures si vous n’allez pas les utilisez ou les suivre, et vous ne devriez pas les utiliser ou les suivre pour les raisons évoquées ci-dessus.

L’estimation des stories en heures

L'estimation des stories en heures peut être utiles. Pas les tâches.

Lorsqu’il s’agit des stories, même si vous n’allez pas utiliser ou suivre ces heures, il y a un petit élément en faveur de leur utilisation.

Dave Farley, lors d’une conversation sur Twitter avec Kate Oneal que j’ai sauvegardé, a dit à Kate que son équipe s’était mise à refaire des estimations parce que les discussions sur la conception qui en résultaient manquaient à son équipe, et qu’ensuite ils jetaient les estimations. Joe Sadowski lui a raconté une histoire similaire sur le fait que le planning poker créé de la discussion lorsqu’il n’y a pas d’accord immédiat.

Je vois tout à fait comment cela pourrait arriver. Je dis que cela prendra une journée, vous en dites quatre. Si je suis suffisamment malin, je ferai semblant de dire quelque chose comme “Quoi ?” et je m’apercevrai que vous voyez bien que je ne le fais pas. Assez souvent nous nous apercevrons que l’un d’entre nous n’a pas compris la story, ou s’est trompé sur sa difficulté. Et nous aurons appris quelque chose de cette discussion.

Faire cela dans le contexte de l’estimation peut être une manière rapide d’identifier les stories pour lesquelles nous ne sommes pas en phase.

Je pense qu’une session rapide dans le style planning poker, montrer les cartes, passer à la suite si elles sont suffisamment proches, discuter si elles ne le sont pas, pourrait être une manière rapide d’aider à faire émerger les bonnes discussions sans perdre du temps sur des choses qui ne rapportent rien.

Il n’y aucune raison de faire cela avec des heures ou des jours, toutefois, si vous êtes à l’aise avec, il n’y a pas de mal. Ne tombez simplement pas dans le piège de les suivre et de justifier les chiffres simplement parce que vous les avez.

Je suppose qu’il “devrait” être possible d’avoir des discussions de conception sans le poker, mais étant donné que nous utilisons le jeu uniquement pour décider de ce que nous allons discuter, cela semble être une pratique décente.

Travailler en tâches

Travailler en tâches conduit à des problèmes d'intégration et à du gâchis

Jusqu’à présent, nous avons trouvé peu de valeur, voire une valeur négative, à l’estimation des tâches. Et que dire alors de décomposer le travail en tâches et de travailler de cette manière ?

Si nous identifions les différentes étapes pour implémenter une story, nous y penserons forcément beaucoup, ferons un peu de conception, et ainsi de suite. Cela sera bel et bon. La conception sera bonne.

Toutefois, si nous travaillons alors vraiment sur ce plan de tâches, beaucoup de choses peuvent arriver, et la plupart d’entre elles sont mauvaises.

Nous pourrions faire chaque tâche, les rassembler, et avoir une story qui fonctionne vraiment. Cela peut arriver. Plus souvent qu’alors, nous pensons que les tâches sont faites, et lorsque nous les intégrons, la story ne fonctionne pas. C’est “loin d’être l’idéal” (voir précédemment). Cela conduit à pointer du doigt, à d’autres gestes du doigt, et à se précipiter à la fin du sprint pour trouver ce qui s’est mal passé.

Travailler en tâches provoque généralement l’arrivée de ce genre de choses : qui que ce soit travaillant sur chacune de ces tâches n’aura pas de retour d’informations jusqu’à ce que toutes les tâches soient faites, qu’elles fassent la bonne ou la mauvaise chose. Travailler sans retour d’informations conduit à l’erreur.

Mais approfondissons un peu plus sur ce qui peut mal se passer quand vous travaillez sur la tâche A1 et que je travaille sur la tâche A2, pour donner la story A. Chacun d’entre nous peut faire la chose correctement ou pas. Nous ne le saurons qu’à la fin. Nous pouvons y travailler chacun un peu, en oubliant quelque chose, ou en faire trop, en y ajoutant quelque chose qui n’est même pas demandé. Ou bien simplement nous pouvons le faire correctement.

Quelles sont les chances ? Des chances que nous aurons des ennuis quand nous intégrerons et des chances qu’il y aura du code à la pelle à la dernière minute et qu’il y aura aussi du code qui n’a pas besoin d’être fait du tout.

Du gâchis, voilà ce qu’il se passe. Faire la décomposition des tâches est souvent inefficace et inefficient. Ne soyez pas cette personne. Travaillez à la place avec des stories complètes. (voir plus loin)

Identifier la décomposition des tâches

Dans une étape de conception, la décomposition des tâches peut être utile. Mais tout simplement, ne construisez pas comme ça

Lorsque nous planifions de construire quelque chose, même de légèrement compliqué, cela peut être tout à fait valable de faire une “rapide session de conception”, où nous esquissons ce que pensons que nous allons faire. Cela peut se transformer en une décomposition de tâches, et c’est sans doute plutôt bien de faire cela. Il y a beaucoup de valeur de faire cela en petits groupes, ou du moins le binôme qui va travailler sur la story, et c’est souvent utile de faire venir d’autres personnes.

J’ai même vu de la valeur dans la présence du product owner à ces sessions, parce qu’assez souvent il entend quelque chose lui signalant que nous n’avons pas compris.

C’est correct d’écrire ces idées d’implémentations sous la forme de tâches sur des cartes ou sur une liste. Mais comme nous l’avons vu précédemment, il y a peu d’avantages de faire de cette manière, et beaucoup de désavantages.

Les estimations, les heures et tutti quanti : non, la plupart du temps

Ça y est nous y sommes, voici mon avis, si ce n’est sage, du moins de professionnel expérimenté :

• Concevoir en utilisant des tâches peut avoir de la valeur
• Réaliser à partir de tâches est toujours moins bien
• Les estimations peuvent déclencher des conversations utiles
• Suivre les estimations est toujours inefficace et souvent néfaste.

Les Stories, c’est mieux que les tâches

Des stories terminées c'est mieux que des tâches. Gardez-les petites. Et il n'y aura pas besoin de faire des estimations.

J’avais promis (voir ci-dessus) de parler de travailler avec des stories pleines et entières plutôt qu’avec des tâches. Nous y voilà.

Tout d’abord, les stories (ou les items du product backlog, si vous préférez) sont ce que le product owner souhaite. Le PO ne veut pas de tâches : il veut juste savoir la manière dont nous pourrions organiser notre travail. Par conséquent, lorsqu’une équipe se concentre sur des stories, elle est plus focalisée sur ce qui est vraiment demandé.

Ensuite, le besoin ou le souhait de décomposer le travail est souvent guidé par les différentes spécialités dans l’équipe. Je suis un spécialiste des bases de données, vous êtes un spécialiste des IHM, Sam est un testeur, et ainsi de suite. L’ensemble de l’équipe est pluridisciplinaire, mais en tant qu’individus nous sommes spécialisés, nous sommes par conséquent limités (à notre domaine - NdT). Ça serait mieux si nous pouvions travailler sur quasiment tout et n’importe quoi, peut être en me laissant les problèmes difficiles concernant les bases de données, à vous les sujets difficiles sur les IHM, et les tests les plus complexes à Sam. Quand nous travaillons ensemble en binôme, ou dans un groupe, tous ensemble nous en apprenons plus. C’est mieux d’avoir un éventail relativement large de compétences, sans compter que cela ne vient pas piétiner sur les plates-bandes de nos connaissances approfondies respectives dans notre domaine de prédilection.

Travailler en stories rend plus service au product owner, et à l’équipe aussi. Ce n’est pas la seule manière de le faire. C’est bien de travailler en tâches. Et c’est probablement mieux en stories.

Mais les stories sont trop grosses !

J’ai déjà entendu cela. Si vos stories sont trop grosses, elles étaient déjà trop grosses lorsque vous faisiez des tâches. Soit vous pouviez les faire en un sprint, soit vous ne pouviez pas. Si vous ne pouviez pas, alors vous ne pouviez pas réellement livrer un incrément “fini” du produit, ou, comme je le dit depuis des années, un “logiciel testé qui fonctionne”.

Si vos stories sont trop grosses, réduisez-les.

N’est-ce pas une forme d’estimation ?

Lorsque quelqu’un posa cette question à Kate Oneal lors d’une conversation sur Twitter l’autre jour, elle répondit que si elle était Madame La-définition-au-pied-de-la-lettre elle appellerait cela de l’estimation, mais en fait ce qu’elle pensait des estimations, c’est que c’était de simples nombres qu’“ils” pouvaient utiliser. “Ils” étant, je pense, l’encadrement …

Chet et moi recommandons que les stories ne représentent pas plus d’un jour ou deux d’implémentations. Nous ne sommes pas intéressés par savoir s’il s’agit d’un jour ou deux : nous sommes intéressés par savoir si c’est petit.

Neil Killick a fait remarquer qu’une bonne règle générale serait qu’une story puisse être définie en un seul test d’acceptance. C’est une idée brillante, parce qu’il n’est pas question ici d’estimation, mais qu’une bonne analyse est nécessaire pour définir le test, abordant la seule valeur à laquelle nous pensions avec les estimations faites dans l’équipe, c’est à dire en examinant en profondeur la story.

Donc non, ce n’est pas vraiment une sorte d’estimation de dire que des stories soient petites. C’est une bonne chose à faire. Cela maintient notre attention sur ce que le product owner veut, cela aide l’équipe à être davantage pluridisciplinaire, cela permet de maintenir à l’écart des fonctionnalités les idées ennuyeuses. De petites stories : la voie à suivre.

Prévoir quand nous aurons fini

Je m’attends à ce que beaucoup d’entre vous soient d’accord désormais, mais certains seront toujours persuadés que les estimations sont en quelque sorte la voie divine de faire les choses, ou du moins celle du directeur général. Eh bien, je suis de tout cœur avec vous, mais cela ne fait pas des estimations la seule ou la meilleure manière de faire. À mon avis, aucune n’est meilleure. Les petites stories sont mieux. Les tests d’acceptances sont mieux.

Voici deux défis :

• Et si les stories étaient approximativement de la même taille ? Alors que pourrions-nous faire avec des estimations de stories que nous ne pourrions pas faire avec le comptage des stories ?

• Et si toutes les stories étaient un seul test d’acceptance ? Que pourrions nous faire avec des estimations des stories que nous ne pourrions pas faire avec le comptage des stories (ou dans ce cas avec le comptage des tests d’acceptance) ?

TL;PL²

Il y a beaucoup de bonnes raisons de ne pas faire des estimations de tâches ou des estimations de stories. Il y a de très nombreuses bonnes raisons de ne pas les suivre, de ne pas les justifier, de ne pas essayer de les améliorer.

Vous pouvez presque tout faire avec le comptage des stories ou des tests d’acceptions que vous faites avec les estimations de tâches et de stories. Quand vous pouvez le faire, cela fonctionne mieux de quasiment toutes les manières.

Si vous connaissez une situation où ce raisonnement ne tient pas, dites-le-moi, j’aimerai en entendre parler.

Auteur : Ron Jeffries
Source : Hours Estimation
Date de parution originale : 2 Janvier 2015

Traducteur : Nicolas Mereaux
Date de traduction : 28/09/2015

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.