Agile: La importancia del WIP (Work in progress).

Todas las personas tenemos una capacidad de atención limitada sobre todo cuando atendemos mas de una  tarea al mismo tiempo. El limite de atención que puedes tener en varias cosas a la vez no es un asunto de inteligencia o fortaleza, es solo naturaleza humana, tu capacidad de atención es limitada y finita, es un recurso que se agota así como la gasolina en un coche. Partiendo de esta idea, solo tienes un numero limitado de tareas que puedes atender eficientemente, conforme sube la cantidad de pendientes paralelos tu productividad se ira al suelo.

Prácticamente todos los marcos de trabajo ágiles limitan el numero cosas que debes atender a la vez, por lo general es solo un item o dos  el máximo que puedes tomar, a esta tarea a la que le dedicas toda tu atención se le conoce como trabajo en progreso (WIP).

Tener mas tareas “en proceso” no te hace mas productivo.

En flujos de trabajo donde todos en la empresa pueden ver lo que se hace en el área de desarrollo puede surgir inseguridad en alguien cuando se tiene un backlog grande y pocos items asignados a los desarrolladores. Para alguien que no conozca como funcionan las metodologías ágiles,  ver pocos items tomados puede interpretarse como ineptitud o pereza. Un externo podría pensar lo siguiente: ¿porque tomas solo una actividad? cuando puedes sacar 3 o 4 sin problemas, siempre veo al equipo muy relajado. Siguiendo la lógica de este externo, si tu tomaras mas de un item para ponerlo en tu carril, digamos que pones 6 items en tu carril de “en proceso”, ¿vas a trabajar en los 6 items inmediatamente y al mismo tiempo en paralelo?, la respuesta es no, ¿que va a suceder con los items que no trabajes?, la respuesta es nada, si tienes 5 items detenidos en tu carril y que tampoco pueden ser tomados por los demás, ¿que  item estas atendiendo en este momento de los 6?, la respuesta es no se sabe.

No hay valor en engordar tu WIP mas que el de un placebo para el equipo de desarrollo y los involucrados del proyecto.

Tener mas tareas “en proceso” dificulta la toma de decisiones.

El tablero del equipo de desarrollo debe poder responder la pregunta: ¿que están haciendo todos hoy?. Si hay pocos items en el carril de cada desarrollador es fácil asumir en que están y por lo tanto priorizar actividades, hacer swarming o reemplazar actividades. En un escenario donde todos los miembros de tu equipo tengan asignados 6 o 7 items, no vas a tener idea que esta haciendo cada uno mas que preguntando. Tampoco vas a poder medir el progreso. ¿como mides el progreso de 6 actividades en una jornada de 8 horas?.

Supongamos que necesitas corregir un bug inmediatamente debes de asignar a un desarrollador para que tome la actividad inmediatamente, luego ves el tablero retacado de items, ¿cual programador es el mas conveniente para asignarle la actividad?, el proceso te puede tomar una hora o dos en lo que vas preguntando el estado de tanta actividad. Sin haber iniciado la actividad ya estas generando desperdicio.

Tener mas tareas “en proceso” incrementa el desperdicio por Task Switching o la generación de trabajo no completado.

Cambiar de actividades constantemente a lo largo del día es un desperdicio, el tiempo que se toma en prepararse mentalmente para después  tomar otra actividad es considerable. Puede ser una hora o dos diarias. Cada vez que retomas una tarea debes olvidarte de todo el contexto que traías de la actividad anterior, luego tratar de recordar o ponerte al corriente de en que estabas cuando dejaste la nueva tarea. Todo esto va a desgastar tu atención durante el día e ira restando valiosas horas de desarrollo.

Si cambias de tarea constantemente dejas código destripado y sin terminar,mismo que no puede ser tomado por otros por estar a la mitad. Este código se vuelve un estorbo, no es productivo y no se puede desplegar. Puedes almacenar el código locamente sin hacer merge con el repositorio pero corres el riesgo de tener muchos conflictos si dejas pasar demasiado tiempo. Si decides  hacer commit y solo comentar algunas cosas por aquí y por allá puedes estar metiendo bugs o re trabajo. En mi experiencia personal, los programadores multitask no suelen tener mucho cuidado a la hora de empujar cambios sin terminar. Con muchos pendientes abiertos reduces la preocupación sobre que se envía al repositorio.

Conclusiones.

Tu capacidad de atención en el día es un recurso limitado, conservarla bien. No sacrifiques hacer un buen trabajo por entregar mas items. A la larga lo único que conseguirás es reducir tu calidad y desgastarte personalmente.

Autor imagen: ER0L

 

Gustavo Sánchez