0
Kanban es una herramienta que se usa SOBRE un flujo de trabajo pre-existente. Para partir es tremendamente recomendado partir de los estados màs simples:
- Queue: En Cola
- Work in Progress (WIP): Trabajo en Curso.
- Done: Listo
A partir de ese momento suceden dos cosas:
- al ir usando el kanban, hay momentos en que no sabes donde poner un papel. Esto es señal de que falta un estado (columna) en el tablero
- y aqui lo menos intuitivo pero lo màs relevante. Si definen un lìmite de cantidad de kanbans en cada uno de los estados(columnas) del tablero, de tal forma que cada vez que superes la cantidad signifique una señal de alerta de que hay que mejorar el trabajo en equipo… tu proceso comenzarà a agilizarse de manera evolutiva y natural (esta es la hipòtesis fundamental de Kanban, que no sucederà sino limitas el trabajo en curso)
Nunca me han tocado dos tableros iguales en sus estados, dedpendiendo la cponfiguraciòn de cada equipo y de las responabildades de este.
En general, estructura del tablero Kanban (o de las columnas del tablero Kanban) deben representar verazmente el proceso existente. Por lo tanto, si después del desarrollo y el QA interno, la tarea es enviada al QA del cliente, vamos a tener la columna “QA del cliente”. Si tal paso no existe, no vamos a tener la dicha columna. Si logramos tener mejor representación, mejor uso vamos a tener del Kanban, facilitando entonces la visualización de los cuellos de botella, mejores métricas, etc.
En Lean, la técnica utilizada para entender este flujo interno se llama “Value Stream Mapping”. Me parece mejor camino partir con l implantación de Kanban realizando el mapeo de flujo de valor previamente y estructurando el tablero Kanban en acorde con esto, que partiendo con un Kanban genérico. Una vez tu Kanban es una buena representación deL proceso existente, te ayudara entender y visualizar puntos carentes y sub-óptimos. La reacción a algunos problemas, como cuellos de botella, puede ser ad-hoc, reorganizando el equipo por el momento (algunos desarrolladores ayudando a QA), o sistemática, cambiando el proceso implantado y entonces modificando el tablero Kanban para que represente verazmente nuevo flujo del valor.
Tal como mencionado en las respuestas anteriores no hay un mejor set de estados en lo absoluto, sino que esas columnas se van a descubrir progresivamente. Eso sí te puedo dar algunos estados que me han sido útiles en varios Kanbans:
1) Esperando: cuando algo ya no depende de tí pero lo tienes que tener en mente para poder preguntar de vez en cuando en que esta la tarea.
2) Por planificar: cuando hay algo que tiene que hacer, pero que primero necesitas descomponer en tareas más chicas.
3) Validar: alguien tiene que decirte si esta bien o no.
Nosotros usamos los siguientes estados:
- Backlog, donde dejamos las tareas que no pertenecen al release actual.
- Todo, donde estan las tareas a hacer en el release actual.
- Doing, las tareas que se estan haciendo en el momento.
- validate, las tareas que se estan validando, aqui tenemos dos tipos de tareas, aquellas que debe validarnos un compañero, y aquellas que estan para que valide el cliente, las diferenciamos con un chinche (con cabeza o planos).
- Done, las tareas que se validaron por el cliente.
Ya de ahí, diferenciamos las tareas por colores de los chiches, y por un pequeño “genero” de color, esto para la prioridad de la tarea y el tipo de tarea
All Shapado.com content and data are available under the
El kanban más sencillo está compuesto de las columas: todo, doing, done. Pero prontamente se hacen necesarias otras columnas cuando es aplicado a la vida real.
¿Cuáles han encontrado que son las columnas más “estándar” a travez de los kanban que han realizado, para que sean una guia de cómo comenzar, pero sin que sean demasiado complejas para que una persona ajena a la herramienta no lo entienda?