Pourquoi les estimations des tâches de développement logiciel sont-elles régulièrement décalées d’un facteur 2-3 ?

Pourquoi les estimations des tâches de développement logiciel sont-elles régulièrement décalées d’un facteur 2-3 ?

Voici une réponse à la question Quora : Pourquoi les estimations ne sont pas exactes ?

Il y a plusieurs facteurs pour cela. Voici quelques exemples courants :

1) Le client n’est pas technique et pense que « tout est facile »

Développer un logiciel n’est pas aussi simple qu’il n’y paraît.

Même si cela semble facile, il est parfois préférable d’omettre certaines tâches.

• Pour faire une analogie :

Il y a une énorme colline et nous devons construire une voie ferrée. Les développeurs conseilleront : « Mieux vaut éviter la colline et construire la piste autour de la colline. De cette façon, nous économiserons 5 mois de travail supplémentaire ».

Ici, il serait évident qu’il faudrait beaucoup plus de temps pour percer un tunnel à travers la colline et que le client accepterait le « travail de contournement ».

• Voyons maintenant le développement de logiciels :

Le développeur déclare : « Il vaudrait mieux n’avoir qu’une seule version mobile avec une seule taille d’écran et une seule version de bureau avec une seule taille d’écran. Nous devrions éviter d’avoir une application mobile et également éviter un design complètement réactif, car cela n’aura pas l’air bien ».

Ici, le client dira très probablement : « Pourquoi ? D’autres sites Web sont également réactifs et peuvent s’adapter à toutes les tailles d’écran. C’est une tâche facile.

Mais : il peut y avoir plusieurs et bonnes raisons pour lesquelles le développeur a suggéré cela. Peut-être qu’un design réactif ne sera pas beau ou professionnel. En particulier, certains boutons peuvent facilement être malveillants, etc., etc.
Alors maintenant, ce qui va se passer, c’est que le développeur va 1) créer la page responsive et 2) augmentera les heures.

• Pour l’augmentation d’heure il n’y aura pas d’acceptation par le client : « Pourquoi plus d’heures ? C’est facile, n’est-ce pas ? »
• Lorsque la tâche est terminée, le client regardera le site Web avec son mobile et dira : « Tout est désaligné lorsque je consulte le site sur mobile. Pourquoi? J’ai payé beaucoup plus et maintenant ça ?”.

Si le client avait accepté la méthode précédente (non réactif, avec seulement deux versions), le site Web aurait été moins cher (moins d’heures) et il aurait parfaitement fonctionné sur presque tous les écrans mobiles et navigateurs de bureau.

Le problème principal ici est aussi : Il n’est pas bon de discuter avec qui que ce soit. Surtout se disputer avec le client n’est pas une bonne idée. Ainsi, le développeur/le fournisseur de services dira toujours « Oui, vous avez raison, faisons-le de cette façon ».

Et une fois que le client n’est pas vraiment satisfait, alors le développeur devrait à nouveau prendre le blâme (même s’il sait que ce n’était pas de sa faute, mais que l’exigence était telle).

2) Il n’est pas possible de prendre beaucoup de temps pour estimer exactement

Dans le monde réel, une entreprise de logiciels recevra des demandes d’applications logicielles quotidiennement ou hebdomadairement.

Si chaque demande était estimée avec précision, les développeurs n’auraient rien d’autre à faire que de créer des estimations exactes. Ils ne seraient pas en mesure de travailler sur de vrais projets, car la création de ces estimations exactes prend beaucoup de temps.

Donc, ce qui se passe réellement, c’est : ils vont examiner le projet et « estimer » le temps nécessaire. C’est pourquoi on l’appelle une « estimation », car elle n’est pas exacte.

Aussi : Le client lui-même n’est pas intéressé à attendre une ou plusieurs semaines pour spécifier l’exigence. Au maximum un document de 5 pages sera créé et qui sera la base du développement.

3) Chaque exigence change au cours du projet

j’aime citer André Rose du fil de discussion/lien Quora au début de cet article :

« Peu importe la taille d’un projet, il y aura toujours quelque chose qui se présentera après le début du projet. Plus probablement, beaucoup de choses vont arriver. C’est juste la nature de la bête. En tant que chef de produit, votre travail consiste à travailler avec vos clients pour trouver ce dont ils ont besoin et sont prêts à payer. Vous devez également trouver ce que vous pouvez raisonnablement fournir avec l’aide de vos développeurs. Au fur et à mesure que vous travaillez pour atteindre ces objectifs, vous rencontrez des changements de portée, des estimations de temps incorrectes et, parfois, des changements dans les personnes qui travaillent pour mener à bien le projet.

Beaucoup de choses changent au cours du projet. Comme Andrew l’a mentionné, non seulement les exigences changeront. Même les gens peuvent se lancer dans d’autres projets avant l’achèvement du projet en cours.

Ici une analogie :

Un sprinter de 100 mètres s’entraîne pendant 10 ans pour parcourir le 100 mètres en moins de 10 secondes.

Le jour du sprint, dit le client, nous avons également besoin de 5 obstacles en cours de route.

