Scrum diario: Difference between revisions
| Line 13: | Line 13: | ||
En la reunión está '''presente todo el equipo''', y pueden asistir también otras personas relacionadas con el proyecto o la organización, aunque éstas no pueden intervenir. | En la reunión está '''presente todo el equipo''', y pueden asistir también otras personas relacionadas con el proyecto o la organización, aunque éstas no pueden intervenir. | ||
''' | Los '''desarrolladores''' son responsables de esta reunión, no el [[Scrum Master]]; y no se trata de una reunión de “inspección” o “control” sino de comunicación entre el equipo para compartir el estado del trabajo, chequear el ritmo de avance y colaborar en posibles dificultades o impedimentos. | ||
El papel del scrum master es facilitar, y encargarse de realizar las gestiones adecuadas para resolver estas últimas tras la reunión. | |||
===Durante la reunión=== | ===Durante la reunión=== | ||
Es frecuente que cada desarrollador explique lo que ha logrado desde el anterior scrum diario, lo que va ha hacer hasta el siguiente, y si está teniendo algún problema o si prevé que puede encontrar algún impedimento. | |||
Se actualiza sobre la pila del sprint el esfuerzo que estima pendiente en las tareas que tiene asignadas, o se marcan como finalizadas las ya completadas. | |||
===Al finalizar== | |||
Al final de la reunión el equipo de desarrollo refresca el gráfico de avance del sprint con las estimaciones actualizadas. | |||
==Evolución del formato tradicional== | |||
===Al final de la reunión | Se ha observado que este '''formato de participación individual puede tener efectos negativos''' en la motivación y las dinámicas de equipo. Aunque puede ser un punto de partida, se recomienda '''evolucionar hacia''' un formato de reunión que '''se enfoque en el trabajo, no en las personas'''. | ||
Este formato alternativo de la reunión sería así: los desarrolladores, que son quienes llevan la reunión, observan el estado de avance. Viendo qué hay en curso, se auto-asignan el trabajo aún pendiente siguiendo el orden de prioridad y asegurándose de que no se formen cuellos de botella. Este formato, que se centra en las historias o tareas en lugar de ir persona a persona, reduce la duración de las reuniones, aumenta la autonomía de los equipos, y mejora la colaboración. Por ejemplo, se ve con más frecuencia que varios desarrolladores decidan trabajar juntos en la misma historia prioritaria para garantizar que salga adelante si puede generar retrasos. | |||
==Véase también== | ==Véase también== | ||