Combien de temps passer à estimer les tâches de programmation?

9

Par exemple, si je divise un projet en n produits de travail discrets (disons des classes ou des fonctions ou des composants), y a-t-il un temps t tel que n * t est un temps approprié à consacrer à l'estimation?

estimation

— Michael Behan
source

9

C'est facile. Prévoyez juste un peu de temps pour examiner votre charge de travail et estimer approximativement combien de temps les estimations prendront et ... oh, attendez.

— joshin4colours

Puisque vos estimations seront toutes fausses tout le temps, zéro retour sur investissement = zéro temps passé. Oh, sauf que les patrons vous forceront à créer de fausses estimations. Les estimations agiles où vous choisissez un certain nombre aléatoire de fibonacci dans une unité de mesure sans unité aléatoire appelée BogoEstimons, ou quelque chose, semblent meilleures que les estimations dans les unités de travail réelles en heures humaines.

— Warren P

Estimer le temps nécessaire pour estimer la tâche. Que la réception d'estimation commence

— utilisateur

13

Si vous avez suffisamment d'informations pour les avoir décomposées à ce niveau, vous ne devriez pas consacrer plus d'une minute à chacune d'elles. Tu ne vas pas être correct de toute façon, mais tu vas être aussi correct après une minute qu'après une heure.

Si, par contre, vous parliez de témoignages d' utilisateurs , je suggérerais de mettre les parties prenantes dans une pièce et de passer cinq minutes à poser des questions avant d'estimer.

Quoi qu'il en soit, ne perdez pas beaucoup de temps à faire des estimations. Ils ne sont pas suffisamment utiles ou précis pour mériter l'effort.

— pdr
source

3

+1. mais je ne suis pas d'accord pour dire que les estimations ne sont pas très utiles. Ils aident à mieux planifier et sont donc plus productifs.

— superM

4

@superM: Je n'ai pas dit qu'ils n'étaient pas du tout utiles. Ils le sont certainement. J'ai dit qu'ils ne valaient pas beaucoup de temps. Un logiciel fonctionnel est beaucoup plus utile, alors passez la majeure partie de votre temps à cela.

— pdr

@superM: Avez-vous déjà fait une comparaison entre vos estimations et les valeurs réelles? Cela nous dira une grande leçon sur la valeur réelle de la conjecture (qui est une estimation par définition). L'estimation est une chose Pareto classique: vous obtenez une assez bonne estimation en 20% du temps. Si vous perdez plus de temps, cela ne fera que 5% de mieux.

— JensG

Pour moi, plus je travaille sur un projet, meilleures sont mes estimations. Il y a trop de facteurs et certains de ceux que je ne peux pas contrôler, et connaître ces facteurs [spécifiques au projet] vient avec l'expérience. Parfois, vous ne pouvez tout simplement pas échapper à l'estimation, et parfois vous faites partie de ceux qui souffrent de vos estimations inexactes.

— superM

2

D'après mon expérience, l'un des éléments fondamentaux d'une approche agile «oui, ça marche vraiment» est la directive «Les tâches devraient prendre moins d'une journée». Si vous estimez des choses qui prennent plus d'une journée, vous allez être assez loin.

Une fois que vous les avez décomposés pour pouvoir le faire, vous en avez fait assez; indépendamment de ce que ces choses sont.

— Telastyn
source

2

Dans la méthodologie agile Scrum, Planning Poker est considéré comme un moyen efficace d'utiliser toute l'équipe pour estimer rapidement l'effort requis pour les user stories dans un sprint (en supposant que c'est de cela dont vous parlez). Sinon, je ne passerais pas plus de quelques minutes à estimer une seule tâche qui fait partie d'une user story.

Je recommande fortement d'utiliser cette technique basée sur le consensus si vous essayez de faire des estimations pour une équipe de développeurs.

Planifier le poker signifie que vous pouvez obtenir de très bonnes estimations pour chaque histoire d'utilisateur unique en une seule session (pas plus de 1 à 2 heures).

Faites un peu de lecture à ce sujet et essayez-le!

De plus, en règle générale, aucune tâche dans une user story ne doit dépasser 7,5 heures (une seule journée de travail). Si c'est le cas, vous devez diviser la tâche en tâches plus petites.

— Ciaran Gallagher
source

1

Planning poker estime les points, qui ne sont en aucune unité réelle. Ce qui les rend analogues à la réalité des estimations; Wild Ass Guessery.

— Warren P

1

