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.
