En el uso diario del panel, deben observarse algunas reglas de necesario cumplimiento, como son:

Una tarea para una sola persona

Una tarea solo se asigna a una persona. Si una tarea parece "asignable" a más de una persona, debería dividirse en dos subtareas, una para cada persona.

Hay alguna metodología muy específica, por ejemplo XP (eXtreme Programming) para desarrollo de software, que promueve el "pair programming", es decir, que una tarea se ejecute por dos personas. Pero no es lo más genérico en proyectos ágiles

Las tareas solo se mueven hacia la derecha

Una tarea solo puede desplazarse hacia la derecha del panel, nunca hacia la izquierda, porque desplazar a la derecha quiere decir que la tarea "avanza" en su estado de realización, y desplazarla hacia la izquierda refleja "deshacer" trabajo.

Solo podemos hacer avanzar una tarea cuando su estado real es el que se refleja en su columna, no un estado "supuesto"; por tanto, si una tarea retrocede, es que no se dijo de forma realista cuál era su estado, y esto no se puede concebir (salvo error) como práctica aceptable.

Deshacer trabajo significa desperdicio, falta de eficiencia.

Pocas tareas en cada columna

En una columna, en un momento determinado, no debería haber más tareas que personas del equipo de trabajo; si hubiera demasiadas tareas en una columna quiere decir que esa etapa del trabajo tiene problemas, las tareas llegan a ella y se detienen, es un cuello de botella y es signo de un problema.

La excepción son las columnas de "pendiente de comenzar" y "finalizadas", o sus equivalentes.

Pocas tareas simultáneas por persona

A menudo, se diseñan reglas específicas en cada proyecto del tipo "una persona no puede tener más de 3 o 4 tareas asignadas". Esto intenta evitar la dispersión en la concentración de las personas, es decir, ir punteando tareas pero sin finalizar ninguna.

Es deseable centrarse en una tarea lo máximo posible e intentar cerrarla antes de comenzar otra.

Sin cambios dentro de un timebox

Una vez comenzada una iteración, no se deben introducir cambios en la misma. Esto desordena y puede hacer inviable el panel de tareas en curso.

Por ejemplo, si hay que incluir una nueva historia de usuario. Si incluimos o excluimos una historia de usuario, quiere decir que la planificación de la iteración no sirve, y esto supone haber incurrido en desperdicio (se ha hecho un trabajo, que ahora no sirve).

Por eso, es una muy buena práctica que las iteraciones sean cortas: 
  • Que sean cortas implica que la cantidad de información que hace falta es pequeña, solo la referente a unas pocas historias de usuario, por tanto, es más fácil dirigir y cerrar las dudas e incertidumbres.
  • Cuanto más cortas, más rápidamente se hace su planificación, porque caben menos historias de usuario y por tanto hay que detallar menos tareas.
  • En caso de que Negocio diga que es necesario un cambio, y haya que anular o parar la iteración, se desperdiciará menos trabajo cuanto más corta sea.
 

Esta píldora formativa está extraída del Curso online de Metodologías ágiles de gestión de proyectos.

¿Te gusta el contenido de esta píldora de conocimiento?

No pierdas tu oportunidad y ¡continúa aprendiendo!

Política de privacidad

ADR Formación utiliza cookies propias y de terceros para fines analíticos anónimos, guardar las preferencias que selecciones y para el funcionamiento general de la página.

Puedes aceptar todas las cookies pulsando el botón "Aceptar" o configurarlas o rechazar su uso pulsando el botón "Configurar".

Puedes obtener más información y volver a configurar tus preferencias en cualquier momento en la Política de cookies