Bonjour,
 
Je me permet de créer ce topic pour poser une question à tout les développeurs pro qui se trouvent ici :
Comment procédez-vous pour évaluer le temps que va vous prendre la réalisation d'un projet ?
 
La question peut paraître simple, pourtant il me semble que les choses ne le sont pas tant.
 
Personnellement, j'ai tendance à essayer de découper X projet en un maximum de sous tâches. Puis j'évalue la durée de chacune des ces tâches et j'additionne le tout pour obtenir ma durée totale et je m'ajoute toujours un délai supplémentaire en secours.
 
Je n'ai jamais reçu aucune formation concernant la gestion de projet, c'est bien mon erreur d'ailleurs. Ceci-dit, je travail maintenant depuis quelques années dans le web et je rencontre régulièrement le même problème : une mauvaise évaluation du temps que prend un projet et lorsqu'il s'agit de retard cela équivaut à des tensions avec le client.
 
Je n'ai pas trouvé de topic qui aborde ce sujet, et je n'ai pas trouvé non plus d'infos sur le net qui traite véritablement le sujet. Je viens donc recueillir vos avis.
 
J'ai choisi de poster dans cette rubrique parce qu'il me semble que les réponses sont spécifiques au domaine dans lequel le projet est réalisé. Cela-dit, je me trompe peut être et dans ce cas ce topic est déplaçable !
 
Merci !

Perso, je fais ça aussi, globalement. Le truc, c'est de pas trop sous-découper pour pas avoir un effet d'accumulation des marges de temps, mais pas tomber dans le travers inverse et pas assez découper. Ensuite, ça dépend beaucoup des technos employées et de la maîtrise de celles-ci par l'équipe de dév. Enfin, y'a sa propre expérience : à force coder des trucs, tu sauras mieux évaluer le temps qu'il te faut pour coder un truc similaire.
 
A ce qu'il paraît, une ssii prend comme base : 1j de dév = 10 lignes codées et testées. Ca m'a toujours paru très peu, perso, je suis plutôt à 100 lignes. Une bonne moyenne apparemment est 30 à 40 lignes codées et testées par jour.

Dans l'idéal il faut suivre un cycle de dev : spec, design, dev, tests. Et évaluer les risques : ressources, techno,...
Faire un planning en fonction du design, des risques et de son expérience, mettre des jalons.
Et avoir un bon chef de projet. Qui saura suivre le projet au plus près, mettre à disposition tout le nécessaire, régler les problèmes, faire gagner du temps, trouver des ressources si nécessaire... Il doit être capable de comprendre au plus tôt comment les choses se déroulent.
En fait, pour tenir un délai c'est le travail de toute une équipe. L'estimation du temps de dev dépend d'une multitude de facteurs difficiles à maitriser.
 
Sur des parties claires à développer, autant profiter de l'expérience des plus anciens pour fixer les temps de dev. Au moins être deux pour faire ces estimations. Ne pas hésiter à faire x2. Et peut-être engager un travail d'analyse sur les projets finis.
 
Voilà mon feeling
 
Sinon je crois avoir déjà vu des formules pour pondérer les estimations. Elles prennent en compte le temps optimiste et pessimiste... Je n'ai jamais testé.

Une fois les specs de base déterminées, je découpe en morceaux sur lesquels j'ai une bonne visibilité (par expérience) du temps que ça va prendre, auquel j'associe un pourcentage de risque, je somme, et je multiplie par un pourcentage variable pour l'intégration des divers morceaux et les imprévus, selon le contexte de l'intégration et le risque de chaque morceau.
Bon ensuite, selon le client, et ce qu'on peut espérer lui vendre, on peut reprocéder à un découpage plus fin avec une inflation des sous-taches permettant de gonfler l'estimation et sa marge  
A+,

Merci pour vos retours.

Ça me parait peu aussi. Et puis je n'ai jamais vraiment aimé compter à la ligne de code. Je trouve que la complexité d'une portion de code ne peut pas se mesurer à son volume, ou pas exclusivement en tout cas.

Voilà c'est souvent le problème. Sur les choses que l'on maîtrise, par expérience, on arrive toujours à poser des délais que l'on respecte. Sur le reste, l'évaluation est plus hasardeuse, j'essaie d'analyser les risques mais ça reste très flou...

Nous faisons toujours nos évaluations à plusieurs, il faut profiter de l'expérience de tout le monde. Faire x2 ça m'arrive quelque fois, mais l'idée c'est aussi de ne pas être largement au dessus. Par contre oui, engager un travail d'analyse sur des projets terminé c'est clairement ce qu'on ne fait pas et qu'on devrait faire.

Je vais chercher un peu de côté, mais bon, je crois pas à la formule magique...

Je vais essayer de d'appliquer quelque chose comme ça pour le prochain projet.

Hé hé, oui, mais là on s'écarte du sujet.