Todas las personas tenemos una capacidad de atención limitada, sobre todo cuando atendemos más de una tarea al mismo tiempo. El límite 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, solamente tienes un número limitado de tareas que puedes atender eficientemente, conforme sube la cantidad de pendientes paralelos tu productividad sé ira al suelo.
Prácticamente, todos los marcos de trabajo ágiles limitan el número cosas que debes atender a la vez, por lo general es nada más 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 más tareas «en proceso» no te hace más 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: ¿por qué 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 más 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, ¿qué 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, ¿qué item estás atendiendo en este momento de los 6?, la respuesta es, no se sabe.
No hay valor en engordar tu WIP más que el de un placebo para el equipo de desarrollo y los involucrados del proyecto.
Tener más tareas «en proceso» dificulta la toma de decisiones.
El tablero del equipo de desarrollo debe poder responder la pregunta: ¿qué 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 está haciendo cada uno más que preguntando. Tampoco vas a poder medir el progreso. ¿Cómo 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, ¿cuál programador es el más 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 estás generando desperdicio.
Tener más 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 más items. A la larga lo único que conseguirás es reducir tu calidad y desgastarte personalmente.
Autor imagen: ER0L
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
2 comments On Agile: La importancia del WIP (Work in progress).
Pingback: Kanban: Mi primer reunión de retrospectiva. – Happy Devops ()
Pingback: Kanban smells: Carriles sin limite de trabajo (WIP). – Happy Devops ()
Comments are closed.