¿Qué son los límites de trabajo en curso?
En el desarrollo ágil, los límites de trabajo en curso (WIP, del inglés "work in progress") establecen la cantidad máxima de trabajo que puede existir en cada estado de un flujo de trabajo. Limitar la cantidad de trabajo en curso facilita la identificación de la ineficacia en el flujo de trabajo de un equipo. Los cuellos de botella en un canal de entrega del equipo son claramente visibles antes de que la situación se agrave.
¿Por qué los límites del trabajo en curso son importantes?
Seguramente estés pensando "¡Cuéntame más!". (Al menos, eso espero).
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 (WIP, por sus siglas en inglés) fomentan la cultura de finalizar tareas. Pero lo que es más importante todavía es que los límites del trabajo en curso 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.
Los equipos que se estén iniciando en los límites del trabajo en curso se sentirán raros. Dedica tiempo a hablar sobre ello en las primeras iteraciones. Comprende cuándo y por qué el equipo alcanza los límites del trabajo en curso. No caigas en la tentación de ajustarlos arbitrariamente al principio. Si hay un desajuste persistente, será un indicador de que los límites del trabajo en curso son demasiado restrictivos o de que el proceso del equipo es ineficiente.
Usar límites del trabajo en curso en equipos ágiles
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.
- Los límites del trabajo en curso se aumentan según sea necesario para que el equipo deje de estrellarse contra ellos. (¿Te suena "techo de deuda"?).
- Todos tienen una "tarea secundaria" grande a su cargo para enmascarar tiempos cuando de otro modo estarían inactivos.
- Los miembros del equipo se quedan sentados esperando les llegue más trabajo en vez de lanzarse cual enjambre a los cuellos de botella.
- Es preferible asignar más horas de trabajo personal a los cuellos de botella persistentes que a mejorar las prácticas de ingeniería o procesos del equipo.
Cuatro objetivos para los equipos ágiles que usen límites del trabajo en curso
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 como un gran elemento de trabajo obstruyendo la canalización.
Cuando los límites del trabajo en curso funcionan bien para el equipo, se reduce la duración del ciclo de una incidencia. La duración del ciclo es la cantidad de tiempo que tarda una incidencia en completarse. Consulta nuestra página acerca de las métricas ágiles para obtener más informació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.
