Discussion :

[Patrick Ruiz]

Charger les développeurs d'estimer les délais dans le détail est une perte de temps et d’argent
D’après un contributeur d’un institut en techniques de gestion des logiciels

Dans une ère où le numérique occupe une place de choix dans les cultures du monde entier, les métiers du génie logiciel bénéficient d’une forte demande en applications de toutes sortes. Dans le processus de mise sur pied de ces dernières, une étape cruciale est à franchir : celle d’estimation des délais de réalisation des tâches qui impacte sur le respect du calendrier de livraison au client. Les travailleurs de la filière informatique sont pour la plupart d’accord sur un point au sujet de cet exercice : ses retombées (les estimations des délais) sont en général plus trompeuses qu’autre chose. Une publication parue sur une colonne d’un institut de gestion des logiciels tente son essai d’explication de cet état de choses…

Ce qui ressort en premier de cette publication est que l’estimation des délais est faussée à la base en raison de la manière dont certaines équipes de développement la mènent. Le problème en toile de fond est celui de l’application de méthodes classiques de gestion des projets à un domaine (le développement de logiciels) auxquelles elles ne conviennent pas.

« Le développement de logiciels implique la découverte en tout temps de nouvelles tâches dans l'environnement complexe et abstrait du code, ce qui fait que la durée des tâches de développement de logiciels finit par demeurer une inconnue. De plus, les techniques de gestion de projet sont conçues pour être appliquées à des tâches dont la durée est connue. Un exemple de tâches de durée connue est le pliage de textiles pour la livraison aux clients. Si vous travaillez sur un ensemble de tâches dont la durée est connue, ce serait une erreur de ne pas appliquer les techniques de gestion de projet pour les mener à bien de façon aussi efficace que possible. Maintenant, il existe un nombre limité de tâches en génie logiciel qui fonctionnent bien avec la gestion de projet. Prenons un ensemble de 100 rapports bien connus auxquels il faut appliquer quelques variations simples pour 10 clients. Ce travail peut être assez facilement planifié en supposant que vous ayez un ingénieur qui connaît très bien ces rapports et qui a déjà apporté des modifications similaires auparavant. Mais soyons réalistes, la plupart des logiciels sont bien plus compliqués que de petites adaptations de rapports. En outre, après le démarrage d'un projet typique en génie logiciel, la découverte constante de nouvelles tâches entraîne des extensions en terme de charge de travail pour l'équipe. Cela signifie que l'évaluation de la durée de nombreuses tâches en génie logiciel finit toujours par générer des interrogations. Ceci a au finish tendance à rendre de telles évaluations absurdes et mène à l'état actuel de l'industrie où les projets logiciels sont connus pour le non-respect des délais », lit-on.

Non-respect des délais et tares liées : nouvelles planifications à profusion, accumulation de la dette technique, etc. Toutes choses qui suggèrent la conclusion selon laquelle requérir des estimations de délais dans le détail est une perte de temps et d’argent pour les entreprises.

Pourtant, il faut bien pouvoir définir une fourchette dans laquelle le projet sera livré au client, ce qui passe d’une manière ou d’une autre par l’exercice des estimations. À ce propos, la publication suggère de ne pas trop en faire sur le papier, mais de s’inspirer des méthodes Agile : l’action.

« C'est dans ce contexte qu'est apparu Agile, ce qui est un bon signe de reconnaissance de l'idée que non seulement les estimations sont inexactes, mais que l'équipe était lancée sur la mauvaise piste, car les exigences étaient erronées. C'est pourquoi Agile dit d'arrêter de se concentrer autant sur la paperasserie et de faire des démonstrations tôt et souvent au client pour que l'équipe puisse découvrir ce dont le client a vraiment besoin et lui donner un bon coup de pouce ! », suggère la publication aux chefs de projets. Elle va plus loin en indiquant de s’appuyer sur des historiques de gestion de projets bouclés pour sortir les prévisions les plus précises possible pour les projets en cours ou à venir.

À l’intention des chefs de projet, c’est peut-être le lieu de rappeler quelques règles (formulées par un architecte logiciel il y a quelques années) à respecter pour une estimation logicielle optimale :

Première règle : ne pas allouer un temps énorme à estimer les délais

