¿Qué hacer si un miembro del equipo pierde una planificación de sprint?

Digamos que un miembro del equipo está de vacaciones anuales. No asistirá a la planificación del sprint, pero regresará a mediados de la iteración / sprint. Digamos que tiene una capacidad del 50%, es decir, ya que estará disponible para la mitad posterior de la iteración, si:

1. tener una sesión de planificación con él después de que regrese.

2. tener una sesión de planificación con él antes de irse de vacaciones anuales, es decir, antes de la planificación del sprint.

3. no lo programe para ninguna tarea y lo asigne a tareas que no sean de sprint, por ejemplo, picos, etc.

4. haga que sus compañeros planifiquen en su nombre durante la planificación del sprint y la persona ausente puede agregar tareas cuando regrese y si no puede hacer todo el trabajo que puede desear.

5. haga que se siente con otro desarrollador y que haga un par de programación por un tiempo.

6. Algo más..

Estoy interesado en saber lo que estás haciendo.

Nota: Estamos haciendo (1) y no se siente bien.

La planificación se trata de comprometerse y de dividir historias de usuarios comprometidos en tareas.

tener una sesión de planificación con él después de que regrese.

Definitivamente no. La planificación de la sesión después de su regreso no tiene sentido porque el compromiso ya había sido hecho.

tener una sesión de planificación con él antes de irse de vacaciones anuales, es decir, antes de la planificación del sprint.

Definitivamente no. No debe haber planificación cuando no se completa el sprint actual = el resultado del sprint actual es desconocido y nadie sabe si todas las historias de usuarios se completarán y el cliente estará satisfecho con ellas en la revisión.

no lo programe para ninguna tarea y lo asigne a tareas que no sean de sprint, por ejemplo, picos, etc.

Definitivamente no. Regresará y su capacidad debería usarse para el objetivo de sprint.

haga que sus compañeros planifiquen en su nombre durante la planificación del sprint y la persona ausente puede agregar tareas cuando regrese y si no puede hacer todo el trabajo que puede desear.

Esto es correcto. El equipo se compromete, no un miembro del equipo en particular. El equipo se compromete a establecer un conjunto de historias de usuarios porque conocen su velocidad y, según su conjetura profesional, pueden modificar el compromiso para el próximo sprint en función de la capacidad disponible. No debe haber tareas asignadas a un solo desarrollador por adelantado. Los desarrolladores deben ser multifuncionales, aunque no siempre es posible, deben poder dividir al menos la historia del usuario en tareas. Puede haber problemas con las tareas de estimación, pero en mi opinión no es necesario en absoluto.

haga que se siente con otro desarrollador y que haga un par de programación por un tiempo.

Definitivamente no. La programación de pares debe estar cubierta por la velocidad misma. Si no cuentas con el desarrollador, es lo mismo que decir que él estará lejos todo el sprint. ¿Por qué el cliente debe pagar el tiempo del desarrollador que no hizo nada durante el sprint?

En un equipo ágil ideal, los miembros se sienten cómodos con todas las tecnologías utilizadas en un proyecto y cualquier tarea puede ser ejecutada por (casi) cualquier miembro de un equipo. Si ese es el caso, después de clasificar las tareas en el trabajo atrasado, definir la iteración y los miembros del equipo seleccionando su primer conjunto de tareas del trabajo atrasado, puede dejar el resto de las tareas en el cubo y el equipo las recogerá miembros, incluido el que se perdió la sesión de planificación.

En otra situación común, los miembros del equipo están especializados (uno es un tipo de interfaz de usuario, otro es un experto en bases de datos, el tercero es un gurú de middleware, etc.) En ese caso, al miembro del equipo desaparecido se le asignarían sus tareas en ausencia. Sin embargo, es posible que deba cambiar el tamaño después de subir a bordo.

En un equipo en el que está trabajando "scrum", el equipo mismo tomará el relevo y propondrá una solución creativa. Esta situación no se presenta con la frecuencia suficiente para justificar la descripción de casos especiales, simplemente "siga la corriente" por el resto del sprint. Después de todo, estos sprints no son muy largos de todos modos.

Las vacaciones, ya sean planificadas / no planificadas, son solo parte del juego. @Asim Ghaffar, los métodos sugeridos, al menos la mayoría de ellos, parecen estar criminalizando a una persona que se ausentó de la reunión de planificación del sprint. En un equipo, el respeto mutuo entre ellos comprenderá las necesidades personales de una persona, y en tales equipos existe una confianza saludable sobre el tipo de trabajo que realiza. Es con esta confianza que planean lo que pueden hacer, considerando el momento en que diferentes personas estarían fuera del trabajo para una iteración / sprint en particular.

Son los tiempos difíciles los que indican cuán profesional es un equipo. En un equipo de tamaño medio, en nuestra empresa siempre hay una persona que se pierde la reunión de planificación de sprint. No lo criminalizamos. Creemos que es lo suficientemente maduro como para tomar su decisión :)

Agradezco su pregunta siempre que tenga sed de aprender y apreciar el espíritu de la metodología ágil de desarrollo de software.

Donde trabajo, 4 sería la solución común tomada. La (s) persona (s) que faltan a la reunión puede estar de vacaciones, enferma o tener que hacer algo más en algunos casos en los que el hecho de que alguien falte no significa que el sprint no deba continuar. La idea aquí es que el equipo reconozca qué tipo de ajustes se pueden hacer si alguien está ausente durante la mitad de un sprint, aunque al final puede haber más de unos pocos ajustes.

La gente siempre tiende a tener vacaciones :-) sin daño.

En un grupo ágil, si alguien necesita vacaciones si el ágil funciona correctamente, una persona desaparecida no debería marcar una gran diferencia, sí, el grupo puede hacer menos de lo normal, pero solo significa hacer menos funciones en esa iteración.