¿Qué debo hacer si el miembro de Scrum se va a la mitad?

12

Debido a la condición de salud de uno de los miembros del scrum, tiene que dejar el equipo.

Mi pregunta es, ¿necesito comenzar una sesión de planificación de sprint nuevamente? ¿O cambiar el gráfico de quemado? ¿O pedir a todos los miembros del equipo que muerdan la bala y hagan un trabajo adicional para cumplir el objetivo?

Gracias

    
pregunta janetsmith 30.09.2011 - 23:30

5 respuestas

20

Debes quitar el alcance de las historias menos importantes y moverlas al siguiente sprint. Tu capacidad ha cambiado y el sprint debería reflejar eso.

Si el cliente agrega una nueva historia importante de alta prioridad, ¿qué hace? ¿Aceptarla y agregarla al sprint? Re-planear ¿Cambiar el gráfico de quemado? ¿Morder la bala? No. Desaconsejas otras historias porque no tienes capacidad.

Esto no es diferente: las circunstancias han cambiado y su equipo ya no puede comprometerse con el alcance inicial.

    
respondido por el Oded 30.09.2011 - 23:34
2
  1. no No le pides a la gente que trabaje horas extras. ¿Quieres más para salir?
  2. ¿Qué es un gráfico de quemado? Es el gráfico de los puntos que se completan en comparación con los puntos que debe completar antes de la fecha límite. Entonces, ¿por qué cambiarlo? Mantenga la gráfica y verá el efecto que tiene perder un desarrollador y puede mantener informado al cliente.
  3. El cliente puede usar esa información para descontinuar o extender la fecha límite. Lo que no se les puede permitir es decir que quieren más recursos. Los recursos se obtienen cuando los encuentra y se van cuando les da la gana y forzar a la persona incorrecta rápidamente no resolverá su problema. Esto es particularmente cierto a medida que se acerca la fecha límite.
  4. Si va a contratar a alguien, espere que eso también lleve tiempo, por lo que el costo será de más de una hora de desarrollo y la ganancia no será inmediata.
  5. Indique a la empresa que si no quieren que esto suceda en el futuro, deben contratar demasiados recursos al inicio del proyecto y mantenerse a la vanguardia del requisito esperado hasta cerca del plazo (cuándo, porque están por delante, pueden perder la mitad del equipo y no reemplazarlos en un momento en que los desarrolladores restantes no necesitan dedicar tiempo al entrenamiento).

Descargo de responsabilidad: Todo esto viene con la advertencia, "en un mundo perfecto". Ahora acérquese lo más que pueda y estará bien.

    
respondido por el pdr 30.09.2011 - 23:51
0

Como miembro del equipo o scrum master no hace nada, excepto informar al propietario del producto sobre la situación. Su equipo ya se comprometió con cierta cantidad de historias de usuarios basadas en alguna capacidad esperada. Algo malo sucedió y uno de los miembros de su equipo no puede continuar en el sprint debido a una condición de salud. Eso puede suceder y nadie puede culparlo ni a usted por eso.

Es decisión del propietario del producto decidir qué hacer a continuación. Es obvio que lo más probable es que no entregue lo que cometió. La propietaria del producto puede dejar que el sprint continúe tal como está, de modo que pueda completar tantas historias de usuario como sea posible sin perder a un miembro del equipo y horas extras irrazonables, o puede decidir detener el sprint y comenzar uno nuevo, pero sería bastante drástico.

El descopelado es peligroso. Sprint debe ser una zona segura para el equipo. Es parte de los principios ágiles para empoderar a las personas. El equipo está facultado para hacer un compromiso. Una vez que permita que el compromiso cambie durante el sprint, pronto se convertirá en una práctica común y desaparecerá todo el punto de compromiso y la zona segura. Obtendrás el caos con el objetivo de sprint que cambia continuamente.

    
respondido por el Ladislav Mrnka 03.10.2011 - 16:38
-1

Date cuenta de que el scrum tiene velocidad para ayudar a gestionar eso.

Entiendo que tu velocidad se ajustará al nuevo equipo con el tiempo. Ciertos lugares incluso permiten estimar una disminución en la velocidad, para ayudar a administrar mejor cuando los miembros del equipo se van o simplemente se van de vacaciones.     

respondido por el tylermac 03.10.2011 - 18:13
-2

Analizar el impacto en el sprint general. Identificar solución alternativa / trabajo alrededor. Discuta con el propietario del producto para mover menos prioridad / historias de usuarios importantes al próximo sprint. Incorpore recursos adicionales para este sprint o futuro sprint.

    
respondido por el Pani 23.05.2016 - 05:56

Lea otras preguntas en las etiquetas