8 Reasons Why the Estimates Are Too Low
http://www.pmhut.com/8-reasons-why-the-estimates-are-too-low
Par Jens Schauder
Une des tâches les plus difficiles dans un projet de développement logiciel est d’évaluer la taille du projet. Malheureusement, le plus souvent, vous devez le faire au début même du projet, alors que vous avez le moins d’informations. Le résultat à la fin est très souvent une différence très significative entre l’estimation originale et le temps et l’argent réellement nécessaires.
Si la différence est aussi souvent positive que négative c’est en quelque sorte “acceptable”. Mais dans certaines équipes, les estimations sont systématiquement trop faibles !
La stratégie évidente et souvent employée est d’ajouter un certain pourcentage à l’évaluation de l’équipe. Mais bien sûr, ceci n’adresse que les symptômes, parce que la plupart du temps personne n’en connaît la raison. Aussi, dans cet article, je vais vous présenter plusieurs raisons pour de mauvaises évaluations, comment les identifier et aussi comment si possible les éliminer.
Voici les sortes de raisons que j’ai identifiées à ce jour :
Les estimations des super héros : Souvent les évaluations sont faites par un développeur très expérimenté (le Super Héros). Quand il évalue une tâche il s’imagine la réalisant. Mais, bien que l’évaluation puisse être correcte pour le Super Héros, elle pourrait ne pas fonctionner pour des développeurs dans la moyenne. Et, comme ils ne sont pas des Super Héros, il leur faudra plus de temps.
Vous pouvez identifier cette sorte de situation en laissant des personnes différentes réaliser les estimations, en incluant des développeurs moyens. Si l’évaluation du Super Héros est constamment au-dessous de celles des autres, la correction devient évidente : Utilisez l’estimation des autres développeurs. Mais n’excluez pas le Super Héros des évaluations. Ces développeurs expérimentés sont très bons pour identifier les choses que d’autres auraient tendance à oublier.
- Mauvaise Équipe : Cette raison est semblable à la situation des estimations de Super Héros dans laquelle l’évaluation n’est correcte que pour une équipe de bons (voire excellents) développeurs. Elle en diffère cependant, parce que dans ce scénario, pour une raison ou pour une autre, le projet est pourvu en personnel avec une équipe différente de celle escomptée au départ. Peut-être avec des développeurs moins brillants, ou peut-être simplement une équipe qui ne connaît pas bien le domaine, la structure ou le langage de programmation.
Pour identifier cette situation, parlez avec les personnes réalisant les évaluations. Laissez-les expliciter les suppositions qu’ils ont faites quand ils ont préparé l’évaluation et comparez les à ce qui se produit sur dans le projet dans réalité.
Si c’est le problème vous avez deux options : la première est d’arrêter ce changement d’équipes. Mais cela ne marche pas la plupart du temps, parce que vous ne les changez pas juste pour le plaisir, n’est-ce pas ? Donc il vous reste la deuxième option : Même quand vous planifiez d’utiliser votre équipe de champions, faites les évaluations en supposant qu’une équipe moyenne doive réaliser le travail. Soyez honnête sur ce qu’est une équipe moyenne.
- Faire des suppositions dans le noir : Souvent les informations disponibles sur le projet ne sont suffisantes pour une évaluation fiable. Seule une vague description est disponible.
Pour identifier cela comme le problème sous-jacent, décomposez le projet en tâches, que vous évaluez. Pour chaque tâche inscrivez les suppositions que vous avez faites : quelle technologie sera utilisée, quelle est la complexité de la logique à implémenter. Pendant le projet, vérifiez si vos suppositions tiennent la route ou s’il y a beaucoup de changements. C’est aussi une grande partie de la solution au problème. Faites de la description de votre supposition une partie de votre évaluation. Si les suppositions sont fausses, le client peut les corriger, aboutissant à une nouvelle estimation plus fiable. S’il change d’avis plus tard, vous avez une base claire pour un processus de management des changements, qui assure, que les modifications sont possibles, mais que celui qui les demande les paye aussi.
Oublis : Cette raison paraît très semblable à la précédente. Les trucs oubliés ne sont pas inclus dans les évaluations. Mais cette fois, ce n’est pas parce que les personnes faisant les évaluations ne les connaissent pas, mais parce qu’ils en oublient.
Utiliser la même stratégie que sur « Faire des suppositions dans le noir » devrait rendre cette sorte d’erreur évidente. Comme remède, laissez de multiples personnes faire des évaluations et comparez les résultats. Vous devriez le faire basé sur les tâches détaillées, car des tâches manquantes dans des évaluations différentes y deviennent évidentes.
- Projets « Boule de glaise » : Quand les projets basés sur une base de code spécifique prennent trop longtemps à chaque fois, une raison pourrait être que les tâches continuent à devenir de plus en plus complexes que prévu. Une raison typique à cela serait une base de code excessivement complexe et tortueuse, où personne ne peut vraiment prévoir les effets que peut avoir un changement de code donné.
Dans un tel projet, je m’attendrais à beaucoup de syndrome du 80 %, peu de tests et beaucoup de développeurs qui jurent. Faites une analyse de la base de code, en vous concentrant sur le management des dépendances et l’architecture. Si vous trouvez beaucoup de non-sens, il y a une seule solution : Nettoyez cette base de code et payez votre dette technique. C’est-à-dire investissez le temps et l’argent nécessaire pour améliorer l’architecture. Je recommande aussi d’implémenter des tests qui empêcheront l’architecture de commencer à se dégrader de nouveau.
Multitâche : Les personnes sont mauvaises dans le multitâche. Donc vous ne pouvez pas mettre votre meilleur développeur à 20 % sur cinq projets différents et vous attendre à ce qu’il soit aussi efficace qu’en temps normal. Une fois que vous commencez à y réfléchir, cela devrait vite devenir évident de savoir si vous avez le problème ou pas. Et il en va de même pour la solution.
Le Mythique Mois Homme: Vérifiez si vos évaluations sont traitées comme cela : “Frank dit qu’il aurait besoin de 6 mois. Nous devons avoir fini dans 1 mois, donc mettons 6 développeurs sur le projet.” Si c’est le cas vous ratez tous les surcoûts que cause une plus grande équipe. Pour comprendre cette sorte de problème lisez le livre Mythical Man Month. Je pense vraiment que le livre est surévalué, mais le chapitre sur le mythique mois homme est vraiment pile sur le sujet.
Ce problème est presque certain de vous frapper quand vous faites un projet qui a de plus grande ampleur que vos projets normaux. Vous sous-estimerez grandement, si vous ne factorisez pas la sur couche exponentielle de communication sur un tel projet.
- Développeur Paresseux : Bien sûr il y a toujours la possibilité que les développeurs ne travaillent juste pas assez dur. Selon mon expérience, la plupart du temps, ce n’est pas un problème. Mais cela peut vraiment se produire. Les symptômes pourraient être beaucoup de fenêtres de navigateur ouvertes, sur des sites qui n’ont aucune relation avec le travail à faire, accompagné de commutations hectiques entre ces fenêtres, quand le patron arrive. Si c’est un problème avec un seul développeur, il se peut que le développeur puisse y remédier. Mais si beaucoup de développeurs passent leur temps à procrastiner alors c’est le plus probablement un problème de management. La procrastination n’est pas amusante. Réaliser des choses l’est. Donc si chacun remet ses tâches à demain, c’est qu’il y a quelque chose dans l’environnement qui les démotive probablement fortement. Découvrez quoi et éliminez le.
Partenaire de DantotsuPM
