Les estimations sont généralement un mal nécessaire dans le développement logiciel, estime Steve Smith, architecte logiciel sénior, formateur et entrepreneur. Selon lui, beaucoup de gens ont tendance à croire que la réalisation d’un nouveau logiciel est comme la construction d’une maison et que comme l’entrepreneur, l’architecte logiciel doit être en mesure de fournir une estimation correcte et fiable du travail à faire au client. En effet, l’entrepreneur travaille généralement avec des matériaux connus qui ont des coûts déterminés. Or, pour le développement d’un logiciel, une grande partie du système est construit à partir de zéro, d’après Steve. Même la manière dont les différentes parties de ce logiciel seront assemblées, la manière dont il va fonctionner et ce qu’il devra faire exactement ne sont pas connus de manière absolue et peuvent changer à tout moment. Il est difficile dans ces conditions de pouvoir déterminer les dates de début et de fin des différentes tâches du projet.Steve a donc essayé de puiser de son expérience personnelle pour établir cinq règles qui d’après lui, si elles sont respectées, permettent de réaliser une estimation fiable lors de la réalisation d’un nouveau logiciel.
Première loi : ne perdez pas votre temps à faire des estimations
Steve Smith estime que le temps passé pour faire des estimations peut être valorisé autrement, sur d’autres tâches du projet. Ce temps peut par exemple être ajouté au temps de développement. Mais au lieu de cela, ce que constate Steve c’est que ces derniers sont souvent interrompus pour faire d’autres estimations étant donné que les premières n’étaient pas correctes. Ce qui implique un manque de productivité des équipes de développement. Selon l’architecte, 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 %. Steve rapporte en effet, qu’il y a quelques années, un département de Microsoft a réussi à augmenter la productivité de son équipe sans nouvelles ressources et sans changement de la façon dont étaient effectuées les différentes tâches. Les seuls changements opérés, poursuit l’architecte, concernaient le planning et la façon de faire les estimations. Le paradoxe de l’histoire est que souvent les estimations sont initiées par la direction en vue de plus de transparence, mais aussi dans le but de pouvoir améliorer la productivité de l’équipe.
Deuxième loi : les estimations sont non transférables
Ce qu’il faut comprendre par là, d’après Stève, c’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 en face d'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, avertit Steve, 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 loi : 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, d’après Steve. Il déclare en effet 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. Steve ajoute qu’il faut s’attendre à des précisions plus près 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 loi : les estimations sont temporaires
Les estimations sont périssables avec une durée de vie relativement courte, estime Steve. Pour lui, 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, c’est selon, 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, continue Steve. Cependant, cela peut exacerber les membres de l’équipe qui ont encore en tête la première loi. Pour trouver le juste milieu entre les lois « une » et « trois », le conseil de Steve 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 loi : faire une estimation de ses dépenses
Une estimation qui en vaut la peine d’être faite est bien celle du budget des dépenses, d’après Steve. 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, Steve estime que toute l’équipe doit y participer, du gestionnaire du projet au développeur en passant par le commercial.
Source : Ardalis
Et vous ?
Que pensez-vous de ces cinq lois ?Voir aussi
la rubrique Humour et Divers 
