Comment gérer les estimations des programmeurs rejoignant l'équipe?

L'itération a déjà commencé, un nouveau programmeur rejoint l'équipe, la tâche X a déjà été estimée à 30 heures par un développeur différent.

Quelle est la meilleure pratique dans cette situation?

• le nouveau développeur fonctionne avec l'estimation donnée (l'idée étant que tout écart sera corrigé lorsque la vitesse sera calculée?)
• nouveau développeur réévalue la tâche? (si c'est le cas, que se passe-t-il s'il est nettement plus élevé et ne correspond plus à l'itération?)
• lever les mains et retourner à la cascade?
• autre chose entièrement?

Ce que je dis c'est:

Un nouveau développeur réévalue la tâche. S'il doit être déplacé hors de l'itération, il est déplacé.

Vous ne savez pas si le nouveau développeur sera en mesure ou non de le faire dans le temps que le développeur d'origine prendra. Et avec les méthodologies agiles, le développeur qui fait le travail est celui qui devrait dire combien de temps cela prendra.

De plus, j'appliquerais un multiplicateur (quelle taille selon le développeur), car le développeur doit s'intégrer dans l'équipe / le projet / l'entreprise.

Je n'ajouterais pas cette personne à ce sprint individuel. Au lieu de cela, donnez-lui une autre tâche sur laquelle travailler pour se familiariser avec la base de code (peut-être des corrections de bogues peu importantes?)

L'ajout d'une nouvelle personne à l'équipe ralentira probablement vos progrès sur cet objectif particulier, car il devra s'habituer à votre environnement et apprendre comment les choses fonctionnent là-bas. Incorporez-le dans le prochain sprint, avec des estimations appropriées basées sur la nouvelle équipe.

Tout d'abord, j'entends "Agile Task" et je pense qu'un à deux jours de travail, pas une semaine. Les tâches sont ce que vous divisez en histoires lorsque l'histoire elle-même s'inscrit dans l'itération, et il est très rare d'avoir une histoire qui ne peut pas être décomposée en petits morceaux.

Deuxièmement, vous demandez essentiellement à ce nouveau développeur de se lancer. Si l'on peut raisonnablement s'attendre à ce qu'il saute le pas et poursuive le rythme du reste de l'équipe, alors l'estimation initiale devrait tenir. S'il ne le peut pas, il ne devrait probablement pas être tenu à cette estimation, du moins pas par lui-même.

Troisièmement, quelle est la situation? Je suis sûr que la situation n'était pas que l'équipe a estimé leur travail, puis quelqu'un est sorti et vous l'avez remplacé le lendemain. Donc, je pense que X gars de l'équipe ont estimé le travail de ce sprint et ont compris ce qu'ils pensaient pouvoir gérer, puis vous avez présenté le nouveau gars et maintenant il y a X + 1 gars pour faire le travail initialement engagé par X gars . À moins que l'équipe n'ait pas choisi sa charge de travail et que l'arriéré ait été surchargé par la direction, je ne donnerais pas grand-chose au nouveau gars cette semaine. Si le calendrier a été défini par la direction, ce n'est pas Agile.

Personnellement, je configurerais ce type pour qu'il s'associe avec un programmeur plus expérimenté pour son premier sprint (si vos programmeurs ne s'apparient pas tout le temps, ce que je déduis qu'ils ne le font pas du fait que vous envisagez d'en donner un tâche à un gars). En regardant par-dessus son épaule et en posant des questions, il commencera à apprendre la base de code, et si ses compétences générales en programmation sont à la hauteur, il sera un réviseur de code efficace presque immédiatement, repérant des bogues, du code inefficace, etc.