Le temps passé à faire des estimations peut être valorisé autrement, sur d’autres tâches du projet. Il peut par exemple être ajouté au temps de développement. Malheureusement, c’est bien le contraire qui prévaut sur le terrain dans la plupart des cas et entraîne un manque de productivité des équipes de développement. Dans les chiffres, les équipes de développement perdent environ 2 à 4 heures à cause des estimations sur une semaine de 40 heures impliquant une perte en productivité entre 5 à 10 %.

Deuxième règle : les estimations sont non transférables

Ce qu’il faut comprendre par là est qu’une estimation faite par un individu n’est pas forcément valable pour un autre pour la simple raison que les personnes ne sont pas les mêmes, n’ont pas les mêmes capacités ni les mêmes compétences face à un problème donné. C’est encore moins valable quand l’estimation a été faite par une personne qui n’est pas du même domaine ou qui n’a pas les mêmes intérêts. C’est le cas par exemple quand c’est un commercial, dont le souci est de vendre un produit qui n’est pas encore sorti d’usine, mais qui fait croire au client que le produit en question peut être livré dans un délai assez court, qui fait l’estimation. C’est moins grave quand il s’agit d’une estimation faite par une personne du même domaine, avec un niveau d’expérience similaire. L’erreur à ne surtout pas commettre est de faire les estimations pour une équipe en considérant le temps que mettrait le plus rapide de l’équipe pour exécuter une tâche donnée.

Troisième règle : il faut savoir qu’une estimation est par défaut erronée

Les estimations ne doivent pas être considérées comme étant des promesses, mais plutôt comme des suppositions dépendant de l’évolution de l’activité et des risques d’erreurs. Il vient donc que personne ne devrait être surpris lorsque des estimations se révèlent fausses, mais il faut plutôt l’être quand elles sont exactes. C’est d’ailleurs la raison pour laquelle le mot estimation est utilisé et non le mot exactitude. En sus, il faut s’attendre à des précisions plus proches de la réalité quand il s’agit d’une petite tâche, mais aussi pour des projets individuels ou des projets en cours d’achèvement. En effet, pour ces derniers, on apprend de ses erreurs pour améliorer les estimations futures pour qu’elles soient les plus précises possible.

Quatrième règle : les estimations sont temporaires

Les estimations sont périssables avec une durée de vie relativement courte. Un développeur peut faire une estimation d’une semaine pour « coder » une fonctionnalité de son application avant le début du projet. Trois mois après le démarrage du projet, il peut arriver que certaines spécifications en relation avec la fonctionnalité en question aient changé. D’une semaine, la fonctionnalité peut se retrouver avec une nouvelle estimation d’une heure ou d’un mois. Ou alors, il peut arriver que la fonctionnalité soit tout simplement abandonnée pour une raison ou une autre. C’est pour prévoir des cas pareils que certaines équipes recommandent une révision de l’ensemble des estimations de façon périodique. Cependant, cela peut exacerber les membres de l’équipe qui ont encore en tête la première règle. Pour trouver le juste milieu entre les règles « une » et « trois », le conseil est de retarder les estimations le plus possible en vue d’y inclure tous les facteurs déterminants. Mais pour ceux qui souhaitent une estimation avec 100 % de précision, ils peuvent aussi attendre la fin du travail pour donner une estimation.

Cinquième règle : faire une estimation de ses dépenses

Une estimation qui vaut la peine d’être faite est bien celle du budget des dépenses. En effet, l’architecte logiciel affirme qu’aucune équipe de développement ne prendrait la décision de réaliser un nouveau logiciel sans avoir fait au préalable une estimation de ses dépenses. Si les lois précédentes sont valables, cela ne signifie pas faire fi de toute estimation. Pour mieux réussir cette estimation, toute l’équipe doit y participer, du gestionnaire du projet au développeur en passant par le commercial.

Source : iiSM

Et vous ?

Qu’en pensez-vous ?
En tant que développeur, l’estimation des délais fait-elle partie de votre quotidien ? Comment se passe cet exercice au sein de votre entreprise ?
Les équipes de développement sont-elles condamnées à ne jamais respecter les délais de livraison des projets quelles que soient les méthodes employées ?

