Devolverle el "flow" al "workflow" con los límites del trabajo en curso

En el desarrollo ágil, los límites de trabajo en progreso (WIP) establecen la cantidad máxima de trabajo que puede existir en cada estado de un flujo de trabajo. Limitar la cantidad de trabajo en progreso facilita la identificación de la ineficiencia en el flujo de trabajo de un equipo.

Los cuellos de botella en la canalización de entrega de un equipo son claramente visibles antes de que la situación se agrave. Al centrarse en completar las tareas antes de empezar otras nuevas, los equipos (de todos los tipos) aumentan la eficiencia, reducen el cambio de contexto y ofrecen resultados significativamente mejores.

Ahora estarás pensando: "¡Cuéntame más!".

Los límites del trabajo en curso mejoran el rendimiento y reducen la cantidad de trabajo "prácticamente listo", ya que obliga al equipo a centrarse en un conjunto de tareas más pequeño. En el fondo, los límites del trabajo en curso fomentan la cultura de finalizar tareas.

Pero lo que es más importante todavía es que también exponen los cuellos de botella y los impedimentos. Los equipos pueden reunirse y tratar los impedimentos para comprenderlos, implementarlos y resolverlos cuando haya un indicador claro de qué tarea está causando el cuello de botella. Una vez eliminados los impedimentos, el trabajo de todo el equipo volverá a fluir.

Estas ventajas aceleran los incrementos del valor al cliente, lo que convierte los límites del trabajo en curso en una herramienta valiosa en el desarrollo ágil.

Durante el desarrollo, es fácil pensar “dejaré de trabajar en este asunto mientras empiezo otro”. Tener dos tareas abiertas significa cambiar de contexto entre dos asuntos diferentes o transferir trabajo entre compañeros. Dejar de trabajar en una incidencia para empezar otra no sale gratis: se pierde tiempo y disminuye la concentración.

Suele ser mejor trabajar hasta terminar la incidencia inicial en lugar de empezar, y no finalizar, trabajo nuevo. En otras palabras, los límites del trabajo en curso nos incitan a no perder nuestro ritmo de trabajo. 

Por último, estos límites señalan áreas de inactividad o sobrecarga crónica. Ayudan al equipo a ver las ineficiencias de todo el proceso en lugar de únicamente las del área concreta en la que trabajen.

Ahora que estás convencido de su valor, pongamos manos a la obra.

Al implementar un nuevo flujo de trabajo, tomad una decisión en equipo para determinar los límites del trabajo en curso de cada estado. Recomendamos establecer los límites del trabajo en curso después de estudiar el número medio de elementos de trabajo en cada estado durante unos sprints. A continuación, encontrarás un tablero ágil de ejemplo con límites del trabajo en curso utilizados por un equipo de desarrollo de software típico.

Más arriba, se ha establecido un límite del trabajo en curso en el estado "revisión del código". Dado que la columna supera su límite, el fondo se ha vuelto de color rojo.

Dado que no hay nada que hacer una vez que una incidencia alcanza el estado Finalizado, no hace falta establecer un límite de trabajo en curso. En el tablero de kanban anterior, "Por hacer" significa que el propietario del producto y el equipo han examinado la historia a fondo. El equipo de desarrollo saca trabajo de "Por hacer" y lo pasa a "En curso" a medida que empiezan los elementos de trabajo. Como práctica recomendada, es importante mantener trabajo suficiente en el estado "Por hacer" para aprovechar al máximo las capacidades de todos los miembros del equipo de desarrollo. Si se mantienen las historias justas en el estado "Por hacer", el propietario del producto no avanzará en exceso en la especificación de requisitos, y el programa responderá mejor a los cambios.

El estado "en curso" muestra el trabajo que se está desarrollando activamente. El objetivo de los límites del trabajo en curso en este caso es asegurarse de que todos tengan trabajo sin caer en las multitareas. En el tablero anterior, el límite entre los elementos "en curso" es 4 y hay 3 elementos en ese estado. Esto informa al equipo de que tienen capacidad para asumir más trabajo. Como buena práctica, algunos equipos establecen el límite máximo de trabajo en curso por debajo del número de miembros del equipo. La idea es dejar hueco para las buenas prácticas ágiles. Si un desarrollador termina un evento, pero el equipo ya ha alcanzado el límite de trabajo en curso, sabrá que es hora de realizar revisiones del código o de unirse a otro desarrollador para una programación conjunta.

El estado "revisión del código" indica las historias que ya se han escrito completamente, pero que necesitan revisarse antes de hacer el merge en la base de código. Las revisiones del código oportunas son una buena práctica que fomenta la calidad, acelera la introducción de innovación en el mercado, simplifica el merge gracias a una reducción de las ramas abiertas y extienden el conocimiento en el equipo de ingeniería. Debe actuarse en los elementos con este estado urgentemente por varias razones:

• El código no se estanca a medida que los miembros del equipo incorporan nuevo código

• El desarrollador no pierde el contexto obtenido al escribir el código original

• Puede hacerse el merge de la funcionalidad en la rama principal para publicarse

Los límites del trabajo en curso impiden que el código sin revisar se acumule. 

Ten en cuenta que en el tablero anterior el equipo tiene demasiadas revisiones del código, de modo que la columna aparece en rojo para señalarlo.

Como en cualquier nueva actividad, los límites del trabajo en curso pueden parecer extraños al principio. El objetivo aquí es optimizar el equipo a medio plazo. Sentirse extraño a corto plazo en realidad es algo positivo porque obliga al equipo a comprobar los puntos de dificultad del proceso. Después de que el equipo use los límites del trabajo en curso durante unas semanas, realiza los ajustes necesarios. No caigas en la tentación de aumentar el límite de trabajo en curso simplemente porque el equipo lo alcance a menudo. Aprovecha la oportunidad para aumentar la capacidad, idealmente formando al equipo y aumentando las habilidades de cada miembro, o mejorando la eficiencia de algún proceso de desarrollo.

Primer objetivo: dividir las tareas individuales de forma sistemática. Al dividir los requisitos y las historias de usuario, es importante que las tareas individuales no superen las 16 horas de trabajo. De este modo, se aumenta la capacidad del equipo para realizar estimaciones con seguridad y se ayuda a prevenir los cuellos de botella. No hay nada que ralentice más a un equipo y que agrave los límites del trabajo en curso que un gran elemento de trabajo obstruyendo la canalización.

Segundo objetivo: Asocia los límites del trabajo en curso a las habilidades del equipo. El ejemplo anterior supone que los miembros del equipo tienen habilidades similares. Si tu equipo cuenta con especialistas, los límites del trabajo en curso pueden variar si hay un especialista implicado. Crea un estado específico para el trabajo del especialista. Si suceden cuellos de botella en ese estado, aprovecha la oportunidad para formar a otros miembros del equipo de modo que puedan añadir más capacidad a las habilidades del especialista y aumentar el flujo de todo el equipo.

Tercer objetivo: Reduce la inactividad. Cuando algún miembro del equipo esté inactivo, anímale para que ayude a miembros del equipo que se encuentren en fases anteriores o posteriores. Contribuirán a la productividad general del equipo y aprenderán algo por el camino.

Cuarto objetivo: defender la cultura de ingeniería sostenible. Los límites del trabajo en curso no significan que los desarrolladores deban realizar el trabajo rápidamente para evitar la carga de trabajo en un estado particular. Están diseñados para fomentar buenas prácticas de ingeniería ágil que protejan la calidad del producto y el estado de la base de código. 

Si tu equipo está preparado para implementar los límites de trabajo en curso, utiliza nuestra plantilla de tablero de kanban para empezar gratis.