Saltar al contenido principal

Columnas Tablero Kanban

Este documento tiene como objetivo describir el propósito y uso de cada columna en nuestro tablero Kanban, para que todo el equipo entienda el flujo de trabajo y pueda utilizarlo de forma consistente durante el sprint. La estructura del tablero es la siguiente:

  1. To Do
  2. In Progress
  3. On Hold
  4. Ready for QA
  5. In QA
  6. Ready for Deployment
  7. Done

1. Not Started​

Propósito: Esta columna reúne todas las historias de usuario y tareas que aún no han sido iniciadas. Se considera el punto de partida de nuestro flujo de trabajo. Uso:

  • Aquí se colocan todas las tareas nuevas o aquellas que han sido refinadas y priorizadas pero aún no han comenzado.
  • Es importante que cada tarjeta en esta columna cuente con la información básica (descripción, criterios de aceptación, asignado, etc.) para que, en el momento de comenzar, el equipo tenga el contexto necesario.
  • Durante la planificación del sprint, se seleccionarán tareas desde esta columna para moverlas a la fase de desarrollo.

2. In Development​

Propósito: En esta columna se agrupan las tareas en las que se está trabajando activamente. Uso:

  • Una vez que un desarrollador comienza a trabajar en una tarea, se mueve de Not Started a In Development.
  • Aquí se llevan a cabo actividades de codificación, diseño, y cualquier otra acción técnica necesaria para completar la funcionalidad.
  • Se recomienda actualizar la tarjeta con notas o comentarios sobre el progreso para mantener la transparencia.

3. On Hold​

Propósito: Esta columna está diseñada para aquellas historias o tareas que, por motivos externos o dependencias, han tenido que ser puestas en pausa durante el sprint. Uso:

  • Se utiliza cuando se identifica un impedimento o una dependencia que impide continuar con el desarrollo de la historia.
  • La tarjeta se mueve a On Hold para indicar que necesita atención o resolución externa.
  • Es importante que se documente la razón de la pausa y, en la medida de lo posible, se establezca un plazo o una acción para resolver el impedimento.
  • Una vez resuelto, la tarjeta podrá volver a In Development.

4. Ready for Testing​

Propósito: Esta columna señala que la tarea ha sido completada en la fase de desarrollo y está lista para ser evaluada por el equipo de pruebas. Uso:

  • Cuando el desarrollo de una tarea finaliza y se han realizado las revisiones internas necesarias, la tarjeta se mueve a Ready for Testing.
  • En esta etapa se verifica que la historia cumpla con los criterios de aceptación definidos.
  • Se recomienda que el desarrollador incluya comentarios relevantes o documente cualquier detalle importante para facilitar la labor del equipo de QA.

5. In Testing​

Propósito: Aquí se encuentran las tareas que están siendo evaluadas o probadas. Uso:

  • El equipo de QA toma las tareas de la columna Ready for Testing y comienza a realizar pruebas (manuales, automatizadas, de integración, etc.).
  • Durante esta fase se documentan hallazgos, errores o cualquier retroalimentación relevante.
  • En caso de detectar algún fallo, se pueden agregar comentarios en la tarjeta o incluso moverla de nuevo a In Development para realizar las correcciones pertinentes.
  • Una vez aprobada, la tarjeta se moverá a la siguiente columna que es Ready for deployment.

6. Ready for Deployment​

Propósito: Esta columna agrupa aquellas tareas que han pasado las pruebas y están listas para ser desplegadas en producción. Uso:

  • Una vez que la tarea ha sido probada exitosamente en la fase de In Testing, se mueve a Ready for Deployment.
  • En este punto, se realiza una última verificación (por ejemplo, validación final o revisión de requisitos de despliegue) antes de liberar el cambio.
  • Se debe confirmar que no existen bloqueos pendientes y que la tarea cumple con todas las condiciones para su despliegue.

7. Done​

Propósito: La columna Done representa la finalización total de la tarea, una vez que ha sido desplegada y validada en producción. Uso:

  • Cuando la tarea ha sido desplegada y se ha verificado que funciona correctamente en producción, se mueve a Done.
  • Esta columna sirve como registro de trabajo completado y permite evaluar la capacidad del equipo y los tiempos de ciclo.
  • Es recomendable hacer revisiones periódicas para analizar el rendimiento del equipo a partir de las tareas completadas.

Buenas Prácticas Adicionales​

  • Límites de WIP (Work In Progress):
  • Para evitar la sobrecarga en cualquier fase del proceso, se recomienda establecer un límite de tareas activas en cada columna. Esto ayudará a mantener un flujo de trabajo constante y a identificar cuellos de botella de forma temprana.
  • Actualización Constante:
  • Es fundamental que todos los miembros del equipo actualicen el estado de sus tareas y añadan comentarios o notas sobre el progreso. La transparencia en el tablero mejora la colaboración y la toma de decisiones.
  • Revisión y Retroalimentación:
  • Al final de cada sprint, se recomienda realizar una revisión del tablero para identificar áreas de mejora en el flujo de trabajo y ajustar las políticas o límites WIP según sea necesario.

Este documento sirve como guía para todo el equipo y debe revisarse periódicamente para asegurarnos de que el flujo de trabajo se adapte a las necesidades del proyecto y se sigan las mejores prácticas de gestión ágil.