Combien de temps faut-il vraiment pour faire quelque chose? [fermé]

Question

Je veux dire nommer un projet de programmation que vous avez fait et combien de temps cela a pris, s'il vous plaît. Le patron ne s’est jamais plaint mais j’ai parfois l’impression que les choses prennent trop de temps. Mais c'est peut-être parce que je suis impatient aussi. Faites-moi savoir vos expériences à titre de comparaison.

J'ai également remarqué que les choses semblent toujours prendre plus longtemps, parfois beaucoup plus longtemps que prévu initialement. Je ne sais pas pourquoi nous ne commençons pas à planifier, mais je pense que c'est peut-être à des fins de motivation.

Ryan

Answer 1

Il est préférable de simplement vous chronométrer, d’enregistrer vos estimations et de déterminer le pourcentage moyen de vos vacances. Dans la mesure où, si vous êtes cohérent, vous pouvez estimer correctement les temps réels en fonction du moment où vous pensiez le faire. Il ne s'agit pas simplement de déterminer votre niveau d'estimation, mais de prendre en compte la régularité des inévitables distractions (à la fois personnelles et basées sur le patron / client).

Ceci est basé sur la planification basée sur des preuves de Joel Spolsky, essentielle En lisant, il explique que le principal autre aspect important consiste à décomposer vos tâches en tâches très simples (16 heures maximum), à les estimer et à les additionner pour obtenir le total de votre projet final.

Answer 2

Les estimations basées sur l'intestin sont fournies avec l'expérience, mais vous devez vraiment détailler les tâches nécessaires pour obtenir quelque chose de raisonnable.

Si vous avez une spécification ou au moins certaines contraintes, vous pouvez commencer à créer des tâches (page de conception d'utilisateurs, page de balises de conception, page d'implémentation d'utilisateurs, page de balises d'implémentation, requête d'écriture de balises, ...).

Une fois cela fait, additionnez-le et doublez-le. Si vous devez vous coordonner avec les autres, tripler.

Enregistrez votre temps réel de manière détaillée au fur et à mesure de votre progression, de sorte que vous puissiez évaluer votre précision à la fin du projet et affiner vos compétences en estimation.

Answer 3

Je suis tout à fait d'accord avec les affiches précédentes ... n'oubliez pas également la charge de travail de votre équipe. Ce n’est pas parce que vous estimez qu’un projet prend 3 mois que cela se fera.

Je travaille dans une petite équipe (5 développeurs, 1 chef de file), beaucoup d’entre nous travaillons sur plusieurs projets à la fois, certains grands, d'autres petits. En fonction de la priorité du projet, des caprices du management et de la disponibilité des autres équipes (si nécessaire), le travail sur un projet est dispersé entre les autres.

Donc, oui, 3 mois de travail sont peut-être une tâche impossible, mais il se peut que cela représente 3 mois de travail sur une période de 6 mois.

Answer 4

J'ai réalisé des projets entre 1 et 6 mois et j'ai toujours tendance à doubler ou quadrupler mes estimations initiales.

Answer 5

Il est en effet impossible de comparer deux projets de programmation, car il existe trop de facteurs qui font que les métriques ne sont applicables qu’à un autre (par exemple, des technologies spécifiques utilisées, l’expérience antérieure des développeurs, les exigences changeantes). À moins que vous ne détruisiez un autre système presque identique à celui que vous aviez précédemment construit, vos estimations auront une faible probabilité d’être exactes.

Une mise en garde concerne la construction de la prochaine révision d’un système existant avec la même équipe; l'expérience spécifique acquise améliore la capacité d'estimer le prochain lot de travail.

J'ai vu trop de tentatives de méthodologie d'estimation et aucune n'a fonctionné. Ils ont peut-être une allure pseudo-scientifique, mais ils ne fonctionnent tout simplement pas dans la pratique.

La seule réponse significative est l’itération relativement courte, comme le préconisent les défenseurs agiles: choisissez un périmètre de travail pouvant être exécuté dans un délai très court, livrez-le, puis passez au tour suivant. Les budgets sont ensuite alloués à court terme, les parties prenantes pouvant évaluer si leur argent est effectivement dépensé. Si cela prend trop de temps, ils peuvent abandonner le projet.

Answer 6

Loi de Hofstadter:

"Cela prend toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter."

Je pense que c'est parce que:

• Le travail se développe pour occuper le temps disponible pour le faire. Si impitoyable que vous réduisiez des fonctions inutiles, vous auriez été plus brutal si les délais étaient encore plus serrés.
• Des problèmes inattendus se produisent pendant le projet.

Dans tous les cas, il est vraiment trompeur de comparer des anecdotes, en partie parce que les gens ont des souvenirs sélectifs. Si je vous disais qu'il m'avait déjà pris deux heures pour rédiger un tri rapide optimisé, j'oubliais peut-être le fait que je savais que je m'occuperais de cette tâche une semaine à l'avance et que je réfléchissais à mes idées. Peut-être que j'oublie qu'il y avait un bogue dans lequel j'ai passé deux heures à réparer une semaine plus tard.

Je suis presque certainement en train de laisser de côté tout le travail qui n’est pas lié à la programmation: réunions, conception d’architecture, consultation d’autres qui sont bloqués sur quelque chose que je connais par hasard, administrateur. Il est donc injuste pour vous de penser à un rythme de travail qui semble plausible en termes de "codage assis", et de s’attendre à ce que cela soit maintenu tout le temps. C’est la source de nombreux sentiments après le fait que vous auriez dû être plus rapide.

Answer 7

Je fais des projets de 2 semaines à 1 an. En règle générale, mes estimations sont plutôt bonnes, a posteriori . Au début du projet, cependant, je suis généralement pris au piège parce que mes estimations sont considérées comme trop grandes.

C'est parce que je considère beaucoup de choses que les gens oublient:

• Temps pour la correction des bogues
• Heure des déploiements
• Temps consacré à la gestion / réunions / interaction
• Il est temps de permettre aux propriétaires d'exigences de changer d'avis
• etc

L'astuce consiste à utiliser la planification basée sur des preuves (voir Joel on Software).

Si vous prévoyez un peu de temps supplémentaire, vous l'utiliserez pour améliorer la base de code si aucun problème ne survient. Si des problèmes surviennent, vous êtes toujours dans les limites du budget.

Answer 8

Je pense que Joel a écrit un article à ce sujet: Vous pouvez demander à chaque développeur de l’équipe de décrire en détail sa tâche (quelles sont toutes les étapes à suivre) et de lui demander de faire une estimation du temps nécessaire pour chaque étape. Plus tard, lorsque le projet est terminé, comparez le temps réel au temps estimé et vous obtiendrez un biais pour chaque développeur. Quand un nouveau projet est démarré, demandez-leur de réévaluer le temps et de le multiplier par un parti pris de chaque développeur pour obtenir des valeurs proches de ce à quoi on s'attend vraiment.

Après quelques projets, vous devriez avoir de très bonnes estimations.