Estimation du temps nécessaire à l'accomplissement des tâches

Question

Je sais que cette question a été posée à plusieurs reprises sur ce site/programmeurs et qu'il s'agit d'une question assez courante et classique :

Comment estimer avec précision la durée d'une tâche ?

Le problème que je rencontre est que pour les tâches de type pointer-cliquer dans Windows, je peux donner des estimations précises. Pour coder quelque chose de nouveau (en utilisant des API que je ne connais pas), je ne peux pas estimer un temps précis pour sauver ma vie. Il s'agit de penser et de dire le premier nombre (de jours/semaines/quoi que ce soit) qui me vient à l'esprit. Pour le code qui utilise des API avec lesquelles je suis familier et des applications que je peux instantanément dire que je peux développer (par exemple, une application de type bloc-notes), je pourrais donner une estimation précise.

Toute aide est la bienvenue.

Remerciements

Answer 1

Concentrez-vous sur les pièces. Lorsque vous essayez d'estimer une tâche à un niveau élevé, non seulement elle est décourageante, mais vous ne parviendrez pas à prendre en compte avec précision tous les éléments qui composeront le temps total.

Au lieu de cela, n'essayez même pas de deviner le total (non seulement ce n'est pas utile, mais cela peut en fait fausser vos estimations des tâches individuelles), mais asseyez-vous plutôt et essayez de penser à toutes les sous-tâches qui composent la tâche. Si celles-ci vous semblent trop importantes, décomposez-les en soustâches encore plus petites.

Une fois que vous avez fait cela, donnez une estimation à chacune des tâches secondaires. Si l'une d'entre elles dépasse les 4 heures, il est probable que la tâche secondaire n'a pas été suffisamment décomposée. Additionnez toutes ces estimations. C'est votre estimation.

Cette approche vous oblige à raisonner sur ce qui est réellement nécessaire pour accomplir la tâche et vous permettra de produire de meilleures estimations.

Veillez également à penser aux étapes non évidentes nécessaires à l'accomplissement d'une tâche. Si vous écrivez un morceau de code, avez-vous inclus des estimations de temps pour l'écriture des tests unitaires associés ? Pour tester le code ? Pour le documenter ?

Lorsque vous convertissez des heures en jours, faites preuve de réalisme quant au temps que vous passerez réellement à travailler la tête en bas. Le consensus général est qu'un développeur peut accomplir 4 à 6 heures de travail dans une journée de 8 heures. Cela correspond à peu près à mon expérience personnelle.

Si vous avez d'autres membres de l'équipe, vous pouvez essayer une technique appelée Planifier le poker . Dans sa forme la plus simple, l'idée est de demander à chaque membre de l'équipe d'estimer individuellement chacune des tâches. Une fois cette étape franchie, l'équipe se réunit et compare les estimations à la recherche d'écarts importants. Cela permet de savoir si la tâche n'était pas assez claire, si certains membres de l'équipe possèdent des informations pertinentes que les autres n'ont pas, ou si différents membres de l'équipe font des hypothèses différentes.

Lorsque vous effectuez vos estimations, soyez conscient de vos hypothèses et documentez-les dans le cadre des estimations. En supposant x, y et x, la tâche q devrait prendre n heures. Il peut s'agir d'éléments tels que la disponibilité d'un ingénieur AQ pour tester la fonctionnalité, la disponibilité d'un environnement de développement dans lequel déployer la fonctionnalité pour la tester, la compatibilité de deux frameworks tiers qui n'ont pas encore été testés ensemble, la fonctionnalité z dont dépend la tâche et qui doit être prête à une certaine date... Etc. Nous faisons des tonnes de ces hypothèses tout le temps sans en être conscients. Les documenter vous oblige à en être conscient et permet à d'autres parties de valider que vos hypothèses sont correctes. Et si les estimations s'avèrent fausses, vous disposez de beaucoup plus d'informations pour en analyser les raisons.

Même en suivant tous ces conseils, vous ferez encore souvent des estimations inexactes, mais ne vous sentez pas trop mal car notre cerveau est câblé pour produire des estimations terribles pour des tâches abstraites. Nous avons une multitude de biais cognitifs qui affectent notre capacité à évaluer la taille et l'effort d'une tâche.

Je vous recommande de lire cet article pour obtenir encore plus d'informations et de conseils :

http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/

Answer 2

J'ai surtout travaillé sur des projets de "petite" durée, mais ce qui a bien fonctionné pour moi, c'est de diviser la tâche en sous-tâches suffisamment petites pour que je pense pouvoir les mettre en œuvre toutes en une journée environ. Pour certains éléments, cela signifie seulement deux ou trois sous-tâches, pour d'autres, cela peut représenter des dizaines ou des centaines. Ajoutez un certain pourcentage de frais généraux gaspillés dans des activités non productives, un certain pourcentage de frais généraux pour l'exploration de mauvaises directions, et vous obtiendrez, je l'espère, un chiffre qui se situe dans une fourchette raisonnable du résultat final.

Answer 3

Ce que je fais habituellement, c'est décomposer les tâches en petites tâches. la tâche la plus importante ne devrait pas dépasser 2 jours. l'estimation des petites tâches n'est pas si difficile. chaque petite tâche a son temps de test inclus dans l'estimation, de sorte que je ne me retrouve pas avec une tonne de code non testé à la fin du projet.

La décomposition de la tâche en petits morceaux n'est possible que s'il existe une conception de haut niveau, sinon l'estimation n'est qu'une approximation qui est généralement de 2 semaines, les fameuses 2 semaines qu'utilisent la plupart des développeurs ;)

L'ajout d'un peu de temps à la fin du projet pour intégrer-stabiliser-corriger les bogues en fait une estimation raisonnable.

Answer 4

Similaire à ce que sarnold mais il peut être plus difficile de réduire la tâche à des incréments d'un jour si l'on ne comprend pas le domaine ou les technologies concernés. Dans votre cas, je suggérerais ce qui suit (en particulier si cette tâche ne semble pas devoir prendre moins de quelques jours) :

1) Tout d'abord, vous devez demander à votre équipe/collègues s'ils peuvent vous éclairer (et/ou s'ils ont utilisé les mêmes API/technologies que vous). Si personne ne sait rien, vous devrez admettre que vous n'avez tout simplement pas assez de données pour avancer une hypothèse raisonnable et que vous devrez consacrer X jours à la recherche (le temps nécessaire à la recherche doit être aligné sur la complexité de l'API/du domaine avec lequel vous travaillez).

2) À la fin du temps que vous avez alloué à l'étude de la nouvelle technologie, vous devriez être en mesure de réaliser une application très basique de type "hello, world" qui utilise l'API (elle se compile, se lie et fonctionne correctement). À ce stade, vous devriez être en mesure de déterminer si votre tâche va prendre des jours, des semaines ou des mois.

3) La prochaine chose à faire est de.., dans les meilleurs délais Le plus important, c'est d'identifier les obstacles majeurs qui risquent de réduire à néant vos prévisions... c'est essentiel. La pire chose que vous puissiez faire est d'aller continuellement voir votre responsable/client à la date d'échéance et de lui dire que vous avez besoin d'un délai supplémentaire important pour livrer le produit. Ils ont besoin d'être prévenus le plus tôt possible pour pouvoir remédier à la situation et/ou trouver un plan B.

Et c'est à peu près tout... ce n'est pas sorcier, mais il s'agit essentiellement de fournir une estimation une fois que l'on est en mesure d'en donner une, puis de s'assurer que l'on met à jour cette estimation sur la base d'événements nouveaux, non anticipés, qui ont un impact significatif sur notre capacité à respecter les dates prévues.