1 pièce(s) jointe(s)
Charger les développeurs d'estimer les délais dans le détail est une perte de temps et d’argent
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 ?
:fleche: Qu’en pensez-vous ?
:fleche: 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 ?
:fleche: 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 :
:fleche: Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ? Une étude en recherche la cause
:fleche: Pourquoi nous trompons-nous toujours dans l'estimation des délais ? Les sprints de courtes durées sont la solution, affirme un sénior
:fleche: Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel, selon un blogueur
