¿Quién debe definir, asignar, implementar y seguir las tareas en Scrum?

10

Los roles en scrum son Product Owner, Scrum Master y Scrum Team. Una historia de usuario también debe dividirse en partes más pequeñas llamadas tareas. Una tarea parece tener cuatro fases, a saber, definición, asignación, implementación y seguimiento.

¿Quién debería hacer qué en Scrum sobre las tareas? ¿Es responsabilidad del scrum master actualizar las horas restantes de una tarea, o es responsabilidad del desarrollador (equipo scrum)? ¿Deben los desarrolladores asignarse tareas a sí mismos o es responsabilidad del scrum master acompañado por el propietario del producto?

— Saeed Neamati
fuente

12

Ágil sigue varios principios. Uno de ellos es: Empoderar a las personas. Debido a eso, las tareas deben ser definidas por el equipo y las tareas deben ser seleccionadas por los miembros del equipo. Las tareas no deben asignarse a un miembro del equipo. El equipo debe ser autoorganizado y, debido a esa distribución de tareas difíciles / fáciles / interesantes / aburridas, debe ser uniforme.

Scrum Master debe asegurarse de que el equipo siga los principios de Scrum. Él no es un gerente de proyecto.

Esto es teoría y funciona para equipos maduros. Para los principiantes de Scrum, a veces puede ser difícil, pero al menos debes insistir en que los miembros del equipo seleccionen la tarea ellos mismos en lugar de asignarlos.

actualizar las horas restantes de una tarea

En mi opinión, estimar tareas y mantener el tiempo restante es una pérdida. Usted se comprometió con el conjunto de historias de usuarios, por lo que no importa cuánto tiempo llevará cada tarea. Lo único importante es si la historia del usuario se completará o no.

— Ladislav Mrnka
fuente

3

No estoy de acuerdo con que estimar las tareas y mantener el tiempo restante sea un desperdicio. Descubrí que el "tiempo restante" es la mejor señal de advertencia temprana que puede obtener cuando las cosas comienzan a ir inesperadamente. No tiene que ser súper preciso, pero el Scrum Master debe saber si una estimación es A) que no cambia o B) aumenta. Esto a menudo puede suceder si hay un impedimento oculto (incluso para el desarrollador). En un nuevo equipo de scrum, esto también ayuda con la transparencia, y ayuda a prevenir el "Yo hice x ayer, voy a hacer más x hoy".

— Brook

@Brook: Esa es la razón por la cual Scrum usa el gráfico Burndown. Si usa el gráfico de burndown para mostrar historias de usuarios completas (con una complejidad definida por los puntos de la historia), aún tendrá tales comentarios. En mi experiencia, la retroalimentación será aún mejor porque no terminará (ejemplo) con 10 horas de trabajo no completado, lo que significa 10 historias de usuarios con cada 1 hora faltante.

— Ladislav Mrnka

Si pudiera, daría esta respuesta +10. En el clavo, absolutamente correcto.

— wolfgangsz

@Ladislav Mrnka: Obtendrá datos similares de la quema, pero tener el trabajo restante le brinda detalles más precisos y puede advertirle antes. Es un punto discutible si todas sus tareas toman <día, pero ocasionalmente cuando una tarea toma> 1 día, el trabajo restante puede dar un indicador rápido de si preocuparse o no. Por lo general, no le pido a la gente que piense mucho, sea cual sea su instinto, por lo que no es una métrica tan engorrosa para agregar.

— Brook

¿Cuanto antes? Sprint debería ser "corto": ¿cuánto antes debería ser advertido? Usé una regla muy simple. Si no tenemos al menos 1/3 de historias de usuarios (puntos de historia) realizadas en la mitad del sprint, probablemente no podremos entregar todo lo que comprometimos. Funcionó bastante bien y no tuvimos que estimar nada. Con sprints que toman 2 o 3 semanas, no necesitas mucho más.

— Ladislav Mrnka

6

