Scrum Taskboard: ¿pueden cambiar las tareas?

Question

La empresa para la que trabajo actualmente está buscando pasar de la cascada tradicional a Scrum para su desarrollo. Estamos en el proceso de adoptar lentamente las prácticas que podemos sin hacer un cambio completo (¡aún tenemos mucho que aprender antes de que podamos seguir avanzando!).

Una de las cosas que queremos implementar ahora, antes de hacer el cambio completo, es la tabla de tareas. Todos sentimos que es una gran herramienta que puede ayudar con el desarrollo, y ayuda a mantener a esos usuarios de negocios a raya con el "¿qué estás haciendo?" y "¿cómo te va?" preguntas y reuniones

Con todo lo dicho, una cosa que me he estado preguntando es si las tareas en la placa de tareas pueden cambiar. Sé que no quieres cambiar Historias, pero ¿qué hay de las tareas dentro de una historia? ¿Qué ocurre si surge una nueva tarea o una tarea anterior ya no es válida? ¿Se pueden agregar y/o eliminar a mediados de sprint (aunque realmente no estamos usando sprints, más bien como ciclos de desarrollo cortos).

Gracias!

Answer 1

Sé que no quiere estar cambiando Historias, pero ¿qué pasa con las tareas dentro de una historia? ¿Qué ocurre si surge una nueva tarea o una tarea anterior ya no es válida? Pueden ser agregados y/o eliminados mediados de sprint (...).

Sí, pueden. Durante una iteración, un equipo típicamente reúne conocimiento y obtiene una mejor comprensión de lo que se debe hacer, o no. Como consecuencia, un equipo puede descubrir que una tarea no es realmente relevante, que un elemento de trabajo acumulado determinado requiere más trabajo del esperado, que una estimación inicial es incorrecta. En tales casos, definitivamente deseas actualizar tu Sprint Backlog y el Burndown Chart para mantenerte fiel a la realidad y mantener visible lo que debe hacerse: realmente quieres saber si la iteración sigue en curso, si puedes tomar un elemento más , etc.

Así que, sí, no dude en actualizar, quitar, agregar tareas tan pronto como descubra que tiene que ser hecho. Y cuanto antes, mejor.

En nuestro equipo, use una tabla de tareas inspirado por Scrum and XP from the Trenches de Henrik Kniberg y tenemos un lugar especial para los "elementos no planificados", como se ilustra a continuación:

nos gusta este enfoque, ya que hace fácil de detectar si los elementos no planificados están matando una iteración. Y también "revisamos" dichas tareas durante la retrospectiva para ver cómo podemos mejorar nuestra reunión de planificación, nuestras estimaciones, la forma en que dividimos los elementos, etc.

Answer 2

El equipo se comprometen en las historias de usuario, no tareas

No es un problema tener algunas tareas que cambian a medida que se enfrentan a problemas o tiene mejores ideas de implementación.

De hecho, es muy raro terminar un sprint con cada tarea 100% precisa "predicha" en la reunión de planificación de sprints.

Answer 3

Pueden y deben cambiar. El tablero debe actualizarse al menos diariamente.

Pero Pascal respondió a eso ya - Quiero hacer otro punto: desde la experiencia 'tratando de adoptar' Agile a través de pequeños cambios no funcionará.Scrum es un marco completo, con esto quiero decir que hay muy poco en Scrum (no diría nada) que se puede descartar sin dañar el proceso y promover la disfunción o al menos permitir que la disfunción continúe (wrote about it). Ir despacio puede ser el único camino a seguir en algunas empresas/circunstancias, pero tiene el riesgo de que las disfunciones persistentes soplen el proceso de cambio/mejora antes de que llegue a su fin y rinda beneficios.

Answer 4

Ya me gustan las respuestas de Pascal y Andy para no repetirlas.

Una alternativa útil es iniciar una Junta Kanban. Henrik Kniberg también tiene un buen 'libro' al respecto, disponible aquí: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html

Le permite organizar su trabajo y tener un poco de pensamiento ágil en la empresa. Como dijo Andy, Scrum es un All-in, si no, encontrarás que 'No funciona'.

Answer 5

¿Por qué no? Deje el espacio para formar un equipo para completar el trabajo de la manera que les gustaría hacer.

Las historias son 'contract' entre el cliente, el propietario del producto y el equipo, por lo tanto, es bueno no cambiar, agregar, eliminar historias sin avisarles. Pero las tareas son solo para el equipo.

El equipo debería ser capaz de rastrear el esfuerzo de la manera que lo necesitan para hacerlo visible.

Cuestionable es un cambio de horas que el equipo se comprometió a completar en el sprint, pero un buen maestro de scrum y un equipo experimentado es capaz de autoorganizar eso.