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
la source
la source
Réponses:
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.
la source
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.
la source
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.
la source
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.
la source
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).
la source
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.
la source
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:
la source