¿Deben los desarrolladores asignarse tareas a sí mismos o es responsabilidad del scrum master acompañado por el propietario del producto?

Los lugares donde he trabajado que han seguido a Scrum han hecho ambos, aunque idealmente los desarrolladores deberían elegir sus propias tareas. En última instancia, no importa mientras se realicen todas las tareas.

Hay ventajas y desventajas de cada enfoque.

Dejar que el equipo elija el suyo:

Profesionales: el equipo se siente dueño de la tarea, elige los que considera que pueden hacer un buen trabajo. La propiedad es un aspecto importante del desarrollo que mucha gente pasa por alto.
contras: algunas tareas se dejan hasta el final cuando sería mejor hacerlas primero.

Tener tareas asignadas:

Pros: todas las tareas se consideran por igual y ninguna se deja fuera.
contras: los miembros del equipo no necesariamente se sienten dueños de la tarea.

En la vida real, debe adoptar un enfoque pragmático. Habrá momentos en que las tareas deben asignarse, pero estos deben ser pocos en número.

— ChrisF
fuente

+1 - para alguien que tiene la última palabra. Alguien tiene que estar a cargo.

— JeffO

2

Aprecio que cierto pragmatismo sea algo útil, pero asignar tareas a los desarrolladores definitivamente NO es la forma en que Scrum hace las cosas.

— wolfgangsz

@ChrisF: ¿Puedes aclarar dónde en Scrum dice que ScrumMaster tiene autoridad de anulación y que otros tienen permitido asignar tareas para los desarrolladores?

— Martin Wickman

@ Martin - no, no puedo. Principalmente porque ha pasado un tiempo desde que trabajé con Scrum. Sin embargo, el pragmático en mí afirma que en algún momento alguien tendrá que tomar una decisión.

— ChrisF

Un poco tarde en el juego, pero mis 2 ¢: creo que si algunas tareas se dejan hasta el final cuando deberían haberse realizado primero, eso significa que su Scrum Master (y el propietario del producto) no están poniendo suficiente énfasis en esas tareas.

— Wayne Werner

2

En nuestro proceso de scrum, hacemos lo siguiente:

Las tareas están definidas por el grupo de desarrolladores, quienes probablemente implementarán la historia del usuario.

Al menos dos desarrolladores son responsables de la implementación de una historia de usuario, por lo tanto, serán asignados a las tareas automáticamente (si pueden trabajar en paralelo, tomarán la tarea más adecuada para ellos de acuerdo con su conocimiento y sabor personal. De lo contrario, emparejará el programa).

— Benni
fuente

2

¿Quién actualiza las horas restantes de una tarea?

Solo los desarrolladores pueden saber cuánto trabajo queda, por lo que proporcionan la información. Exactamente quién actualiza las horas no es importante.

¿Deberían los desarrolladores asignarse tareas a sí mismos?

Si. El acto de seleccionar tareas para usted mismo es poderoso porque lo compromete firmemente a completarlo de una manera que no sería posible si alguien más lo asignara por usted.

— Martin Wickman
fuente

2

Guía Scrum

Todo lo que tiene que ver con las tareas es responsabilidad del equipo en Scrum. El equipo generalmente presentará una descomposición de historias en tareas durante la segunda mitad de la reunión de planificación del sprint, pero se pueden introducir nuevas tareas o se pueden eliminar tareas en cualquier momento durante el sprint a medida que sale nueva información. En mi opinión, este ciclo de retroalimentación diaria es una parte importante de Scrum.

ScrumMaster no es el líder del equipo ni su administrador. El papel de ScrumMaster es facilitar el proceso de Scrum y eliminar los impedimentos. ScrumMaster no asigna tareas a los desarrolladores. El propietario del producto no asigna tareas a los desarrolladores. El equipo entrega valor al propietario del producto (y por extensión al cliente) al implementar las historias de los usuarios.

El equipo es responsable de todas las estimaciones. Por lo tanto, posee las estimaciones para las tareas (e historias) en el tablero.

— Guy Sirton
fuente