Voir aussi :

Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ? Une étude en recherche la cause
Pourquoi nous trompons-nous toujours dans l'estimation des délais ? Les sprints de courtes durées sont la solution, affirme un sénior
Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel, selon un blogueur

[dfgs]

Estimer les délais est une vrai plaie. Dans mon ancienne équipe les DEV avaient peur de donner des estimations, car ils se faisaient brimer par le management en cas de dépassement .

Nous avions fini par établir une notion de forfait fixe: Trois jours par user story (point barre). Si les dev estimaient que ce n'était pas suffisant, alors on la redécoupait....

Au final on arrivait plus près de la réalité via se système, qu'en perdant du temps à calculer la durée des tâches à la demi journée près.

[MagnusMoi]

Si la méthode agile est apparue et que les estimations de temps sont fausses c'est à cause de 2 facteurs :

1. La recherche de l'argent rapide
2. La nation des pisseurs de code

Parce que les sociétés et leur commerciaux sont prêtes à signer n'importe quoi pourvu qu'elles signent avant les autres. Donc on s'en fiche de savoir en détail ce que veulent les clients.
Ensuite pas mal de développeur veulent juste taper du code sans prendre le temps de le penser, test de nouvelle tech sans prendre de recul, et que se poser 2 semaines ou plus pour faire : Cahier d'analyse de la demande, concevoir le modèle de donnée les CU les Workflows, le principe générale des interfaces et l'architecture ... "C'est trop fatiguant"

Et donc on se retrouve dans des situations absurdes comme aujourd'hui, où les projets sont bâcles, non documentées (on utilise Agile parce que leur utilisateurs pensent à tord que cela les libère des doc), refait tous les 5 ans les app de zéro, remplis de copier coller et j'en passe. L'important étant de livrer on patchera après (WWE 2K20 I SEE YOU ! ), parfois comme pour le dernier God Of War certaines applications n'ont même pas certain fonctionnalité cruciales pensées ou implémentées 3 mois avant la sortie ( pas de menu pour GoW d'où l'arbre monde). Et je ne parle pas de mon expérience pro (projet flash, windev et java I SEE YOU TOO !!! ).

Pour résumé le problème avec une image
L'informatique aujourd'hui ... c'est un commercial qui vend une maison à un particulier, sans plan, sans terrain, qui demande à un maçon et un architecte de donner une estimation vis-à-vis de leur dernière construction (même si c'était un centre commercial), et de commencer la construction sans plus tarder.
Ensuite, utilisant la méthode agile, à chaque revu de sprint on demande au client si veut une pièce en plus ou arranger les choses et à la fin du projet :
On se rend compte que les pièces ne se collent pas, certaines sont clonées, que le terrain est en fait un ensemble de parcelle non contiguës, qu'il manque la moitié du toit et que l'autre partie est directement sur la dalle et que ... en dépit du fait que le client soit passablement satisfait du cagibi, il faut tout casser pour mettre l'eau et l’électricité

La conception logicielle et les outils associés comme modelio n'ont pas été inventé pour les chiens en fait, si le temps et la qualité étaient le main focus, il y aurait moins de problème. Dans les industries plus "physique" exigent plus de rigueur (et encore) sans doute parce que l'on a pas l'impression que se rouler sur un clavier suffit pour sortir un produit.

Désolé pour la noirceur de mon post mais c'est pas très rose en ce moment dans ma vie

[Edrixal]

En tant que développeur, l’estimation des délais fait-elle partie de votre quotidien ? Comment se passe cet exercice au sein de votre entreprise ?

L'estimation des delais à son importance. Si un dev estime qui doit mettre une semaine pour faire une tâche mais qu'il y passe un mois, il faut tenter de comprendre pourquoi et corriger le tir pour la prochaine fois.
De même que si ont estime un temps à une semaine et qu'on y passe un jour, c'est bien de comprendre comment on à pu réduire le temps de dev, savoir si ça peut s'appliquer ailleurs, ect...

De mon coter, même si on ne me demande pas toujours d'estimation j'en fait toujours une au préalable pour moi. Le but étant de capter là ou j'ai le plus de mal et de voir ce qui peut être fait pour m'améliorer.

Les équipes de développement sont-elles condamnées à ne jamais respecter les délais de livraison des projets quelles que soient les méthodes employées ?

