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

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.

[B][SIZE=2]Quatrième règle :[/size=2]...