Ensuite, le sprinteur dira « mais alors je ne pourrai pas le faire en moins de 10 secondes » et le client dira « pour quoi vous êtes-vous entraîné ces 10 dernières années, veuillez le faire en moins de 10 secondes ».

Cette même chose aussi dans les projets logiciels. Les clients et les chefs de projet apporteront de nouvelles exigences car « Oh, j’ai oublié cette fonctionnalité très importante. Cela doit être dans le logiciel, sinon cela ne nous sera pas utile ».

Ces changements d’exigences viendront généralement au cours du projet complet. C’est comme ajouter un étang, un mur, une échelle, etc., à la manière du sprinteur, en s’attendant à ce qu’il le fasse encore en moins de 10 secondes.

4) Architecture mal vérifiée

Surtout lorsque les choses ne sont pas faites à partir de zéro et que des outils tiers (WordPress, TYPO3, Drupal, Magento, Shopware et bien d’autres) sont utilisés et qu’ils doivent être personnalisés pour faire quelque chose de particulier auquel il peut arriver estimations erronées .

Dans ces outils tiers, nous ne pouvons pas simplement changer tout ce que nous voulons. Des choses simples comme la structure de l’URL ou d’autres choses doivent être suivies.

Comme au point 1) de ce texte, tout n’est pas facile à mettre en œuvre. Une fois qu’il a été découvert que l’architecture actuelle du système tiers ne prend pas en charge une fonctionnalité spécifique, il est toujours préférable d’éviter cette fonctionnalité spécifique et d’utiliser un travail autour qui fait le même travail, mais en utilisant l’architecture existante.

Remarque : ce problème/problème se posera également si le projet est réalisé à partir de zéro avec des outils tels que PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js, etc. et certaines hypothèses initiales erronées ont été faites sur l’architecture du système.

5) Le bouchon du spectacle « une phrase » ou « un mot »

J’avais déjà évoqué l’exemple du document de 5 pages, qui sera fourni par le client. Une fois le développement presque terminé ou en cours, le client dira : « Il manque une fonctionnalité importante. À la page 3 à la ligne 22, il est mentionné que nous avons besoin – d’un outil de rapport – ».

Mais la construction de cet outil de reporting, qui n’est mentionné que brièvement dans le document, coûtera en soi le même montant que l’ensemble du projet. Et parce que « l’outil de reporting » est mentionné dans le document, le client insistera bien entendu sur sa mise en place.

6) Gagner le projet

Supposons que vous ayez le sentiment que de nombreuses entreprises soumissionnent pour le même projet. Maintenant, vous ne voulez certainement pas être la proposition qui facture le plus d’heures. Vous voulez être celui qui affiche le plus petit nombre d’heures. Si un client peut choisir entre 100 heures et 500 heures, tout le monde optera certainement pour les 100 heures.

En réalité, dans un monde idéal, tout le monde a besoin du même nombre d’heures. Donc, même si 100 heures ont été citées, cela finira par être 500 heures.

7) Inconnus / Temps d’attente

Il y a plusieurs inconnues dans les projets logiciels :

• a) Changement technologique : Si l’un des outils de développement (par exemple Android) reçoit une mise à jour majeure, il reste du travail à faire pour intégrer ces changements technologiques.
• b) Expérience des membres de l’équipe : Si un développeur senior travaille sur le projet, cela prendra moins de temps, s’il s’agit d’un développeur junior, cela prendra probablement plus de temps.
• c) Les commentaires arrivent en retard : Les clients ne sont généralement pas très intéressés par le projet, ils veulent de bons résultats. Ainsi, lorsque le client est approché pendant le projet, il peut ne pas être disposé à donner une réponse dans l’heure. Cela peut prendre plusieurs jours. Pendant ce temps, le projet restera inactif et le fournisseur de services pourrait même facturer des heures pendant cette période, si les développeurs restent inactifs en raison du retard des réponses.

8) Le projet est trop grand pour être estimé correctement

Supposons que la tâche en soit une, qui nécessite plusieurs développeurs sur une période de plusieurs mois.

Il est presque impossible de décomposer les tâches en si petits morceaux de travail, afin d’obtenir la bonne estimation.

Les autres choses mentionnées dans cet article joueront bien sûr également un rôle.

Conclusion

La meilleure approche est :

• Faire une estimation approximative
• Mentionnez qu’il est préférable de réduire les fonctionnalités, si le projet prend trop de temps et prend plusieurs heures (par exemple créer une liste de fonctionnalités prioritaires, ne faire que les plus importantes)
• Utiliser la méthodologie agile pour le développement et la facturation

Si vous souhaitez un prix/heures exacts, cela n’est généralement possible que pour des projets plus petits, qui dureront quelques semaines.

Autres articles intéressants sur le sujet :
Comment estimer un projet de développement logiciel en heures-homme de manière réaliste
Pourquoi l’estimation du temps de développement logiciel ne fonctionne pas et approches alternatives

Source de l’image : Flickr.com/ Michael Kappel/ Judit Klein/ Markus Spiske

L’auteur : Sascha Thattil travaille chez Software-Developer-India.com qui fait partie du groupe YUHIRO. YUHIRO est une entreprise germano-indienne qui fournit des programmeurs aux sociétés informatiques, aux agences et aux services informatiques.