Tout dépend qui fait les estimations. Là ou je bosse on refait tout un ERP. Y'a 1 ans les commerciaux nous ont annoncer avec un grand sourire et une joie non contenue qu'il avait lancer un mailling général à nos clients qui annoncer la sortir de la nouvelle version pour juin 2020.
Étonnamment toute l'équipe de dev c'est mise à rire, sauf l'architecte logiciel et le chef de projet qui eux avait bien compris que c'était pas une blague... Et faut être honnête on finira pas avant fin 2020/début 2021. Depuis les commerciaux tente de minimiser l'impacte de leur annonce sur les clients. S'quand même dommage parce que d'habitude nos commerciaux viennent d'abord nous voir pour demander en combien de temps on peut faire les devs avant d'annoncer au client au chiffrage.

'fin bref tout ça pour dire que tant que les dev ce verrons imposer des temps de dev par d'autre, ils ne pourrons que difficilement respecter les délais. Sinon, un dev avec un peu d'expérience qui fait ses propres estimation devrait être généralement dans les délais, avec parfois un peut d'avance, parfois un peut de retard.

[pboulanger]

Pour pouvoir faire une estimation, il faut savoir qui va réaliser: un débutant sorti de l'école risque d'être moins rapide qu'un développeur expérimenté qui a déjà l'expérience de ce type de sujet... Fut un temps, les chefs de projets qui étaient des développeurs confirmés ayant une bonne connaissance fonctionnelle des sujets faisaient les estimations... Maintenant ceux-ci ont été remplacé par des gens sortit d'école de management ou de commerce: ils n'ont ni la connaissance des technologies ni du fonctionnel... Mais ils peuvent être catapulté chef de projet direct à la sortie de l'école et sont donc moins coûteux... Lorsque les actionnaires et les dirigeants cesseront de penser à leurs primes, le monde s'en portera mieux...

[L33tige]

Pour pouvoir faire une estimation, il faut savoir qui va réaliser: un débutant sorti de l'école risque d'être moins rapide qu'un développeur expérimenté qui a déjà l'expérience de ce type de sujet... Fut un temps, les chefs de projets qui étaient des développeurs confirmés ayant une bonne connaissance fonctionnelle des sujets faisaient les estimations... Maintenant ceux-ci ont été remplacé par des gens sortit d'école de management ou de commerce: ils n'ont ni la connaissance des technologies ni du fonctionnel... Mais ils peuvent être catapulté chef de projet direct à la sortie de l'école et sont donc moins coûteux... Lorsque les actionnaires et les dirigeants cesseront de penser à leurs primes, le monde s'en portera mieux...

J'ai tendance à dire que parfois en sortie d'école les devs sont justement plus rapides, parce-qu’ils font un peu du quick and dirty sans penser que cela peut leur retomber dessus "on verra demain", je jette pas la pierre j'étais dans ce cas !

[ddoumeche]

La seule méthode d'estimation des délais qui fonctionne est celle du poker planning. Lorsque chaque développeur estime les tâches en amont, et les chiffre en réunion en points avec un jeu de carte. Ceux ayant émis les estimations les plus extrèmes doivent discuter rapidement de leur estimation, peuvent ainsi lever les lièvres, confronter leur connaissance du code source, les seniors peuvent éclairer les juniors etc.

Ainsi Jean-Claude apprendra enfin a quoi sert réellement WidketAbstractFactoryManager, Gonzague qui pensait devoir toute une fonctionnalité top-down peut alors apprendre qu'elle existe déjà sous une forme tierce à modifier, une catastrophe sera évitée et l'esprit d'équipe sera renforcé. En outre, les développeurs jouent ensembles symboliquement et sont dans l'échange, et même le chef d'équipe participe.

Charge au chef d'équipe, à l'animateur, de transformer ces évaluation de temps en heures.

[Chuck 3.50]

La seule méthode d'estimation des délais qui fonctionne est celle du poker planning. Lorsque chaque développeur estime les tâches en amont, et les chiffre en réunion en points avec un jeu de carte. Ceux ayant émis les estimations les plus extrèmes doivent discuter rapidement de leur estimation, peuvent ainsi lever les lièvres, confronter leur connaissance du code source, les seniors peuvent éclairer les juniors etc.

