Ton estimation de temps est une blague
Tu penses que ça va te prendre combien de temps ? Cette question à la con me file un frisson à chaque fois qu’on me la pose. Le problème c’est qu’il n’y a pas de bonne réponse à cette question. Ton estimation de temps sera forcément une blague et aujourd’hui on va voir pourquoi.
Théorie du chaos
Imagine, tu décroches un nouveau travail. Pour le trajet du premier jour, tu vas faire comme tout le monde. Tu vas demander une estimation de temps à Google Map. Et le premier jour, tu te mets bien, tu vas arriver à l’heure.
Le lendemain, pas de chance, il y a toute la terre sur l’autoroute avec toi. Tu débarques avec 20 minutes de retard. OK, dans le futur tu partiras 20 minutes plus tôt histoire d’être peinard. Le surlendemain, chaos total, carambolage, autoroute fermée, tu te tapes toutes les départementales de la terre et t’arrives avec deux heures de retard. Ton boss il fait la gueule et ton estimation de 20 minutes, c’est une grosse blague. Tu commences à faire rire tous tes collègues.
Du coup, tu fais comment ? Tu pars 1 heure en avance ? 2 heures en avance ? Mais comment tu fais si tu tombes en panne ? Et tu fais comment s’il tombe 20 cm de neige ? Tu arrives au cœur du problème. Ça fait longtemps que tu parles plus de ton trajet en fait. Tu n’estimes plus ton trajet. Tu estimes le chaos potentiel durant ton trajet. Ton estimation de temps est une blague car tu estimes le chaos. Le chaos est par définition imprévisible. Et ceux qui disent le contraire ne font qu’amplifier ce chaos.
Caisse de résonance
Si je te parle de ça aujourd’hui c’est parce que tu es particulièrement concerné dans le milieu de la tech. Plus un système est complexe, plus il est sujet au chaos. Et dans la tech côté chaos on est à peu près au niveau Carnaval. Y’en a de partout et c’est le bordel !
Des systèmes complexes ? Tu fais ça tous les jours. Pire, tu as un milliard de dépendances qui sont des systèmes complexes et qui ont eux-mêmes des dépendances. Ton estimation de temps est une blague car le chaos potentiel autour de toi est incalculable.
Et au milieu de tout ce chaos, t’as un chef de projet qui vient te voir. Sereinement, il te met des specs qui tiennent sur un post-it devant ta face et il te dit : combien d’heures de travail pour ça ? Et toi du coup tu regardes le post-it et tu trouves ça super drôle !
Tout de suite après il rajoute « tu peux faire ça vite vite ? ». Bah oui, il faut que ça aille vite. C’est ça ton domaine. Les technologies évoluent et les façons de faire aussi. T’apprends en permanence pour une seule raison : aller plus vite. Savoir plus de choses, être capable de tenir la cadence d’un secteur connu pour son rythme infernal. Pour la plupart des gens qui gèrent des projets informatiques, un bon développeur est un développeur rapide. Rien à foutre de la qualité. Rien à foutre de la maintenabilité. Rien à foutre des bonnes pratiques. Rien à foutre de la stabilité.
On patchera plus tard. Tu as tenu les délais ? C’est bien, toi, t’es un bon développeur. Ton estimation de temps est une blague car on te pousse à faire toujours plus vite. Et comme on te pousse à faire vite il faut en plus que tu estimes vite.
Ton estimation est ta deadline
Alors je vais pas parler du cas où c’est le chef de projet qui fait l’estimation de temps pour toi. Si c’est même pas toi qui estimes le temps nécessaire pour faire ton propre travail, tu es actuellement dans les sous-sols de l’enfer. C’est chaud. Barre-toi très loin. Vite.
Quand c’est toi qui l’as fait, tu as généralement très peu de temps pour la faire. Et en très peu de temps, il se passe plein de choses. D’abord tu sais que peu importe ce que tu vas dire ça va être utilisé tel quel. Ton estimation de temps est une blague car tu sais très bien que ça va devenir ta deadline. Sachant ça, tu estimes large. Logique.
On va te dire que c’est trop long ton estimation là. C’est trop cher pour le client tu comprends ? D’ailleurs on a vu quelqu’un faire la même chose en moitié moins de temps. C’est simple ! T’es nul ou quoi ?
Et avec cette technique non seulement on refuse ton estimation, mais en plus on titille ton énorme égo. Tu finis par craquer. Tu raccourcis ton estimation. J’ai souvent fait exactement la même chose. « En effet ça c’est facile, je l’ai fait plein de fois ». Évidemment sans rien vérifier. Ton estimation de temps est une blague car c’est souvent ton égo qui fait l’estimation. La plupart du temps le chaos ne s’invite pas et tout se passe comme prévu. Mais quand le chaos s’invite, ça peut vite devenir spectaculaire.
Ta deadline est une blague
Dans l’une des agences où je suis passé un collègue a été victime exactement du même scénario. Post-it, estimation puis chaos. Il s’était engagé le lundi matin pour finir une tâche le lundi même. Il a ship vendredi 15 h. Le vendredi de la semaine d’après.
Ce vendredi-là, avec toute l’équipe de dev, on lui a fait une clef de bras et on l’a forcé à venir dans un bar. On voulait savoir tous les détails. Son histoire chaotique nous a fait rire toute la soirée. On l’a écouté toute la nuit et c’était incroyable.
Son histoire, c’était le schéma habituel d’une tâche piège. À chaque fois qu’il s’approchait de la fin de la tâche soit on lui en rajoutait soit on lui changeait carrément le scope. La plus grosse blague étant le changement de scope sans le changement de délais. Ton estimation de temps est une blague car tu donnes un temps strictement fixe sur un problème qui peut évoluer. Quand plus personne prend les choses au sérieux, c’est au développeur de payer le prix.
Ta blague ne te fait plus rire
Bon ceci dit le scope peut très bien rester le même et les délais être non tenus. Ça arrive fréquemment et là tout d’un coup ça te fait plus rire.
Faire du dev c’est comme monter un meuble Ikea. T’es bon pour monter des meubles. Tu fais ça depuis des années. En plus, tu as une documentation pour t’aider. Souvent tu le fais avec d’autres personnes. Tu assembles plein de pièces ensemble pour former un beau résultat utilisable. La plupart du temps ça se passe bien. Et puis des fois t’es au milieu de l’assemblage et tu te rends compte qu’il te manque une pièce. C’étais pas du tout prévu ça. Tu te retrouves à refaire cette pièce. Il faut qu’elle soit parfaite et surtout compatible avec le reste.
Le problème c’est que cette pièce est très compliquée à faire. Ça demande autant de temps que tout le meuble. Tu te retrouves bien dans la merde. Le chaos s’installe. Et avec ton meuble bancal, tu sais plus comment t’en sortir. Ton estimation de temps ne te fait plus rire quand les enjeux sont sérieux. Et c’est vraiment pas marrant quand ça atteint des cas extrêmes.
La tentative de la méthode agile
La méthode agile fait tous les efforts possibles pour contrôler le chaos. Dans les efforts remarquables, tu trouves l’itération de sprint pour trouver la cadence (ou vélocité) idéale d’une équipe. Et tu trouves surtout le fameux planning poker qui permet mine de rien de discuter et de réfléchir longuement, avec plein d’acteurs différents, avant de faire une estimation.
La méthode agile se base sur un système de point. Ce système de point n’est pas censé être une estimation de temps, mais une estimation de complexité de la tâche. Et on donne à chaque sprint un nombre de points.
Mais voilà, la méthode agile n’est jamais vraiment appliquée complètement. Et malgré tous les tours de pass-pass le projet a toujours une hard deadline. Dans 100% des entreprises où je suis passé, tout le monde traduisait l’estimation de points en estimation de temps. Ni vu ni connu l’estimation de temps était faite comme ça et l’illusion agile était parfaite.
C’est quoi la solution ?
J’ai pas de solution ! Ça fait cinq minutes que je t’explique que c’est le chaos. Bon par contre, tu me connais, j’ai toujours deux / trois conseils pour toi. Il faut apprendre à vivre avec le chaos au lieu de le défier.
Mon premier conseil est de ne jamais laisser ton égo prendre des décisions pour toi. Ne tombe jamais dans le « non, mais ça je connais, déjà fait, facile ». Tôt ou tard ça va se retourner contre toi. Demande toujours un temps de réflexion, prends ton temps pour faire des recherches, pose des questions, demande des clarifications et vérifie tout ce que tu peux vérifier. Investis-toi dans cette estimation. Ne te laisse pas aller à donner un délai ridicule par facilité et excès de confiance.
Second conseil : ne donne jamais un temps absolu. Donne toujours une fourchette de temps. Si tu estimes que ça va te prendre 2 jours, tu peux dire que ça va te prendre entre 2 et 4 jours selon tels critères et sous certaines conditions. Au-delà même du fait que tu te protèges, tu permets surtout à ton entreprise d’avoir des détails sur ta réflexion. D’avoir une vue sur les risques de ta tâche. Et si elle estime que les risques sont trop élevés elle pourrait ajuster les plannings en conséquence.
Enfin mon dernier conseil est de toujours donner une mise à jour en temps réel sur ton estimation. Si au bout d’un jour c’est le chaos total alors, dis-le tout de suite. Transparence totale. Va voir ton chef de projet et dis-lui qu’on est plus parti sur quatre jours de travail. Cette façon de faire à deux avantages. La première c’est que ton entreprise peut s’adapter en temps réel, voir même trouver des solutions en réduisant le scope. La seconde c’est que le fait d’être transparent va moins te stresser et du coup te rendre plus efficace.
Épilogue
Le Graal c’est d’être dans une entreprise qui ne fait pas d’estimation. Il parait que ça existe. Ces entreprises livrent des projets quand ils sont parfaits et du coup sans date particulière. Personnellement, j’ai jamais vu ça nulle part où je suis passé. Si toi non plus alors il est temps que tu acceptes la variable chaos dans ton travail de tous les jours. Elle sera toujours là.
Si ça existe : la fonction publique. Mais c’est sûr ça fait pas rêver🙂
Sauf que la fonction publique sous-traite un grand nombre de développement par un système de marché public. Le marché public est un système où l’on donne le travail à celui qui fait la meilleur blague…
Je travail dans la fonction hospitalière, et je par expérience c’est faux.
Attendre que le produit soit parfait? C’est pas possible, le décret dit que le changement est applicable à une date précise et on s’en fout que ça soit réalisable ou pas. On livre, on patch ensuite.
Je suis dans la fonction publique aussi, les deadlins sont fixées à l’avance car déployé en même temps que tous les autres dev, je connais la deadline avant même le scope!
La seule fois ou la deadline n’a pas été fixée, j’ai demandé 3 mois, on m’a changé le scope au bout d’un mois et on m’a raccourci le délais d’1 mois aussi…
Résultat, je suis tout le temps à la bourre… je zappe les commentaires, la doc, les tests unitaires (besoin « que » de 60%), les revues de codes…
Tu bosses pour les impôts ?
Je ne préfère pas répondre 😉 mais tu n’es pas loin.
Moi je parie sur l’Urssaf. Ça se voit que le site a été rush, la moitié des features sont « en construction » et tout pète de partout.
Tant mieux car les tests unitaires c’est de la merde
Mon Graal, c’est l’entreprise qui donne du temps pour étudier la complexité des tâches avant de se lancer dedans, et qui est capable de laisser tomber certains tickets si on a une date butoir non négociable. Genre : on livre et on y reviendra si ce ticket deviens indispensable.
Étudier un ticket n’est pas du temps perdu, c’est juste une manière de commencer le ticket jusqu’au moment de faire du code. C’est souvent un bon moyen de ne pas faire plus que prévu d’ailleurs. Concrètement, lister quelques scénario de tests, étudier quelques bibliothèque tierces à intégrer, rédiger une preuve de principe à l’arrache pour valider une hypothèse, rédiger approximativement une API (code, REST, CLI, etc.) .
Tout cela prends du temps, mais ce n’est pas du temps perdu (j’insiste) C’est du temps investi pour prioriser correctement et ne faire que ce qui est nécessaire.
Un autre conseil : bien choisir son unité d’estimation de temps. Si tu donnes une estimation en jours, on va s’attendre à une variation de quelques jours. Si tu donnes une estimation en mois, de même. Du coup, 40 jours, 8 semaines ou 2 mois, c’est pas la même chose quand on en vient à parler de retards.
Alors attention, il ya aussi les personnes à qui il faut expliquer le concept des jours ouvrés 🙂
Noublions pas : les devs sont des passionnés sans vie sociales (cf. https://www.jesuisundev.com/passion-developpeur/ )
Mon problème, c’est aussi en amont, pour SAVOIR estimer une tache… Quand je maitrise pas forcément les technos ou l’application, ou pire que je ne peux pas rechercher ou voir tous les impacts… Et je ne sais jamais comment, faire, toujours obligé de me mouiller (forcément ca foire)
Je trouve ca difficile d’estimer quelque chose qu’on a jamais fait… Comme changer une roue je sais pas… Aucune idée de combien de temps ca me prendrait, mais dès que je l’aurais fait une fois j’aurais plus d’élements pour répondre grâce à l’expérience…
On est arrivé sur un projet à ne pas faire d’estimations. Et beh c’est le paradis.
La non estimation (#NoEstimate) existe bel et bien. Fréderic Leguebois l’expérimente régulièrement.
Octo en a fait également un retour d’expérience sur 1an de projet : https://blog.octo.com/noestimates-un-an-de-projet-faisons-le-bilan/
Ce n’est pas Le Graal comme tu dis car si c’était si facile on le ferait tous, mais la réalité est qu’une estimation fait partie d’un système chaotique dont on ne pourra jamais tout prévoir. Pour preuve, cet effet se retrouve dans la météorologie où l’on est incapable de prédire avec certitude une variation sur plus de 2 semaines.
De mon côté, dès que je peux ne pas estimer, je le fais.
Après tout, l’être humain n’est pas fait pour sprinter mais pour marcher, nah ? 😀
>>Après tout, l’être humain n’est pas fait pour sprinter mais pour marcher, nah ?
Travailler en courant, que voilà une bien belle productivité. Cela me fait penser à ‘la flânerie systématique’ de Taylor.
C’est vrai qu’une fois que l’on te fait courir, il reste peu de place à la flânerie !
Merci pour ton article très intéressant.
Quand on a l’obligation de faire une estimation de durée, autant essayer de la faire correctement.
Pour cela il y a la méthode PERT qui a l’air intéressante : https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique#Time
En gros, on fait trois estimations de durée : le cas idéal, le cas « normal » et le cas où tout se complique. Ensuite, on applique un principe de probabilité pour trouver une durée moyenne avec un écart-type, par exemple 5 jours +/- 2
Sur un ensemble de plusieurs tâches, les cas optimistes et pessimistes « s’équilibrent »
Je ne l’ai utilisé que sur une durée relativement courte donc je n’ai pas de certitudes quant au fait qu’elle soit efficace ou non, mais je pense que c’est à creuser.
J’ai eu une fois un client sérieux au niveau des estimatios sur un très gros chantier. Refonte d’un système en place depuis 30 ans, utilisé par 1000 personnes. L’estimation et la planification en elles mêmes fut un projet qui a pris… 1 an ! Le projet total, comprenant l’estimation à pris 5 ans.
Ce client nous a payé un bras pour juste ça. Ça nous bien aidé et le projet s’est très bien passé même si malgré tout ces efforts en amont on a rencontré des difficultés assez sérieuses.
Ce qui a bien aidé c’est comme tu le dis la transparence. Dès qu’on avait une alerte significative, on en parlait avec eux. Les risques, on les prenait ensemble.
Aussi pour chaque jalon critique, on n’avait pas une deadline mais 2: la date cible et la vrai deadline du client. Ça aussi c’est super important.
Enfin un point qui n’a pas été mentionné ici mais super important : les 3 variables principales d’un projet sont coûts, délais, qualité. Une estimation ne sera pas la même suivant les attentes du client. Dans ce cas, c’était très clair que pour eux, délais et qualité étaient primordiaux, la variable d’ajustement était donc le coût.
Sinon accumuler de la dette technique, ça peut payer du moment qu’on en a conscience et qu’on la rembourse avant que les intérêts ne soient trop élevés.
En 15 ans ce fut le seul projet qui se soit aussi bien passé.
Ce que je retiens de cette expérience, si on veut une estimation sérieuse, faut y passer bien 20-25% du temps du projet.
En effet le triptyque qualité-coût-délai est super important. On peut fixer deux parmi les trois et utiliser le troisième comme variable d’ajustement. Bien que tous les clients veulent officiellement optimiser les trois, un ou deux paramètres sont en général plus importants (sauf si mauvaise foi ultime).
Il arrive souvent que l’on fixe les variables délais et coûts et que la variable d’ajustement devienne implicitement la qualité (moins de TU, de doc, de refacto etc. et un logiciel qu’il faut refondre au bout de 5 ans…)
Baaah j’ai trouvé une telle boîte. Je l’ai montée moi même et je suis seul dedans. Je tombe souvent en accord avec moi même notamment sur le planning. Les evol sortent when it’s done. Et comme je peux pas tout faire à la fois et que le moindre code dégueu va engendrer du chaos dans MON agenda et pas celui des glands qui vont récupérer mon dev à maintenir, j’ai peu voire pas de bug. Ou rien de grave en tout cas. J’ai une todolist plus longue que la bible, du petit détail au gros chantier et je prends ça dans l’ordre logique du moment, du jour, des 3 mois, de l’objectif de l’année prochaine etc. Jamais je n’irais développer dans une grosse boîte par contre… Plutôt mourir.
Il manque la règle de base qui permet de rendre les estimations viables :
1) prendre l’estimation « si tout se passe bien », et ensuite faire :
2) faire x2 pour la durée minimale qu’on annonce
3) faire x3 pour la durée maximale, en chaos d’ultra chaos ou de grosse refacto au passage.
Après 10 ans de dev dans 7 structures différentes, cette règle est toujours juste.
Ca choque toujours le PO/CdP : « QUOI ? 2 à 3 semaines pour 2 nouvelles pages et un formulaire ? Tu te fous de ma gueule ? » Mais au final, sur l’ensemble des sujets… ben ça tombe très souvent juste.
Après oui, du SCRUM bien appliqué (sprints verrouillés et limités, estimations et calcul de la vélocité) ça fonctionne mieux, mais dans la majorité des cas, SCRUM est très mal appliqué 🙁
Et comme le disait un super article lu il y a longtemps : « estimer, c’est deviner ».
Dans ma start-up actuelle, on n’a pas de deadline, pas d’estimations. On m’assigne une issue gitlab et j’ai toute la vie pour m’en occuper, en attendant qu’un de nos clients émette une éventuelle requête pour orienter les développements futurs. Du coup mon ticket, je le fais traîner sur 2-3 jours, puis j’attends… Finalement les deadlines et les estimations, ce n’est pas si mal 🙂
Ouais enfin non. Là tu décris un « besoin de flicage » et ce n’est pas le but d’une deadline.
Et malgré tout les tours de pass-pass / Et malgré touS les tours de pass-pass
my 2 cents
Je n’allais pas le faire, mais puisque quelqu’un a déjà relevé cette phrase en particulier : tours de passE-passE ^^
Hello,
Attention avec ce que tu appelles « la méthode agile ». Ce que tu décris là ressemble beaucoup à du Scrum. Scrum est une méthode agile mais pas l’unique méthode agile, loin de là (certains estiment d’ailleurs que Scrum n’est pas de l’agilité… 🙂 ) !
J’ai toujours un peu de mal avec les estimations parce que j’ai vu comment c’est utilisé contre les développeurs :
– les estimations faites en avant-vente sont faites pour être moins cher que le concurrent. En général, c’est connu côté commercial, il y a un choix de perdre de l’argent sur un projet pour gagner un client. Ils savent que les estimations ne sont pas tenables, n’en disent rien au développeur qui pour tenir, par ego, va faire gratos des heures supp’
– vu aussi, le chef de projet qui me file un projet estimé à 10 jours. Il y a une estimation qui a été faite en face de chaque tâche. En faisant l’addition, on était plutôt à 15 jours. Son explication était très vague, genre les estimations ont été faites il y a longtemps. La vérité probable, c’est que la boîte voulait se débarrasser de moi pour diverses raisons, et « ne tient pas les délais », ça le fait comme motif de licenciement.
– vu aussi, la demande d’estimation pour la correction d’un bug se produisant de façon aléatoire. J’admets que c’est chiant, ce gente de bug pour les chefs de projets, vu qu’en général quand tu peux estimer t’as déjà corrigé. Mais exiger une estimation impossible à avoir de la part de l’informaticien, c’est bien pour ne pas avoir à expliquer au client ou au n+1 qu’on ne sait pas. C’est beaucoup moins de boulot pour le chef de projet de donner une estimation complètement au pif, et charger le développeur si elle n’est pas respectée
et aussi, j’oubliais, c’est toujours le dev qui perd :
– si tu finis avant ton estimation, c’est que ton estimation était mauvaise
– si tu finis après, ton estimation était bonne, c’est juste que tu sais pas développer dans les temps
Heureusement, je suis maintenant dans une boîte qui respecte ses développeurs. Les estimations sont demandées pour anticiper sur la roadmap, pas pour être utilisées contre toi.
Un gros +1 à l’ensemble de l’article. En le lisant, je me disais à chaque paragraphe : « Put**n, mais c’est trop ça ! ».
Concernant les conseils pour les estimations, voici mes $0.02 :
– pour estimer une durée réaliste de réalisation d’une tâche, la méthode est :
1. estimer objectivement combien de temps ça prendrait en bossant normalement (pas à l’arrache, mais sans glander non plus), avec doc et tout le toutim et dans un contexte normal (soit quelques surprises par-ci parl-là)
2. doubler cette durée
3. arrondir à l’unité de temps supérieure.
Exemple :
1. estimation de 4 jours
2. on double : 8 jours
3. 8 jours ouvrés ==> on arrondit à 2 semaines
Autre conseil, c’est de rendre explicites certains petits détails qui sont souvent « oubliés » parce que ça arrange le commercial / CdP. Par exemple, si j’estime une tâche à 10 jours, je précise dans mon mail : « 10j à temps plein ». Je connais des arnaqueurs qui, en recevant une estimation de 10j le 15 du mois, s’attendent à une livraison le 25. Ou ceux qui chargent la mule avec des demandes sur un autre projet ou une autre tâche tout en considérant qu’on est toujours à 100% sur le projet initial.
Au final, si le sujet des estimations est aussi compliqué, c’est d’une partie à cause du chaos ambient, mais aussi souvent à cause de tout un tas de petits mensonges, de vérités cachées, de trucs qu’il faut pas dire au client, des petites malhonnêtetés : quand on sait que la moindre estimation va prendre un -25% d’entrée de jeu, ça fausse un peu les cartes.
Ce que tu cherches se trouve ici: https://www.youtube.com/watch?v=pLISFJM22ro
Le risque, c’est aussi de ne pas avoir de délais : plus tu as de temps, plus tu en consommes.
L’idéal est d’avoir un sprint avec 50 % du temps pour les tâches prévues et 50 % pour la dette technique / la maintenance. De fait, tu tiens ta promesse et en plus tu peux gérer ta dette technique correctement.
Une autre erreur classique, également portée par l’ego, c’est quand un dev prend du boulot en plus quand on lui donne plus de temps.
Très bonne synthèse
J’ai bossé sur un projet sans estimation, on avait des deadlines et un scope et on virait des éléments du sprint au fur et à mesure qu’il avançait, au final le backlog augmente de plus en plus et tu te perds dans ce qu’il te reste à faire; Et surtout tu finis par ne plus être stréssé, tu prends un temps fou à faire des taches simple. Et sans pression un développeur n’évolue plus!
Je ne partirai pas pour une traversée autour du monde avec toi… le bateau ne serait jamais assez grand pour emporter toute la nourriture pour l’equipage pour un voyage sans estimation de durée !! Il y a aussi bcp d’incertitude sur la météo l’état de la mer et la santé mentale des marins qui ne connaissent pas la durée du voyage!!
De mon côté ce qui m’arrive (en agence web) c’est d’entendre l’autre dev’ qui est là depuis 7ans ans contre 5 mois pour moi, que mon estimation est « trop longue que c’est easy » ou alors d’entendre le chef de projet dire « on ne va pas estimer cette tâche à autant d’heure pour le client ».
Du coup je me retrouve à donner des estimations de baisé et du coup je stresse en me demandant avec combien de temps de retard je vais livrer cette tâche
Une grosse entreprise sans estimation de temps rigide je sais pas si ça existe car dans la gouvernance les deadline c’est la base. Mais personnellement je suis dans une team au sein d’un grand groupe, et a mon niveau on n’en a pas vraiment.
On ne pose pas de dates, on prévoit seulement la liste des évolutions qu’on souhaite, on les classes par priorité (bien sûr en prenant en compte le rapport gain/complexité a priori), et après on dépile la liste en prenant le temps qu’il faut. Techniquement il y a toujours un semblant de deadline mais c’est surtout dans les outils et les rapports pour la haute hiérarchie et ça concerne surtout les bug et les hotfix a faire au plus vite, car en pratique on se contente de faire des gros packages avec une deadline par semestre dans lequel on met rarement tout ce qui a été envisage/estimé.
Ça n’empêche pas pour autant de re-éstimer très régulièrement tout ça, car c’est que sur le tas que tu te rend compte de plein de trucs et si il faut les priorité ça se change et pour ça pas de miracle il faut en discuter.
Donc c’est possible, et dans une grosse boite bien rigide, même si c’est je pense plus le fait du management a mon niveau que de l’entreprise.
Du coup