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

Los límites del trabajo en curso no están pensados para limitar tu progreso. Más bien al contrario.

Dan Radigan Dan Radigan

¿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 de trabajo en curso mejoran el rendimiento y reducen la cantidad de trabajo "prácticamente listo" obligando al equipo a centrarse en un conjunto de tareas más pequeño. En un nivel superficial, los límites del trabajo en curso fomentan la cultura de finalizar tareas. 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 incidencias 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 original en lugar de empezar y no finalizar nuevo trabajo. 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.

Pro Tip:

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 workflow, toma una decisión de 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 revisar 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. 

Límites del trabajo en curso | Orientador ágil de Atlassian

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 cuando un tique alcanza el estado finalizado, aquí no hay necesidad de establecer un límite de trabajo en curso. En el tablero anterior, "Listo para desarrollo" significa que la historia la ha aprobado completamente el propietario del producto y el equipo. El equipo de desarrollo saca trabajo de "Listo para desarrollo" y lo pasa a "En curso" a medida que empiecen los elementos de trabajo. Como buena práctica, es importante mantener trabajo suficiente en el estado "Listo para desarrollo" para aprovechar al máximo las capacidades todos los miembros del equipo de desarrollo. Si se mantienen las historias justas en el estado "Listo para desarrollo", 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 ágil anterior el equipo tiene demasiadas revisiones del código, de modo que la columna aparece en rojo para señalarlo.

Antipatrones ante los que estar alerta:
  • 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"?).
  • Everyone has a large "background task" on their plate to mask times when they'd otherwise be idle.
  • Team members sit idle waiting for more work to pull in, rather than swarming on bottlenecks.
  • 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: Ordenar 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, aumenta la capacidad del equipo para realizar estimaciones con seguridad y ayuda a prevenir obstáculos. No hay nada que ralentice más a un equipo y agrave los límites del trabajo en curso como un gran elemento de trabajo atascando las tuberías. 

Pro Tip:

Cuando los límites del trabajo en curso trabajan a favor del equipo, se reduce la duración del ciclo de tiques. La duración del ciclo es la cantidad de tiempo que tarda un tique 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: Defiende la cultura de ingeniería sostenible. Los límites del trabajo en curso no significan que los desarrolladores deban realizar el trabajo rápidamente y 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 la salud de la base de código.