Que faire si un membre de l'équipe manque un planning de sprint?

Disons qu'un membre de l'équipe est en congé annuel. Il n'assistera pas à la planification du sprint mais il sera de retour au milieu de l'itération / du sprint. Disons qu'il a une capacité de 50%, c'est-à-dire qu'il sera disponible pour la moitié de l'itération, si nous:

1. avoir une session de planification avec lui après son retour.

2. avoir une séance de planification avec lui avant qu'il ne parte en congé annuel, c'est-à-dire avant la planification du sprint.

3. ne le programmez pour aucune tâche et ne l'affectez pas à des tâches non sprint, par exemple des pointes, etc.

4. demander à ses pairs de planifier en son nom lors de la planification du sprint et une personne absente peut alors ajouter des tâches quand il est de retour et s'il ne peut pas faire tout le travail, il peut détraquer.

5. demandez-lui de s'asseoir avec un autre développeur et de faire de la programmation en binôme pendant un certain temps.

6. rien d'autre..

je suis intéressé de savoir ce que vous faites ..

Remarque: nous faisons (1) et cela ne semble pas correct.

La planification consiste à s'engager et à diviser les user stories engagées en tâches.

avoir une session de planification avec lui après son retour.

Définitivement non. Planifier une session après son retour n'a pas de sens car l'engagement devait déjà être fait.

avoir une séance de planification avec lui avant qu'il ne parte en congé annuel, c'est-à-dire avant la planification du sprint.

Définitivement non. Il ne devrait pas y avoir de planification lorsque le sprint actuel n'est pas terminé = le résultat du sprint actuel est inconnu et personne ne sait si toutes les user stories seront terminées et le client en sera satisfait lors de l'examen.

ne le programmez pour aucune tâche et ne l'affectez pas à des tâches non sprint, par exemple des pointes, etc.

Définitivement non. Il sera de retour et sa capacité devrait être utilisée pour la cible de sprint.

demander à ses pairs de planifier en son nom lors de la planification du sprint et une personne absente peut alors ajouter des tâches quand il est de retour et s'il ne peut pas faire tout le travail, il peut détraquer.

C'est correct. L'équipe fait de l'engagement - pas un membre particulier de l'équipe. L'équipe s'engage à définir des histoires d'utilisateurs car elles connaissent leur vitesse et en fonction de leur estimation professionnelle, elles peuvent modifier l'engagement pour le prochain sprint en fonction de la capacité disponible. Aucune tâche ne doit être assignée à un seul développeur dès le départ. Les développeurs doivent être interfonctionnels même si ce n'est pas toujours possible, ils doivent toujours être en mesure de diviser au moins la user story en tâches. Il peut y avoir un problème d'estimation des tâches, mais à mon avis, ce n'est pas du tout nécessaire.

demandez-lui de s'asseoir avec un autre développeur et de faire de la programmation en binôme pendant un certain temps.

Définitivement non. La programmation par paire doit être couverte par la vélocité elle-même. Si vous ne comptez pas avec le développeur, c'est la même chose que de dire qu'il sera absent pendant tout le sprint. Pourquoi le client devrait-il payer le temps d'un développeur qui n'a rien fait pendant le sprint?

Dans un idéal, les membres d'une équipe agile sont à l'aise avec toutes les technologies utilisées dans un projet et n'importe quelle tâche peut être exécutée par (presque) n'importe quel membre d'une équipe. Si tel est le cas, après avoir dimensionné les tâches dans le backlog, défini l'itération et les membres de l'équipe choisissant leur premier ensemble de tâches dans le backlog, vous pouvez simplement laisser le reste des tâches dans le compartiment et elles seront récupérées par l'équipe membres, y compris celui qui a raté la séance de planification.

Dans une autre situation courante, les membres de l'équipe sont spécialisés (l'un est un gars de l'interface utilisateur, un autre est un expert de la base de données, le troisième est un gourou du middleware, etc.) Dans ce cas, le membre de l'équipe manquant se verrait assigner ses tâches en l'absence. Il devra peut-être les redimensionner après son arrivée à bord.

Dans une équipe où "Scrum" fonctionne, l'équipe elle-même va prendre le relais et trouver une solution créative. Cette situation ne se produit pas assez souvent pour justifier la description de cas particuliers, il suffit de "suivre le courant" pour le reste du sprint. Après tout, ces sprints ne sont pas très longs de toute façon.

Les vacances, planifiées ou non, ne sont qu'une partie du jeu. @Asim Ghaffar, les méthodes suggérées - au moins la plupart d'entre elles semblent criminaliser une personne qui s'est absentée de la réunion de planification du sprint. Dans une équipe, qui a un respect sain les uns envers les autres comprendra les besoins personnels d'une personne, et dans de telles équipes, il y a une saine confiance dans le type de travail qu'il fait. C'est avec cette confiance qu'ils planifient ce qu'ils peuvent faire, compte tenu du moment où différentes personnes seraient absentes du travail pour une itération / un sprint particulier.

Ce sont les moments difficiles qui indiquent à quel point une équipe est professionnelle. Dans une équipe de taille moyenne, dans notre entreprise, il y a toujours une personne qui peut manquer la réunion de planification du sprint. Nous ne le criminalisons pas. Nous pensons qu'il est suffisamment mûr pour prendre sa décision :)

J'apprécie votre question tant que vous avez soif d'apprendre et d'apprécier l'esprit de la méthodologie Agile de développement logiciel.

Là où je travaille, 4 serait la solution commune adoptée. La ou les personnes qui manquent la réunion peuvent être en vacances, malades ou avoir quelque chose d'autre à faire à la place pour quelques cas où le simple fait de manquer une personne ne signifie pas que le sprint ne devrait pas continuer. L'idée ici est que l'équipe reconnaisse quels types d'ajustements peuvent être effectués si quelqu'un est absent pour la moitié d'un sprint, bien qu'il puisse y avoir plus de quelques ajustements à la fin.

Les gens ont toujours tendance à prendre des vacances :-) aucun mal.

Dans un groupe agile, si quelqu'un a besoin de vacances si l'agile fonctionne correctement, une personne manquante ne devrait pas faire beaucoup de différence, oui, le groupe peut faire moins que la normale, mais cela signifie simplement faire moins de fonctionnalités dans cette itération.