Disons dire qu'un membre de l'équipe est un congé annuel. Il ne participera pas à la planification du sprint, mais il sera de retour à la mi-itération/sprint. Disons qu'il a une capacité de 50%, comme il sera disponible pour la moitié ultérieure de l'itération, devrions-nous:
avoir une séance de planification avec lui après son retour.
avoir une séance de planification avec lui avant de partir en congé annuel, c'est-à-dire avant la planification de Sprint.
ne le programmez pas pour une tâche et attribuez-le sur des tâches non sprint. Spikes, etc.
demandez à ses pairs en son nom pendant 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 qu'il peut descendre.
demandez-lui de vous asseoir avec un autre développeur et faites une programmation par paire pendant un moment.
rien d'autre..
je suis intéressé à savoir ce que vous faites ..
NOTE: Nous faisons (1) et cela ne se sent pas bien.
La planification consiste à faire de l'engagement et de fractionnement des histoires d'utilisateurs commises aux tâches.
avoir une séance de planification avec lui après son retour.
Définitivement non. Séance de planification 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 de partir en congé annuel, c'est-à-dire avant la planification de Sprint.
Définitivement non. Il ne devrait y avoir aucune planification lorsque le sprint actuel n'est pas terminé = le résultat du sprint actuel est inconnu et personne ne sait si toutes les histoires d'utilisateurs seront terminées et que le client en sera satisfait de la révision.
ne le programmez pas pour une tâche et attribuez-le sur des tâches non sprint. Spikes, etc.
Définitivement non. Il sera de retour et sa capacité devrait être utilisée pour la cible Sprint.
demandez à ses pairs en son nom pendant 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 qu'il peut descendre.
C'est correct. L'équipe fait un engagement - pas un membre de l'équipe particulière. L'équipe s'engage à définir des histoires d'utilisateurs car elles connaissent leur vitesse et sur la base de leurs suppositions professionnelles, ils peuvent modifier l'engagement de la prochaine sprint en fonction de la capacité disponible. Il ne devrait y avoir aucune tâche assignée au développeur unique. Les développeurs doivent être croisés croisés, même si cela n'est pas toujours possible, ils devraient toujours être en mesure de passer au moins une histoire d'utilisation à des tâches. Il peut y avoir un problème d'estimation des tâches, mais à mon avis, il n'est pas nécessaire du tout.
demandez-lui de vous asseoir avec un autre développeur et faites une programmation par paire pendant un moment.
Définitivement non. La programmation par paire devrait être couverte par la vitesse elle-même. Si vous ne comptez pas avec le développeur, il est identique à dire qu'il sera en train de dire du sprint entier. Pourquoi le client doit-il payer l'heure du développeur qui n'a rien fait pendant le sprint?
Dans une équipe Agile idéale, les membres sont à l'aise avec toutes les technologies utilisées dans un projet et toute tâche peut être exécutée par (presque) tout membre d'une équipe. Si tel est le cas, après avoir dimensionné des tâches dans l'arriéré, définissez les membres de l'itération et des équipes qui choisissent leur premier ensemble de tâches à partir de l'arriéré, vous pouvez simplement laisser le reste des tâches dans le seau et ils seront ramassés par l'équipe. membres, y compris celui qui a manqué la session de planification.
Dans une autre situation commune, les membres de l'équipe sont spécialisés (l'un est un gars d'UI, un autre est un expert de la base de données, tiers est un gourou de middleware, etc.) Dans ce cas, le membre de l'équipe manquant obtiendrait ses tâches assignées en absence. Il pourrait avoir besoin de les réapparaître après qu'il vienne à bord.
Dans une équipe où "Scrum" travaille, l'équipe elle-même prendra le relais et proposera une solution créative. Cette situation ne se présente pas assez souvent pour justifier de décrire des cas spéciaux, juste "aller avec le flux" pour le reste du sprint. Après tout, ces sprints ne sont pas très longtemps de toute façon.
Vacances si planifiées/imprévues ne font que 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 absente de la réunion de planification du sprint. Dans une équipe, cela a un respect sain l'un pour l'autre comprendra les besoins personnels d'une personne et dans de telles équipes, il y a une confiance saine sur le type de travail qu'il fait. C'est avec cette confiance qu'ils planifient sur ce qu'ils peuvent faire, compte tenu du moment où différents individus émettraient du travail pour une itération/sprint particulière.
C'est les moments difficiles qui racontent comment une équipe professionnelle est. Dans une équipe de taille moyenne, dans notre société, il y a toujours une personne qui arrive à manquer la réunion de planification de sprint. Nous ne le criminalisons pas. Nous croyons qu'il est assez mature pour prendre sa décision :)
J'apprécie votre question tant que vous avez soif d'apprentissage et d'apprécier l'esprit de la méthodologie agile du développement de logiciels.
Où je travaille, 4 serait la solution commune prise. La personne (s) manquante (s) la réunion peut être en vacances, malade ou avoir quelque chose d'autre qui doit être fait à la place pour quelques cas où une personne disparue ne veut pas dire que le sprint ne devrait pas continuer. L'idée ici est que l'équipe reconnaissait quels types d'ajustements peuvent être faits si une personne est absente pendant la moitié d'un sprint, bien qu'il puisse y avoir plus de quelques ajustements effectués à la fin.
Les gens ont toujours tendance à avoir des vacances :-) Pas de mal fait.
Dans un groupe agile si quelqu'un a besoin de vacances si l'agile fonctionne correctement, une personne manquante ne doit pas faire une grande différence, oui, le groupe peut faire moins que la normale, mais cela signifie simplement faire moins de fonctionnalités dans cette itération.