Knowledge Ingeniería y Proyectos Ingeniería y Proyectos
Esta píldora formativa está extraída del Curso online de Metodologías Ágiles de Gestión de Proyectos

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

Una tarea para una sola persona
Una tarea sólo 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 sólo se mueven hacia la derecha
Una tarea sólo 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.
Sólo 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 ó 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, sólo 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.
Ver Actividad Características de un kanban
 

Esta píldora formativa está extraída del Curso online de Metodologías Ágiles de Gestión de Proyectos.

Amplía tus conocimientos con el Curso Online de Metodologías Ágiles de Gestión de Proyectos

Puedes continuar ahora la formación matriculándote en el curso, o si lo prefieres, consultar nuestro catálogo con cerca de 400 actividades formativas acreditadas.

Benefíciate del crédito para formación bonificando el curso.

Este sitio web utiliza cookies de terceros con la finalidad de analizar el uso que hace de nuestra web y personalizar el contenido de los anuncios. Si continúa navegando entendemos que acepta su uso. Más información