¿Cómo especificar los límites de WIP en Kanban?

Considere una tabla Kanban típica:

Entrada, Análisis, Dev Ready, Desarrollo, Build Ready, Test, Release Ready

¿Cómo especificar los límites de WIP para cada columna? alguna formula?

No, no hay fórmula. No hay uno

Mucho depende de la forma en que trabaja su equipo, las prácticas que usa, etc. Si empareja el programa, tendrá límites más bajos en la columna de desarrollo que varios desarrolladores.

Si presenta Kanban en el equipo existente, puede intentar asignar todo el trabajo que está actualmente en progreso a los MMF y luego ver cuántas funciones tiene en diferentes columnas. Le daría una idea de los límites que realmente tiene en este momento y este es un buen punto de partida para establecer los límites de Kanban.

Otro consejo que recibe es ir con su instinto / el de su equipo. Haz lo que sientes que es correcto. Luego, controle si sus límites no son demasiado ajustados o demasiado flojos y ajústelos. Algunas personas dicen "el tablero te lo dirá" y eso es básicamente cierto. Si llega al cuello de botella todas las semanas, probablemente tenga límites demasiado bajos. Si uno o dos bloqueadores no son un problema, los límites son demasiado altos.

Escribí una publicación sobre cómo establecimos nuestros límites cuando estábamos creando nuestro tablero Kanban: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html

He probado dos extremos, ambos sugeridos por diferentes personas. Una es usar límites altos y ajustarlos hasta que duela, y la otra es lo contrario, para comenzar con n-1, donde n es el número de personas que podrían llevar una tarea a esa columna. Esto último es más doloroso para los equipos nuevos en Kanban, pero nos ayudó a llegar a un punto de maximización del flujo más rápido que la primera opción porque cuando sentimos dolor (cuellos de botella) nuestro primer instinto fue examinar el problema de aumentar el límite de WIP como un último recurso y, como resultado, descubrimos y resolvimos varios problemas de proceso que de otro modo podrían haber sido invisibles.

Si bien estoy de acuerdo con que no existe una fórmula como tal, al mismo tiempo existe la posibilidad real de modelar su proceso Kanban. Esto lo ayudará a simular resultados probables para cosas como tiempo de ciclo, tiempo de espera, eficiencia, etc.

He implementado un simulador que modela nuestro proceso Kanban. Simula el flujo de historias en todos los ámbitos bajo nuestras restricciones Kanban en torno a los límites de WIP y los recursos del equipo. Tenemos un estado que requiere revisión externa del cliente. Todos sospechábamos que esta etapa era algo que estaba matando nuestro tiempo de ciclo al respaldar nuestras historias.

La sensación inicial era cronometrar esta etapa, pero no sabíamos si esto simplemente empujaría el problema a otra parte. Tampoco sabíamos hasta dónde llegar con el tiempo de boxeo ni qué tan grande sería una mejora.

Todo está muy bien diciendo que solo sigas ajustando, pero puede ser muy perjudicial. La gente se acostumbrará a un proceso y se frustrará con alguien que constantemente está tratando de modificar una corazonada. Por lo tanto, a menudo tiene que presentar un caso muy bueno antes de implementar el cambio.

Cuando modela, puede ajustar sin interrupciones y tener una confianza mucho mayor de que sus ajustes le brindarán el resultado que desea. Además, te ayudará a conseguir tu fórmula mágica.

Comenzaría con un número de "espacios" en cada columna que es igual al número de personas que recogerían trabajo en la columna asociada. Eso revelará cuellos de botella o puntos de dolor. Aborde el punto de dolor hasta que desaparezca.

Con el tiempo, experimente con la reducción del número de ranuras en cada columna.

Utilizo dos técnicas para especificar el límite de WIP cuando comenzamos un nuevo proyecto o un equipo.

En el caso de un proyecto de desarrollo: estamos trabajando en parejas (estamos haciendo XP), lo que significa que dos miembros pueden trabajar en un elemento a la vez. Si el equipo constara de 6 personas, el WIP sería 3, según la oración anterior. Sin embargo, la programación de pares es un trabajo agotador, y a veces a los colegas les gustaría trabajar un poco solos, doy un plus, por lo que el límite de WIP para 6 miembros sería 4.

Cuando hablamos de un proyecto de mantenimiento, prueba de verificación o soporte, compruebo cuánto trabajo paralelo pueden hacer los diferentes colegas, sumo este número y lo resto con uno. Por ejemplo, todos los miembros del equipo mencionado anteriormente pueden ocuparse de 2 problemas paralelos, el límite de WIP sería 12, pero con el -1, es 11. El -1 me asegura que el equipo se mantenga enfocado y trabaje en conjunto. Si en este caso el límite de WIP fuera 12, todos trabajarían con sus dos tarjetas máximas, y no se produciría ninguna colaboración.

Quiero empatizar que utilizo estas técnicas solo al principio cuando comienza el proyecto / equipo. Posteriormente, el ajuste del límite de WIP es el deber del equipo en función de sus sentimientos, carga, objetivo, etc.