L'idée est que si nous savons qu'une tâche en 1 point prendra 7,5 heures, par exemple, alors nous pouvons dire qu'une user story en 5 points prendra 30 heures et qu'une user story en 10 points prendra 60 heures. Par exemple, nous pouvons choisir l'une des plus petites tâches, et le temps estimé peut être attribué comme valeur d'un point de récit utilisateur unique. Ensuite, nous pouvons utiliser cette user story comme base pour estimer des tâches plus importantes. Si nous pensons qu'une autre tâche prendra deux fois plus de temps, nous attribuerons 2 points de récit utilisateur (15 heures), etc.

— Ciaran Gallagher

1

Je pense que cela dépend de ce dont vous avez besoin. Si, par exemple, l'allocation des ressources de votre projet en dépend (comme c'était parfois le cas ici), il vaut mieux le faire avec soin. Dans l'autre sens, si vous faites un projet qui n'a pas ce genre de nécessité, vous ne pouvez pas entrer dans trop de détails. Passer trop de temps dessus n'est pas une bonne idée car il est très difficile de faire une estimation précise.

Il y a un concept célèbre appelé Cône d'incertitude et Cône d'incertitude sur Wikipedia qui dit à quel point une estimation peut généralement être précise. Cela vaut la peine d'être lu.

— Joqus
source

1

Que retirez-vous de vos estimations?

Selon ce sur quoi vous travaillez, des estimations individuelles précises peuvent être pertinentes (le client vous paie à la fin de la semaine ou la tâche / l'histoire bloque les autres et un ETA précis est requis) ou non (vous avez 200 histoires dans le carnet de commandes, personne ne mourra si une histoire se déroule pendant une semaine, et vous comptez sur des erreurs d'estimation pour faire une moyenne correcte sur un grand nombre d'entre elles).

Il vous suffit de passer le minimum de temps pour obtenir une estimation suffisamment adaptée à vos besoins. Il n'y a pas de formule.

Personnellement, je considère que plus d'une minute ou deux signifie que vous estimez probablement la mauvaise chose (divisez-la ou planifiez la découverte).

— ptyx
source

0

En fait, vous avez besoin d'estimation pour aider les autres parties prenantes à attribuer une priorité relative - des estimations générales qui disent au moins que la tâche 1 représente environ 3 fois l'effort par rapport à la tâche 2 (même si en termes d'heures ce n'est pas très précis au final) sont utiles. Passez autant de temps que nécessaire pour comprendre quelles sont ces tâches (pour atteindre certains objectifs) et ensuite avoir des estimations approximatives pour elles.

Une fois que vous avez une priorité relative, concentrez-vous simplement sur les choses et ajustez les estimations en cours de route. En d'autres termes, passez peu de temps dans les estimations initiales, mais affinez vos estimations au fil du temps afin que le plan du projet donne une bonne idée du moment où ce sera fait.

— Roopesh Shenoy
source

0

Les bonnes estimations sont celles qui sont basées sur des faits et non sur des hypothèses.

Ainsi, si vous aviez déjà un projet similaire et capturé votre temps d'estimation précédent, cela pourrait servir de bonne base d'estimation pour commencer . Cependant, selon la portée de votre projet, il peut y avoir des artefacts inconnus , ce qui est préférable de clarifier avec BA ou le propriétaire du produit dès que possible.

Il est également vrai de dire que: L'estimation de projet logiciel est intrinsèquement inexacte . Cependant, il existe des pratiques d'estimation réalistes qui pourraient aider:

Les personnes qui font le travail devraient participer à l'estimation du projet
Faites appel aux experts: le jugement des experts est essentiel à la réussite du projet
Estimer de grandes pièces comme une gamme
Utilisez la technique Delphi: il s'agit d'une méthode qui permet de faire converger les opinions de l'équipe en cas de conflit dans l'estimation de projet logiciel.
Gardez à l'esprit le coût
Gardez à l'esprit les ressources allouées disponibles pour effectuer le travail

— Yusubov
source

Je n'ai jamais observé une équipe ou un individu qui a fait des estimations qui, de façon routinière (plus de 50% du temps) se sont avérées exactes dans les 10% du temps réel passé. D'autres personnes dans d'autres endroits réclament des succès qui me semblent difficiles à imaginer se produire n'importe où dans mon travail.

— Warren P

"précis à moins de 10% du temps réel passé" - est en fait un résultat très médiocre. Tenez également compte de la marge d'erreur, qui augmente en fonction de la complexité et des dépendances externes du projet.

— Yusubov

C'est ce que je dis. L'estimation est nulle.

— Warren P

yeap, c'est vraiment un gros coup pour avoir "précis dans les 10% du temps réel passé" ...

— Yusubov