Ainsi Jean-Claude apprendra enfin a quoi sert réellement WidketAbstractFactoryManager, Gonzague qui pensait devoir toute une fonctionnalité top-down peut alors apprendre qu'elle existe déjà sous une forme tierce à modifier, une catastrophe sera évitée et l'esprit d'équipe sera renforcé. En outre, les développeurs jouent ensembles symboliquement et sont dans l'échange, et même le chef d'équipe participe.

Charge au chef d'équipe, à l'animateur, de transformer ces évaluation de temps en heures.

Salut, on travail de cette manière c'est très efficace en effet, mais je trouve que le soucis/dérive de la méthode agile c'est qu'on dit que l'estimation c'est qu'une estimation, mais on dit aussi qu'un sprint est un contrat, du coup une estimation par son nom est forcément fausse et du coup le contrat forcément non rempli ...

[Nebulix]

" découvrir ce dont le client a vraiment besoin "...

[FMJ]

Bref, vive les prestations au temps passé !!!!!

[ddoumeche]

Salut, on travail de cette manière c'est très efficace en effet, mais je trouve que le soucis/dérive de la méthode agile c'est qu'on dit que l'estimation c'est qu'une estimation, mais on dit aussi qu'un sprint est un contrat, du coup une estimation par son nom est forcément fausse et du coup le contrat forcément non rempli ...

Attention, la méthode à Gilles ne corrige pas les problèmes d'incompétence ou de laxisme des chefs d'équipe, de projet, des développeurs, pas plus qu'elle ne supprime les obligations contractuelles de livrer son client en temps et en heure. Mais cette obligation étant rarement remplie, autant passer au poker planning pour cerner et corriger les points faibles de la phase d'estimation. Et avec l'expérience, la conversion des points de charge en temps est de plus en plus précise.

Que propose-t'on, que les développeurs s'engagent sur l'honneur et le sang à livrer en temps et en heure ? avec des pénalités financières en cas d'erreur ?

[gangsoleil]

La seule méthode d'estimation des délais qui fonctionne est celle du poker planning. Lorsque chaque développeur estime les tâches en amont, et les chiffre en réunion en points avec un jeu de carte.

Je ne vois pas l'intérêt de passer par des points. Assez rapidement, on se retrouve avec des correspondances du genre "20 points, c'est 2 semaine", donc pourquoi ne pas dire directement 2 semaines ?

Attention, ceci n'est pas un troll, mais bien une vraie question. Pour moi, si tu es capable d'estimer en points, tu es capable d'estimer en heures ou en jours.

[ddoumeche]

Je ne vois pas l'intérêt de passer par des points. Assez rapidement, on se retrouve avec des correspondances du genre "20 points, c'est 2 semaine", donc pourquoi ne pas dire directement 2 semaines ?

Attention, ceci n'est pas un troll, mais bien une vraie question. Pour moi, si tu es capable d'estimer en points, tu es capable d'estimer en heures ou en jours.

C'est une bonne question, parce demander un temps est imprécis justement d'où l'usage du planning poker, alors qu'une estimation en temps est relative. L'intervenant Jean-Pierre y répond en détail dans sa vidéo. Charge ensuite au responsable de faire la conversion corrigé de son propre factoromètre, qui varie au court du temps. Si 20 points valent 1 mois a un moment T, ils peuvent valoir 2 semaines a T+4.

A l'inverse, une équipe de développeurs capable de chiffrer correctement ses temps de développement n'a sans doute pas besoin de ce outil, soit parce qu'elle est meilleure, soit parce qu'elle connait le projet sur le bout des doigts.

[Pyramidev]

Pour que des développeurs puissent estimer la durée des tâches de manière assez fiable, je vois au moins trois conditions à remplir.

La première, c'est de définir précisément les fonctionnalités à implémenter et pas juste une idée générale. Si on ne sait pas quelles tâches effectuer, on ne peut pas les estimer. Le corolaire, c'est que l'estimation ne peut pas être précise si elle doit inclure de nouvelles fonctionnalités surprises ajoutées entre l'estimation et la livraison, voire de nouvelles tâches surprises qui ne sont pas liées au dev. Le plus simple est que l'estimation ne porte que sur ce qui a été prévu et que, si les exigences changent, on refait l'estimation et on décale le délai (s'il n'y avait pas assez de marge dans le délai).

