Comment les «pointes» figurent-elles dans le jeu de planification / estimation? [fermé]

Question

Peut être subjectif et / ou une discussion .. mais voilà.

On m'a demandé d'estimer une fonctionnalité pour la prochaine grande affaire au travail. Je le décompose. Utilisez les points d’histoire avec une estimation. La fonctionnalité appelle toutefois à l’interface avec GoDiagrams un composant de diagramme tiers en plus de diverses autres initiatives de la société. (Tout un ensemble de frameworks / services 2008_Limited_Edition :). Je me suis suivi à l'aide d'un tableau de combustion et je me trouve incapable de maintenir mon rythme principalement en raison de "pics" .. Définition

J’estime 2 points par semaine, puis je me retrouve à travailler le week-end (en essayant de ne me retrouver ni ici ni là-bas) car je ne sais pas où je vais m'attacher pour pouvoir prévisualiser les actions des utilisateurs, montrer un menu contextuel, etc. En fin de compte, je passe du temps à créer des pics qui font dévier mon emploi du temps ... et diminue sa valeur ... ne donne pas la bonne image.

Des pointes sont nécessaires pour enfoncer les clous dans les planches de l’ignorance. Mais comment sont-ils pris en compte dans l'équation d'estimation? Faire tous les pics requis avant que la fonctionnalité ne semble erronée (il pourrait s'avérer que ce soit YAGNI). Le faire entre les deux m'interrompt. Pour le moment, c’est au stade de la planification de la pré-itération .. mais cela met la ligne de contact chaque semaine.

Answer 1

Je suppose que vous sous-estimez constamment

• ce que vous savez déjà sur le composant tiers
• combien de temps vous faut-il pour créer des pointes utilisables / utiles pour des zones inconnues

1. Améliorez votre estimation de ces deux choses.

Donc, tout est une question d'expérience. Peu importe la méthodologie que vous utilisez, ils vous aideront à mieux utiliser votre expérience et non à la remplacer.

2. Essayez de ne pas perdre la trace lorsque vous travaillez sur ces pics.

Elles devraient être courtes et limitées dans le temps. Il ne s'agit pas de jouer avec toutes les fonctionnalités possibles répertoriées sur les diapositives marketing. Donnez-leur la concentration, deux ou trois options à explorer. Attendez-vous à ce qu'ils obtiennent un résultat concret.

Mise à jour (Gishu): pour résumer

• Les pointes doivent être des tâches explicites définies dans l'étape de planification des itérations.
• Si les pics dépassent la période, arrêtez de travailler dessus. Doubler la tâche associée. Effectuez les autres tâches du compartiment d'itération en cours. Retournez à la tâche mise à l'écart ou ajoutez une pointe plus élaborée / décomposée à la prochaine itération avec la tâche associée. Marquez une estimation plus prudente avec le pic de la génération 1 la prochaine fois.

Answer 2

Si vous manquez de temps dans votre réserve, vous devez tout de même arrêter et terminer votre autre travail engagé. Vous devez ensuite ajouter une autre pointe à votre prochaine itération pour effectuer le travail nécessaire afin d'estimer avec précision la tâche résultant de la pointe.

S'il y a une préoccupation concernant les pointes pendant trop longtemps et que cela devient un problème - c'est l'une des raisons pour lesquelles j'aime les itérations d'une semaine. : -)

Answer 3

@pointernil .. Il s’agit plus d’une absence d’estimation couplée à une approche «Head-First» Indy-Jones pour aborder une histoire. J’estime les histoires en fonction de leur contenu. Actuellement, je ne prends pas en compte le temps requis pour trouver la bonne incantation pour que la bibliothèque de contrôle joue bien. Cela prend parfois plus de temps que la logique de mon application. Ainsi, pour reformuler la question initiale, les pointes devraient-elles être des tâches distinctes dans le plan d'itération, ajouté sur une base d'ECE avant de commencer à travailler sur une histoire particulière?

Mes spikes sont extrêmement concentrés. Je suis impatient de revenir au "réel". problèmes. par exemple. 'Comment afficher un menu contextuel à partir de ce contrôle?' Je suis peut-être coupable de ne pas lire l'intégralité du manuel de 150 pages ou des exemples de code .. mais le temps presse. La première solution qui résout le problème est acceptée et je passe à autre chose. Toutefois, lorsque vous ne parvenez pas à trouver cet événement évasif ou modèle de notification NIH utilisé par le composant, les pointes peuvent prendre beaucoup de temps. Comment définir une zone inconnue dans la zone de temps? Ma timebox est écoulée et je n'ai toujours aucun indice pour brancher mon menu contextuel personnalisé. Comment je procède? Tenir le piratage à distance?

Cela se trouve peut-être dans la zone "Buffering Uncertainity". Je vais regarder si je trouve quelque chose d’utile dans le livre de Mike Cohn.

Answer 4

Je suis d'accord avec pointernil. Le seul problème est que vos estimations sont incorrectes. Ce qui n’est pas un grand drame, à moins que vous veniez de faire sauter un projet de 3 millions de dollars, bien sûr: -)

Si cela se produit une fois, c’est une expérience d’apprentissage. Si cela se reproduit et que le résultat est meilleur, alors vous avez une autre expérience d'apprentissage à votre actif. Si vous sous-estimez constamment et que vos pourcentages augmentent, vous devez vous lever un peu. Aucune méthodologie ne vous sortira de là.

Il suffit de donner aux pointes le temps dont elles ont besoin. Mon expérience m'a souvent montré que les gens s'attendent à pouvoir maîtriser une technologie en quelques heures ou un jour. Cela n'arrive pas dans la vraie vie. Le problème le plus simple, même un bug provoqué par une faute de frappe, peut obliger un développeur à s'arracher les cheveux pendant très longtemps. Soyez honnête sur vos compétences et celles de votre personnel, et inscrivez-le dans le budget.