Non, cela demande encore moins d’efforts que ça
(smartguess.is)- Lorsque des personnes extérieures à l’équipe de développement font pression pour réduire une estimation sans apporter de nouveaux faits, l’estimation devient comme un objet de négociation, ce qui dégrade à la fois la confiance et la qualité de la planification agile
- La charge réelle de travail ne peut généralement pas être réduite à volonté par l’équipe de développement, et l’équipe estime l’effort attendu en s’appuyant sur la vélocité de l’équipe, les données des stories terminées et le débit actuel
- Si l’on saute des étapes du processus ou que l’on baisse la qualité pour faire correspondre une estimation plus basse, le calendrier peut sembler raccourci à court terme, mais cela risque d’entraîner un coût bien plus élevé par la suite
- Une conversation plus productive ne consiste pas à dire « estimez plus bas », mais à examiner ensemble le budget, les parties les plus chronophages, les grandes inconnues, les alternatives, ainsi que le découpage des stories et la validation précoce
- Si l’on baisse uniquement les chiffres alors que le périmètre fonctionnel reste fixe, on crée chez le client de fausses attentes sur la date de livraison, et il faut discuter de l’exclusion des fonctionnalités à effort élevé et à faible valeur
Les distorsions créées par la pression sur les estimations sans faits nouveaux
- Il arrive souvent que des parties prenantes extérieures à l’équipe de développement, avec une connaissance technique ou une compréhension limitée de la base de code, cherchent à faire baisser les estimations en disant : « Non, cela demande encore moins d’efforts que ça »
- En apparence, elles demandent une « meilleure estimation », mais en réalité, elles veulent souvent une estimation plus basse
- Lorsqu’on traite les estimations comme des chiffres négociables, les parties prenantes comme l’équipe de développement aboutissent à un compromis insatisfaisant, et l’entreprise se construit de mauvaises attentes sur le moment où elle pourra livrer le logiciel au client
- Source de la citation associée : Is tasking developers with creating detailed estimates a waste of money?
L’estimation relève davantage de la prévision que du contrôle
- Il existe des cas où l’on peut contester une estimation
- lorsque l’équipe de développement discute de la story en interne
- lorsqu’il existe de nouveaux faits ayant un impact sur la charge réelle de travail
- Lorsqu’une partie prenante extérieure qui ne comprend pas les détails d’implémentation et n’apporte aucune nouvelle information demande une estimation plus basse, c’est un peu comme dire à un météorologue : « Les prévisions de demain sont fausses, il fera meilleur »
- Un météorologue ne contrôle pas la météo : il établit des prévisions à partir de ses connaissances et des données d’observation
- De la même manière, l’équipe de développement ne contrôle quasiment pas la charge réelle de travail et estime l’effort attendu à partir de ses connaissances et des données
Ce que l’équipe de développement peut et ne peut pas contrôler
- L’équipe de développement estime en s’appuyant sur une vélocité d’équipe établie, sur les données de revue des stories terminées, et sur un processus qui s’améliore à chaque sprint
- Il est possible de réduire la charge apparente en sautant certaines étapes du processus et en livrant un logiciel de moindre qualité
- ce n’est pas une approche recommandée
- elle entraîne souvent un coût plus élevé plus tard
- L’équipe peut avoir une marge de progression en matière de vitesse, mais au moment de l’estimation, elle doit se baser sur le débit actuel, et non sur un débit futur espéré
- Si, dans l’entreprise, la discussion dérive vers l’idée qu’« il suffit de travailler plus longtemps », alors l’environnement ressemble fortement à une recette pour le désastre
- Trois commentaires Reddit sont liés comme retours d’expérience :
Les conversations à avoir au lieu de rogner les chiffres
- Le développement logiciel est complexe et prend souvent plus de temps que les gens ne l’imaginent
- Si les parties prenantes considèrent qu’elles ne peuvent dépenser qu’un certain montant, au lieu de réduire l’estimation, il faut discuter des points suivants
- combien peut être dépensé pour cette story
- quelle partie de la story prend le plus de temps
- où se trouvent les plus grandes inconnues
- quelles alternatives existent pour traiter les parties chronophages et les inconnues
- Il faut aussi examiner les options permettant de modifier la manière de valider et de livrer
- découper la story pour la livrer en plusieurs parties
- valider chaque partie le plus tôt possible
- si possible, valider au moyen d’un prototype
- Il faut en particulier chercher à exclure de la story les fonctionnalités qui demandent beaucoup d’effort tout en apportant le moins de valeur
Reformuler les questions de planning de manière plus utile
- Il est plus productif de poser des questions qui clarifient la relation entre fonctionnalités, calendrier et périmètre, plutôt que de demander une estimation plus basse
- Les questions suivantes, traitées dans un autre article, sont liées
- Quand peut-on livrer la fonctionnalité A ?
- Que peut-on livrer d’ici la fin du prochain trimestre ?
- Peut-on livrer la fonctionnalité A d’ici la fin du prochain trimestre ?
- Article lié : converting story points to hours
2 commentaires
Si on traduit le titre original de l’article avec DeepL, ça donne ceci :
« Non, ça demande encore moins d’effort que ça ! », dit-il ?
Commentaires Hacker News
L’analogie selon laquelle « mettre la pression à un commercial pour qu’il augmente ses ventes/son quota, c’est comme demander du soleil à un météorologue » ne semble pas si injuste dans ce contexte
En réalité, cela revient plutôt à demander de travailler plus efficacement pour terminer la même chose plus vite
Si l’on demande à un commercial de fixer lui-même son quota, comme conclure des contrats implique beaucoup de complexité et d’inconnues, il choisira un chiffre prudemment atteignable afin de ne pas paraître en échec
Mais ce chiffre peut être inférieur à ce dont l’entreprise a besoin, et c’est pour cela qu’on propose un quota plus élevé en le poussant à l’atteindre, quitte à forcer un peu
C’est d’autant plus important si la rémunération est directement liée à l’atteinte de ce chiffre
Pourtant, les commerciaux n’écrivent pas sans cesse des billets disant que « les quotas fixés par soi-même sont sacrés, que seuls les commerciaux doivent les définir, et que la direction est ignorante si elle demande des performances supérieures »
Une analogie plus proche serait qu’une équipe commerciale dise, à propos d’un deal donné : « 70 % de chances de le conclure, environ 5 millions de dollars de revenus récurrents annuels », et que la direction réponde : « Est-ce qu’on peut en faire 80 % et 7 millions ? »
Il peut être possible d’augmenter à la fois la probabilité de signature et le prix, mais comme pour terminer une fonctionnalité en deux fois moins de temps, cela exige quelque part un changement ou un compromis majeur
Mais plutôt que de transformer les estimations en objectifs souhaités, il vaut bien mieux terminer plus vite que l’estimation
Le mieux est d’ordonner les tâches en tenant compte des priorités et des prérequis, de disposer d’assez de stories prêtes pour le développement, et, en cas d’urgence, d’assigner stratégiquement les tickets en acceptant le coût à long terme d’une concentration des compétences dans l’équipe
Sous contrainte de temps, il faut retirer de toutes les fonctionnalités ce qui relève du « nice to have » ou le repousser en bas du backlog, et limiter strictement dans le temps les consultations avec d’autres équipes ou des experts externes
Il faut supprimer les réunions et interruptions inutiles, permettre aux développeurs de refuser des réunions ou de bloquer leur calendrier, et relever le seuil des refactorings aux cas où le rapport coût/bénéfice avant l’échéance est clair, comme une façon d’emprunter à l’avenir
En revanche, il faut faire très attention à ne pas transformer cette approche en mode de travail standard
Si l’on peut convertir 10 % des leads, alors lorsqu’il faut 5 conversions au lieu de 4, il suffit en gros d’appeler 10 personnes de plus
Une meilleure comparaison avec le logiciel serait de construire un nouveau type de bâtiment, par exemple une maison en dôme géodésique, sans expérience préalable et sans bien connaître les problèmes qui vont se présenter
Et là, on vous demande une estimation précise, puis on vous met la pression pour la réduire encore
Le plus important est de tromper les clients, et je ne parle pas simplement d’une « exagération ordinaire bonne pour l’entreprise »
Cela consiste à faire des promesses que l’entreprise ne peut pas tenir, ou à vendre de futures fonctionnalités qui imposeront une marche forcée sacrifiant la qualité et la durabilité
Même si les C-level ne le voient pas, les conséquences se produisent quand même
Cela ne veut pas dire qu’il faut croire aveuglément les estimations des développeurs, mais c’est un terrier de lapin encore plus profond et je suis trop fatigué pour m’y engager maintenant
Cela rend simplement la compréhension du calendrier plus irréaliste
Il est tout à fait possible de trouver d’autres solutions créatives au même problème, ou de comprendre quelle portée peut être réduite pour atteindre l’objectif
Mais c’est complètement différent de « faites exactement la même chose, juste plus vite »
Quand il est question d’estimation, les développeurs se mettent rarement à la place du business, et cherchent souvent peu à comprendre pourquoi les estimations sont nécessaires ni pourquoi une estimation courte est toujours préférable à une longue
À la place, ils tentent de protéger le sanctuaire qu’est le développement logiciel, et creusent encore l’écart entre les ingénieurs et « les autres »
C’est là que transparaissent le cynisme et le sarcasme, ce qui finit par mener à des estimations irréalistes
J’ai été développeur, PO, manager, directeur, jusqu’à CTO, mais je reste surpris de voir à quel point la plupart des développeurs sont déconnectés de la réalité de la création de valeur et de la dimension temps
En tant que développeur, c’est même une chance qu’on vous demande combien de temps cela va prendre, et qu’on vous donne l’occasion d’expliquer, de contester et de défendre votre estimation
La triste réalité, c’est que les développeurs sont souvent mauvais pour participer à des discussions de niveau business et exprimer leurs réflexions, idées, inquiétudes et propositions afin que les PM et les managers voient la complexité du travail et puissent avoir une discussion saine sur le coût/bénéfice
Il faut regarder si le lead dev participe aux réunions business, si l’équipe de développement voit les chiffres et les budgets, participe à la roadmap et prend part aux recherches utilisateurs et aux brainstormings de fonctionnalités avec les équipes business/UX
Si ce n’est pas le cas, il est difficile de s’attendre à ce que les développeurs comprennent le business
La séparation développement/business fait que chacun reste dans son silo en espérant qu’un autre spécialiste comprenne bien ses problèmes, et conduit à la sacralisation du développement logiciel
Beaucoup d’entreprises ne font que fonctionner malgré des rôles extrêmement cloisonnés, mais comme l’argent continue de rentrer, elles semblent croire que cette façon de faire est acceptable
La plupart du temps, quelqu’un veut juste mettre un chiffre dans un PowerPoint de politique interne
Parfois, il s’agit de décider entre faire A ou B, et dans ce cas seule une estimation relative est légitimement nécessaire, jamais une estimation absolue
Il arrive qu’il y ait une vraie deadline, mais même là, ce qu’il faut, ce n’est pas une estimation, c’est « peut-on tenir cette date ? » ou, plus utile encore, « que faut-il faire pour tenir cette date ? »
Travailler aussi près que possible du business est une bonne chose, et la raison pour laquelle on utilise du logiciel au départ est généralement de répondre à un besoin business
Mais sur les estimations, il arrive vraiment souvent qu’ils aient tort et que nous ayons raison
Si plus court est toujours mieux, alors disons désormais que toutes les estimations sont d’un jour : est-ce vraiment mieux ?
Si un développeur peut écrire du code, estimer et livrer selon le calendrier business, alors ce n’est pas un employé, c’est un fondateur
Ce qu’ils veulent, ce sont des naïfs qui livrent comme des fondateurs sans toucher de participation aux bénéfices
Peu importe l’effort que vous ou moi y mettons, le bébé n’arrivera pas plus vite
Il n’y a rien d’ambigu là-dedans
Le mécontentement vient de la formulation qui fait comme si les développeurs pouvaient savoir quand ce sera terminé
La capacité de quelqu’un à livrer rapidement de la valeur est distincte de sa capacité à estimer le temps que cela prendra
On peut livrer beaucoup de valeur même en se trompant complètement d’estimation
S’il existait réellement une méthode pour estimer le temps que prendra un travail logiciel, les entreprises embaucheraient des estimateurs professionnels, comme elles ont des équipes produit
Il n’y aurait aucune raison de le demander aux développeurs
Bien sûr, personne d’autre ne sait le faire non plus, et les développeurs donnent au moins une borne basse, donc on continue de les harceler, mais le processus lui-même est manifestement idiot
Pour savoir combien de temps prendra quelque chose, il faudrait énumérer toutes les étapes nécessaires pour le faire, ce qui est impossible dans le développement logiciel
Un développeur peut fournir une borne basse pour des exigences données, et si absolument rien d’imprévu ne se produit, l’estimation pourrait être exacte, mais dans 95 à 98 % des projets, l’estimation sera inférieure à la réalité
Au final, « l’estimation du développeur » devient une mesure du niveau de marge de sécurité que le développeur veut mettre dans ce projet
Demander une estimation cadre complètement mal la discussion
La vraie question devrait porter sur les contributions du développeur concernant le problème que le business a aujourd’hui, celui qu’il risque d’avoir dans six mois, et le rapport coût/efficacité de sa résolution
Ensuite, il faut prendre des décisions qualitatives visant à réduire le risque
Le meilleur résultat d’une estimation logicielle est que tout le monde l’ignore et l’oublie ; tous les autres résultats détruisent de la valeur business
Je comprends l’idée, et dans une organisation où il y a des parties prenantes irresponsables, le risque réel est aussi important
Cela dit, l’analogie avec le météorologue n’est pas très bonne
Le cœur du métier d’un météorologue est de prévoir le temps, alors qu’un développeur ordinaire est quelqu’un qui travaille dans ce temps-là, avec relativement peu d’expérience en prévisions précises
Ce qui frustre les parties prenantes, ce sont des estimations absurdes qui ne commencent même pas par le temps de travail et ne se terminent pas par un délai réaliste
C’est particulièrement vrai au niveau des micro-tâches : il arrive qu’une tâche de 30 minutes maximum, que l’on pourrait faire soi-même plus vite avec les bons accès, revienne avec une estimation de plusieurs semaines
Même lorsqu’elle crée un coût opérationnel important et entre dans la catégorie « il faut tout arrêter pour s’en occuper »
Bien sûr, une tâche de 30 minutes ne prendra pas vraiment seulement 30 minutes à cause des tests et de la documentation, mais plus l’estimation ressemble à n’importe quoi, plus la relation de confiance est abîmée
Demande-t-on le temps de travail effectif nécessaire pour une tâche donnée, ou le temps écoulé entre maintenant et le moment où elle sera déployée ?
Dans presque toutes les équipes, les deux sont dominés par le temps où le travail attend quelque chose, mais c’est particulièrement vrai dans le second cas
Le temps réellement passé au clavier est généralement une erreur d’arrondi par rapport à la coordination et à la planification
Si l’équipe n’a pas beaucoup investi dans des modes de travail contre-intuitifs, le ticket moyen attend énormément plus longtemps qu’il n’est effectivement travaillé
De plus, l’équipe ne voit pas du tout ce déséquilibre et ne se rend même pas compte que c’est important
On veut corriger vite et passer à autre chose
Le problème, c’est que sans déploiement continu entièrement automatisé, 30 minutes ne sont pas 30 minutes
Cette tâche de 30 minutes doit être vérifiée pour s’assurer qu’elle n’affecte pas d’autres départements ; il faut coordonner le calendrier, communiquer, déployer, et 2 ou 3 personnes de plus peuvent se retrouver impliquées
Si c’est une intervention planifiée, on approche des 2 heures réparties entre plusieurs personnes ; si c’est un hotfix ou un ticket de support, et qu’il existe un processus QA au-delà des tests automatisés, cela représente 4 à 6 heures de perte de productivité
Ajoutez à cela six autres personnes qui demandent une « tâche de 30 minutes » dont l’impact sur d’autres personnes dans l’entreprise n’est pas clair, et plus rien ne se termine
Notre équipe a bien un flux de hotfix, mais il doit s’agir d’une urgence qui bloque réellement les opérations de l’entreprise
À part les cas absolument évidents, la demande doit venir au minimum d’un responsable de département
Le préjudice causé par une correction pour une seule personne qui crée des problèmes à plusieurs autres, ou qui empêche de finir un grand projet stratégiquement important, est bien plus important que celui de ne pas traiter immédiatement tous les tickets urgents
Il doit bien exister dans l’organisation un moyen d’accorder les accès nécessaires
Si la réponse ressemble à « ce n’est pas mon travail », alors cette organisation valorise une structure de pièces interconnectées aux responsabilités strictes
Dans ce type d’organisation, il est normal que le coût de communication domine entièrement la performance de production
Quand c’est bien coordonné, la qualité peut être bonne, et si les rôles sont clairs, le débit peut aussi être élevé, mais vous n’obtiendrez jamais une faible latence
Le temps de réponse est sacrifié au profit d’autres choses
Dans une telle structure, obtenir une estimation d’une semaine pour une tâche triviale est aussi prévisible
Avec un planning déjà plein, une nouvelle tâche a de fortes chances de n’être affectée que plusieurs semaines plus tard, et si la granularité des responsabilités impose deux personnes ou plus, les temps d’attente s’additionnent
Si cela ne convient pas au travail à faire, c’est l’organisation elle-même qui n’est pas adaptée à ce travail
C’est inefficace pour toutes les personnes concernées
Notre équipe dispose d’une grande autonomie, et personne ne compte nos heures ni ne mesure notre productivité de l’extérieur, mais quand c’est nécessaire, nous n’avons pas le temps de peaufiner le code
Quand je vois une tâche de « 30 minutes », je la mets dans la revue du matin et, quand quelqu’un touche au sujet, je demande s’il faut aussi traiter ce qui est adjacent
Même s’il n’y a rien, je prévois une journée ; pour un projet que je connais très bien, je prévois une demi-journée
Une demi-journée sert à parcourir le code, et l’autre moitié à faire de petites mises à jour : commentaires, montées de version, améliorations du code, renommages de variables, etc.
Je pense qu’il est plus efficace en temps d’inciter aussi les contributeurs individuels à fonctionner ainsi
Pour un nouveau contributeur individuel, ce temps lui permet d’apprendre le vieux code, et au final, tant qu’il ne fait pas de gros changements, cela réduit aussi les problèmes de legacy
La seule baguette magique en développement logiciel, c’est la simplification des exigences
Les exigences sont toujours fausses
Elles sont trop larges, trop floues, ou fondées sur de mauvaises hypothèses
La vraie grande compétence consiste à abandonner certaines hypothèses et à proposer une solution simplifiée
C’est la meilleure et la seule façon de raccourcir les délais
Quand les exigences sont simples, elles ont plus de chances d’être complètes et exactes, mais les vraies exigences ne peuvent pas toujours être simplifiées
Dans ce cas, ce qu’il faut, c’est une meilleure spécification
« They write the right stuff », sur le groupe logiciel de la navette spatiale, raconte essentiellement ce genre de travail : https://www.fastcompany.com/28121/they-write-right-stuff
La plupart des bugs logiciels sont en réalité des bugs d’exigences, et quand on dispose de bonnes exigences, la vitesse à laquelle on peut produire du logiciel devient absurdement élevée
J’ai vu un projet partir d’un dépôt vide et arriver en production en deux mois grâce à des exigences parfaitement claires et stables
À l’inverse, j’ai aussi vu une fonctionnalité d’environ 30 lignes traîner pendant des mois à cause d’exigences floues et sans cesse changeantes
On explique qu’il n’y a pour l’instant que quelques dizaines d’éléments, mais qu’il y en aura des milliers dans quelques années
Le designer conçoit tous les parcours de recherche à partir d’un document d’exigences produit de 20 pages, puis ce n’est qu’une fois toute la planification et la préparation terminées qu’on fait venir l’ingénierie pour écrire les stories et estimer le travail
Ils ont généralement suffisamment de connaissance du domaine et savent, dans ce contexte, ce qu’il faut pour construire quoi
Il est utile de discuter de la manière de modifier le périmètre afin d’obtenir un équilibre coût/bénéfice adapté aux parties prenantes
J’ai vu des cas où les développeurs partaient du principe que cela demanderait trop de travail, et des cas où des non-développeurs ignoraient les éléments clés qui allongeaient les délais
Parfois, on essaie de construire une solution généralisée, alors qu’en réalité il suffirait peut-être que quelqu’un passe une journée assis devant une feuille de calcul à traiter le problème
Le fait qu’on remette souvent en question les estimations jugées trop élevées, mais presque jamais celles jugées trop basses, est précisément l’un des points que le planning poker cherche à traiter
L’idée est que chacun indique la difficulté d’une tâche sans être influencé par les autres, puis qu’on discute lorsque les attentes divergent
Il y a de fortes chances que quelqu’un ait raté quelque chose
Si je pense qu’une chose est simple, c’est peut-être aussi parce que j’ai raté la partie complexe du problème, ou parce que je vois une solution plus propre
Un bon exemple, c’est lorsqu’un client formule une exigence mathématiquement ou physiquement impossible
On peut faire du planning poker toute la journée autour de ce souhait, on risque quand même d’arriver à un compromis toujours impossible
Quand j’étais freelance, je préférais écouter une explication approfondie du problème, regarder par-dessus l’épaule de la personne qui le résolvait actuellement si nécessaire, puis disparaître quelques jours avant de revenir avec la conception qui me semblait la plus élégante et la plus fiable
À moins d’avoir beaucoup d’expérience avec des problèmes complexes, la plupart des gens savent plutôt bien expliquer leur problème, mais pas proposer une solution
Parce que leurs solutions prennent toujours pour modèle les choses limitées qu’ils connaissent
J’ai vu beaucoup d’exigences étranges construites uniquement par empilement d’hypothèses de plusieurs personnes, alors qu’en réalité personne ne les avait demandées
Par exemple, construire une architecture de microservices infiniment scalable et une application monopage complète pour permettre à une douzaine d’utilisateurs internes de télécharger des données dans une feuille de calcul Excel
Il suppose que l’équipe connaît suffisamment bien l’ensemble des fonctionnalités et comprend comment utiliser le système pour gérer les écarts inévitables, du genre A fait X et B fait X*3
Il suffit de voir les discussions sur la mauvaise mise en œuvre de Scrum pour constater que ces hypothèses ne sont absolument pas garanties
Cela ne tient pas non plus compte du fait que, avec les départs et les nouvelles fonctionnalités, une équipe peut s’éloigner de ces hypothèses à tout moment
Trop souvent, on finit simplement à se regarder en haussant les sourcils, jusqu’à ce que « X s’en chargera, donc l’estimation de X fait foi », ou bien on prend la moyenne/le minimum, ce qui pénalise seulement la personne qui avait estimé plus haut
Dans ce cas, je ne vois pas pourquoi on fait du poker au départ
C’est encore plus machiavélique que ça
L’intermédiaire veut un accord où pile je gagne, face tu perds
Il veut tirer profit d’un chiffre bas pour convaincre son interlocuteur de son côté
Il utilise donc toutes sortes de techniques pour amener le développeur à dire le chiffre qu’il veut entendre, sans que cela ressemble à un ordre ou à une contrainte
Si cela en avait l’air, ce chiffre deviendrait le sien et toute la manœuvre s’effondrerait
Mais si, inévitablement, cela prend beaucoup plus longtemps, il pourra pointer du doigt le chiffre fourni par le développeur et dire qu’il n’a fait que transmettre ce qu’on lui avait dit, et qu’il n’est donc pas responsable
Le seul langage que ce genre de personne comprend consiste à faire en sorte que le résultat de toute demande de « révision » d’estimation aille toujours à la hausse, pour faire passer le message
D’abord, les estimations devraient être utiles pour que le business s’adapte, mais dans la réalité il ne s’adapte pas du tout
Le PM subit la pression de son propre supérieur pour livrer avant une échéance approximative
Si mon estimation ne compte de toute façon pas, pourquoi estimer ?
Ensuite, l’équipe n’a aucun intérêt à estimer de manière réaliste
Est-ce qu’on reçoit une médaille si on est exact ? En pratique, toutes les incitations poussent à gonfler la charge via les estimations
Enfin, toute cette danse et ces rituels autour des estimations ne sont rien d’autre que quelque chose que les managers adoptent pour paraître plus efficaces et influents qu’ils ne le sont réellement
Quand j’étais ingénieur, je disais fermement : « Il n’y a pas moyen de faire ça plus vite, donc n’essayez pas de me mettre la pression pour obtenir le chiffre que vous voulez entendre »
Ce sera terminé quand ce sera terminé, je le rendrai solide et en bon état, alors laissez-moi travailler
Mais quand, en tant que manager, j’ai poussé pour une estimation plus petite, c’était parce que, compte tenu de la réalité business, l’essentiel était de livrer quelque chose dans le délai imparti
Même s’il fallait bâtir un château de cartes et couper les coins, il fallait au moins survivre assez longtemps pour traiter ce problème plus tard
À ce moment-là, l’ingénierie a réagi comme je l’aurais probablement fait si j’avais été à leur place
En disant que c’était une idée catastrophique, que cela nous mènerait à l’échec plus tard, et qu’il fallait faire le travail de terrain maintenant pour éviter la douleur future
Je suis redevenu ingénieur, mais mon expérience de manager m’aide beaucoup à gérer ce genre de décalage
Ce sont des gens qui « montent jusqu’à 11 »
Comme l’ampli de Spinal Tap, si vous réglez habituellement la puissance maximale sur 9, il reste une graduation de plus à monter quand ils le veulent
Bien sûr, cela signifie qu’on travaille plus lentement qu’on ne le ferait autrement
Mais si l’on veut un développeur qui « monte jusqu’à 11 », il est clair qu’il n’y a qu’une seule façon de faire qui fonctionne
Mon manager et son manager au-dessus sont exactement comme ça : ils imposent des échéances arbitraires non pas parce que le client attend, mais pour bien se faire voir de leur propre supérieur
Quand l’estimation échoue inévitablement, tout le monde lève les mains et commence à placer des gens en plan d’amélioration des performances à cause de leurs propres mauvaises estimations
En tant qu’ingénieur, qu’est-ce qu’on gagne à vivre sous ce stress permanent et à rater du temps avec sa famille et ses amis ?
Seulement à faire paraître bonne l’estimation incompétente de son manager
L’une des vieilles ficelles consiste à créer une vision, à faire des promesses, puis à dire : « J’ai fait mon travail, maintenant il faut que l’ingénierie fasse le sien »
Je repense à un manager qui ajoutait des fonctionnalités sans prévenir alors qu’on était en train de finaliser une release, parfois quelques heures avant
Il ajoutait même des fonctionnalités à des releases déjà terminées
Dans sa tête, il semblait suffire d’attacher une fonctionnalité à une release pour que ce soit immédiatement terminé
La plus grande difficulté, c’est que les gens demandent immédiatement une estimation alors que le projet tient à peine en un paragraphe d’explication.
En plus, on a toujours l’impression que « ça dépendra de la quantité de dette technique qu’on découvrira après avoir regardé le code ».
Jusqu’ici, la seule réponse raisonnable que j’aie donnée était : « il me faut 1 à 2 jours pour vous pousser à solidifier les exigences, puis mettre la codebase en pause avant de commencer afin de l’auditer et d’identifier les risques ».
Peut-on faire mieux que ça ?
L’objectif n’est pas de produire des cartes parfaites, mais de créer au moins un ticket pour tout ce qui semble devoir être fait dans le projet.
On se retrouve alors avec plusieurs cartes d’une ligne du type « créer un endpoint d’API de création en masse », « migrer les données de l’ancienne table vers la nouvelle ».
S’il y a 5 cartes ou plus, j’estime avec
((nombre de cartes / nombre de développeurs) * jours ouvrés estimés par carte) + jours de congé prévus.Ce ne sera pas exact, mais le PM et son supérieur auront le sentiment que l’estimation a été réfléchie et raisonnable à ce moment-là.
Si un retard devient nécessaire plus tard, il est aussi facile d’expliquer : « nous avons supposé que toutes les cartes prendraient un nombre de jours similaire, mais ces deux-là se sont révélées être des valeurs aberrantes plus grosses que prévu ».
C’est assez proche du processus de sprint habituel, mais il n’est pas nécessaire de suivre la vélocité de sprint autrement qu’à l’intuition.
La direction de l’entreprise demande des estimations avec très peu d’informations, et quand on dit qu’il faut en savoir plus et regarder la codebase, elle répond qu’elle a « simplement » besoin d’une estimation pour décider s’il faut approuver ce travail et lancer le projet.
On tourne en rond comme ça, puis on finit par donner une grosse estimation, qui est élevée à cause de toutes les inconnues, y compris ce dont on ne connaît même pas le périmètre.
Et là, pour la direction, c’est trop gros et trop cher.
En termes Agile, c’est un ticket de spike à 3 points, dont le livrable est constitué d’exigences détaillées, de livrables et d’estimations, accompagnés des compromis envisagés.
C’est une façon de faire tout à fait normale.
Tu peux donner une estimation avant le spike, mais il faut la qualifier autant que possible.
Par exemple : « moins de 3 semaines avec 60 % de confiance, 5 semaines avec 80 % de confiance, 6 semaines avec 90 % de confiance ».
En général, je refuse les estimations d’échéance au-delà de 1 à 2 semaines, et je privilégie autant que possible des estimations par morceaux.
Par exemple : « ce projet se compose de 7 livrables, chacun demandant 1 à 2 jours de travail ».
Une tâche peut très bien représenter 10 jours de travail d’ingénierie, mais le calcul d’une date de livraison devient en pratique dénué de sens pour des raisons comme des changements de priorité.
Si les « managers » ne comprennent pas ça, il sera malheureusement difficile d’avoir la paix.
Ne pas se soucier de la dette de code ni de la qualité, et sortir en urgence quelque chose qui marche à peine.
Ils seront satisfaits.
La scène de hacking typique d’un film d’action ressemble à ça.
Chef : « Combien de temps pour hacker le mainframe ? »
Technicien : « Le hacker en face est vraiment très bon, donc au moins 2 heures. »
Chef : « Je vous donne 1 heure. Faites-le. »
Puis on vole à travers un système de fichiers en 3D.
Chaque fois que je vois ce genre de scène, j’ajoute mentalement une narration au technicien :
« L’estimation réelle était de 20 minutes. Je finirai probablement vers 50 minutes, puis je volerai encore 10 minutes dans le système de fichiers 3D pour avoir l’air occupé et éviter que le chef ait des idées bizarres. »
Ce n’est pas tout à fait vrai.
Beaucoup de fonctionnalités peuvent être construites à plusieurs niveaux, depuis une version très squelettique jusqu’à une version entièrement plaquée or.
Parfois, un collègue développeur estime à 2 semaines une fonctionnalité qui, de mon point de vue, prendrait au maximum une journée, parce qu’il suppose beaucoup de fonctionnalités supplémentaires qui n’ont pas vraiment été demandées, ou parce qu’il sait quelque chose dont je ne savais pas qu’il fallait tenir compte.
Quand on te demande de modifier une estimation, vois cela comme une invitation à discuter un peu plus des exigences et de l’implémentation proposée.
Il existe peut-être une solution beaucoup plus simple, qui atteint 90 % du résultat et qui serait acceptable.
Un météorologue n’a pas cette option.
La différence entre jeter un combo box / select de base et créer un élément d’interface utilisateur personnalisé beaucoup mieux adapté à la situation ne passe pas bien auprès des gens hors IT.
On peut l’expliquer avec des schémas, mais tant que les parties prenantes ne le voient pas et ne le manipulent pas, elles ne savent toujours pas ce qui se passe.
Il faut donc, la plupart du temps, le rendre réellement fonctionnel pour le leur montrer.
Il y a des clients qui demandent « faites le plus simple possible », puis à qui l’on montre une GUI prototype, une GUI avec le design final, puis le prototype, et qui approuvent sans même regarder les deux premières.
Si on insiste, ils manipulent le prototype et disent quand même « c’est bien, on continue », puis après avoir utilisé la version qui fonctionne vraiment sur le serveur de test, ils disent : « ce n’est pas ce qu’on voulait dire ».
J’ai vu ça aussi bien avec des boutiques familiales tenues par deux conjoints qu’avec des entreprises du Fortune 500 où un directeur régional et un CTO global donnaient leur avis.
Là, je parle du frontend ; le backend et le DevOps posent encore des problèmes totalement différents, mais là aussi l’écart est énorme entre une version squelettique et une version plaquée or.
Maintenant que je connais ce jeu, je gagne aujourd’hui beaucoup d’argent avec ce processus cassé.
En 1975, Fred Brooks a écrit :
« Mettre au monde un enfant prend 9 mois, quel que soit le nombre de femmes qu’on y affecte. »
Il n’y a pas de meilleure formulation.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Chaque personne ajoutée rallonge le délai.
La livraison la plus rapide, c’est de ne pas déranger un développeur solo et de le laisser travailler.