La deuxième, c'est de bien connaître l'existant. Des fois, la fonctionnalité à ajouter est très claire, mais on ne connaît pas à l'avance tous les changements que cela implique de faire dans l'existant. Il faut donc des développeurs qui connaissent bien l'existant. Pour cela, il faut que l'entreprise se débrouille pour que le turnover soit faible, ce qui implique d'augmenter régulièrement les salaires des développeurs sur place.

La troisième, c'est de ne pas avoir un existant de merde. En effet, plus la dette technique est élevée, plus on perd du temps, mais aussi plus le temps perdu est imprévisible.

• Si le code est mal architecturé et mal écrit, on a souvent des imprévus quand on veut le changer.
• Si le code a trop de bogues car n'est pas couvert par des tests unitaires, un bogue existant risque de pourrir les tests manuels en faisant croire que le problème vient des dernières modifs alors que c'est un bogue historique. Ou alors, ce qui arrive plus fréquemment, c'est que le développement en cours sera interrompu car un client a remonté un bogue urgent.
• Si le code a une mauvaise gestion d'erreurs et que le programme a des mauvaises données en entrée, un client va interrompre le développement pour enquêter sur le problème, ce qui risquera d'être long car le message d'erreur n'indique pas clairement que le problème vient des données en entrée.

Si une boîte n'a pas fait ce qu'il fallait pour que ces conditions soient réunies, il ne faudra pas s'attendre à des estimations précises.

[Marco46]

Si une boîte n'a pas fait ce qu'il fallait pour que ces conditions soient réunies, il ne faudra pas s'attendre à des estimations précises.

Il manque un point essentiel, c'est la saisie du consommé. Une estimation n'est pas un engagement c'est une hypothèse. C'est en comparant les estimations avec le consommé (la réalité) que l'on peut voir si les estimations sont pertinentes ou non et donc si on peut s'y fier pour planifier. Ce n'est qu'au terme de plusieurs sprints avec une équipe stable que les deux devraient commencer à se rapprocher et c'est à ce moment que l'on peut tirer parti des estimations.

Si on ne fait pas cet exercice (qui est chiant car il faut être minutieux et rigoureux) l'ensemble ne sert à rien du tout.

Et si on fait cet exercice et qu'il fonctionne, on se rend compte que convertir les points en temps devient ipso facto inutile puisqu'on sait rien qu'avec les points ce qu'on va réussir à réaliser ou non.

Penser en points permet de penser complexité au lieu de temps et c'est bien utile lorsqu'on ne sait pas trop le temps que ça va prendre.

De toutes manières l'aboutissement de SCRUM pour moi c'est KANBAN pour aboutir in fine à du continuous delivery voire du continuous deployment (le Saint Graal). C'est là qu'on réduit au maximum le lead time et donc le TTM.

De ce point de vue SCRUM n'est qu'une phase d’entraînement pour améliorer sa vitesse de delivery (lead time si on part du commit mergé, TTM si on part de l'expression du besoin par le métier).

Je précise que je n'ai pas vu la vidéo mais que j'en ai déjà vu plusieurs de cet auteur.

[el_slapper]

Pour que des développeurs puissent estimer la durée des tâches de manière assez fiable, je vois au moins trois conditions à remplir.(.../...)
Si une boîte n'a pas fait ce qu'il fallait pour que ces conditions soient réunies, il ne faudra pas s'attendre à des estimations précises.

+1

J'ai vu un gars qui était capable de dire, après 30 secondes de réflexion, "ton projet, il va coûter 420 jours". Avec une marge d'erreur mesurée ne dépassant pas 5%. Mais oui, l'existant était archiconnu de toute l'équipe, maintenable et maîtrisable (Il y avait des redondances, mais elles étaient connues et maîtrisées). Après, j'ai foutu la merde dans ses calculs en faisant(sur les ordres d'un autre chef de l'équipe) une refonte qui faisait sauter une bonne partie des redondances(mesuré après coup : plus d'un temps plein de maintenance d'économisé). Mais sur une appli fixe et connue, oui, on peut être précis sur des specs précises et qui ne vont pas changer en cours de projet.