¿Qué significan las columnas (flujo de trabajo o miembros del equipo) en Kanban?

Digamos que tenemos un equipo formado por un desarrollador y un probador. Y tenemos un tablero Kanban que consiste en las columnas "Desarrollo (WIP = 1)", "Prueba (WIP = 1)", "Terminado".

Cuando el desarrollador ha implementado una tarea, la mueve a la columna "Prueba".

Todo está bien hasta ahora.

Pero el probador también puede escribir nuevas pruebas. ¿Debería poner esta tarea en la columna "Desarrollo"?

En caso afirmativo , el probador puede estar trabajando en dos tareas al mismo tiempo a pesar de WIP = 1 (una tarea en la columna "Desarrollo" y una tarea en la columna "Prueba").

Si no , entonces un tablero Kanban representa la división de un equipo en desarrolladores, evaluadores, etc., pero no el flujo de trabajo de un equipo .

Las columnas representan el estado , no las personas ni los recursos.

Respuestas (2)

Creo que es más fácil responder a su pregunta si separamos algunos de los temas.

En primer lugar, las columnas del tablero representan el flujo de trabajo de los elementos. Entonces, si los pasos para entregar un artículo son desarrollo y prueba, entonces un artículo en la columna de desarrollo está en desarrollo y un artículo en la columna de prueba se está probando actualmente. Desde el punto de vista del tablero kanban, qué miembro del equipo está haciendo el trabajo es completamente irrelevante.

A continuación, hablemos de WIP. Si el WIP para ambas columnas es 1, nunca puede haber más de una tarea en ninguna columna. Esto es bueno desde el punto de vista del flujo. Cualquier cuello de botella o impedimento se hará evidente de inmediato. Por otro lado, es muy inflexible. Una prueba de larga duración bloquearía inmediatamente el sistema. Sin embargo, hay otras formas de aplicar WIP. Por ejemplo, podría aplicar un WIP de 2 a todo el proceso, lo que le daría un poco más de flexibilidad.

Finalmente, menciona que cuando el desarrollador termine de desarrollar, pondrá la tarjeta en la columna de prueba. Esto es algo sutil, pero esto es incorrecto. La tarjeta se mueve cuando comienza el trabajo en el siguiente paso, no cuando finaliza el paso actual. Puede parecer semántica, pero da como resultado comportamientos de equipo muy diferentes.

Gracias, pero ¿por qué es irrelevante? Supongamos que ambos WIP son iguales a 2. Supongamos además que un desarrollador trabaja en una tarea y un probador desarrolla una nueva prueba y prueba dos tareas implementadas: el probador trabaja en tres tareas a la vez. No parece ser bueno. En cambio, parece más razonable limitar el número de tareas en las que trabaja una persona.
Perdón por la falta de claridad. No es irrelevante en la conversación general sobre el trabajo en equipo, pero Kanban no lo prohíbe específicamente. Uno de los principios básicos de Kanban es que tú gestionas el trabajo, no las personas. Entonces, en Kanban, los límites WIP en el trabajo no tienen nada que ver con las personas que hacen ese trabajo. Sin embargo, por supuesto, sigue siendo importante que el equipo tenga conversaciones saludables sobre el trabajo y se espera que si alguien está haciendo malabarismos con muchas tareas, otros miembros del equipo señalarán que ellos son el cuello de botella y pedirán ayuda.

Los límites WIP se aplican a las tareas y no a las personas.

Si considera que escribir nuevas pruebas es una actividad de desarrollo, contribuiría al WIP para el estado de desarrollo.

Si considera que escribir nuevas pruebas es una actividad de prueba, contribuiría al WIP para el estado de prueba.

No importa cuál sea el conjunto de habilidades del individuo (es decir, si es un 'desarrollador' o un 'probador').

El punto importante aquí es que depende del equipo definir qué actividades representan qué estados en el flujo de trabajo .

Pensé que Kanban nos obliga a terminar nuestras tareas actuales antes de tomar otras nuevas. Entonces suena extraño que los límites WIP se apliquen a las tareas y no a las personas.
Creo que puede estar combinando dos conceptos diferentes aquí. El primer concepto es que si alguien ha completado parcialmente una tarea, cambiar a otra tarea tendrá un costo. A esto lo llamamos cambio de contexto y tratamos de mantenerlo al mínimo. El segundo concepto son los límites WIP, que se aplican a las etapas de un flujo de trabajo. La idea con los límites WIP es evitar cuellos de botella, ya que esto tiende a reducir el rendimiento general del trabajo completado. Depende del equipo cómo y cuándo aplicar estos dos conceptos para maximizar el rendimiento.