Anatomía de un Tablero Kanban

Un tablero Kanban a menudo se trata como una simple cuadrícula: columnas para etapas, tarjetas para elementos de trabajo. Pero los tableros efectivos tienen más estructura que eso.

Los componentes clave:

1. Columnas — Etapas por las que pasa el trabajo
2. Tarjetas — Elementos de trabajo individuales
3. Límites WIP — Máximo de elementos permitidos por etapa
4. Swimlanes — Divisiones horizontales para categorizar el trabajo
5. Políticas — Reglas sobre cómo se mueve el trabajo (a menudo escritas en el tablero)
6. Bloqueos — Indicadores visuales para trabajo atascado
7. Colas vs. etapas activas — Distinguir espera de trabajo

Exploremos cada uno de estos en profundidad.

La primera regla: las columnas deben reflejar cómo se mueve realmente el trabajo, no cómo desearías que se moviera.

Errores comunes:

• Usar etapas genéricas (Por Hacer, Haciendo, Hecho) que ocultan complejidad
• Mapear un proceso idealizado que nadie sigue
• Copiar el tablero de otro equipo sin entender tu contexto

El enfoque correcto:

1. Reúne al equipo (todos los que tocan el trabajo)
2. Revisa elementos de trabajo recientes: "¿Qué pasó con esto después de que se creó?"
3. Anota cada etapa, incluyendo estados de espera
4. Incluye la verdad dolorosa—si el trabajo se queda en revisión por días, esa es una etapa

Ejemplo de evolución:

• Antes: Por Hacer → En Progreso → Hecho
• Después: Backlog → Listo → Desarrollo (WIP: 3) → Revisión de Código (WIP: 2) → QA → Listo para Desplegar → Desplegado

El tablero expandido revela dónde el trabajo realmente pasa tiempo. Podrías descubrir que la revisión de código toma más tiempo que el desarrollo.

No todas las etapas son iguales. Algunas representan trabajo activo (alguien está haciendo algo). Otras representan colas (el trabajo está esperando).

Esta distinción importa porque:

• El tiempo de espera a menudo domina el tiempo de entrega
• Las colas son donde el trabajo muere
• Gestionas las colas y las etapas activas de manera diferente

Visualizar la diferencia:

Muchos equipos dividen las columnas en dos: un área de "espera" y un área de "haciendo".

| Ready | Development  | Ready for | Code Review | Ready for | Done |
|       | In Progress  | Review    | In Progress | Deploy    |      |

O usan puntos/indicadores en las tarjetas para mostrar "trabajando activamente" vs. "esperando".

La perspectiva: Si tu columna "En Progreso" está llena de trabajo que nadie está tocando realmente, tienes colas ocultas. Hazlas visibles.

Cada columna necesita una Definición de Hecho (DoD) clara: ¿qué debe ser verdad para que el trabajo salga de esta etapa?

Sin criterios claros:

• El trabajo se mueve prematuramente ("está casi hecho")
• La calidad varía ("hecho" significa cosas diferentes para diferentes personas)
• Los problemas surgen tarde ("pensé que alguien más haría eso")

Ejemplo de DoD para "Desarrollo":

• Todos los criterios de aceptación cumplidos
• Pruebas unitarias escritas y pasando
• El código compila sin advertencias
• Auto-revisado (sin problemas obvios)
• El mensaje de commit sigue la convención

Ejemplo de DoD para "Revisión de Código":

• Dos aprobaciones recibidas
• Todos los comentarios de revisión atendidos
• El pipeline de CI pasa
• Sin conflictos de fusión

Escribe estos en el tablero o enlázalos. No son burocracia—son entendimiento compartido.