Muchos seguimientos de proyectos tienden a ser optimistas, demasiado optimistas. No se contempla ni el desperdicio, el retraso o el trabajo detenido. Actividades que se detienen o quedan en espera se agregan al carril de cada desarrollador engordando el trabajo en progreso artificialmente. Si hay muchos items en cada carril significa que todos están trabajando mucho. El tablero de actividades es importante, no para ver como se asigna el trabajo, sino para ver la situación actual del proyecto, sea buena o mala y así tomar decisiones. Un tablero que no refleja la realidad no sirve para nada. Cualquier decisión que se tome con una mentira solo producirá otra mentira.
Contar el trabajo detenido o en espera es valioso.
Que el trabajo se detenga no es un asunto de ineficiencia o mediocridad, pasara en cualquier proyecto. Algunas actividades quedarán en espera por las circunstancias mismas del flujo de trabajo. Por ejemplo: si surge un incidente mayor productivo, es natural, incluso obligado, que todo recurso en capacidad de ayudar a resolver el incidente este disponible para reducir el tiempo de caída. ¿Qué sucede con las actividades en proceso?, se recorren o posponen, y está bien. El trabajo que no está siendo atendido debe ser catalogado como trabajo bloqueado o detenido. Si en el tablero de actividades no hay un carril especializado en trabajo detenido o bloqueado, va a haber problemas.
Catalogar items bloqueados como «en proceso» es malvado.
Un item en algún proyecto que trabaje tenía la siguiente nota: Sigue en proceso, se pauso un poco para resolver un incidente. De la siguiente nota no se puede concluir nada, ¿qué significa se pauso un poco?, si toda la atención del desarrollador fue para resolver el incidente, ¿cuál fue el avance?. El item en cuestión estaba en las actividades en proceso del desarrollador. Si solo se ocupa un carril es complicado saber que se está haciendo justo ahora. Esto se presta a ambigüedades y malos entendidos.
Tener muchas actividades en proceso no te hace más productivo.
Puede causar inseguridad en algunos interesados del producto mover items de lugar o comunicar que algo no está avanzando. Un carril de un desarrollador con una sola actividad puede verse mal en algunas empresas. Ya que hacer solamente una cosa puede representar holgazanería en algunos casos. En realidad es lo contrario, decir que estás haciendo muchas cosas a la vez para poder tener una vía de escape cuando te pregunten: ¿en qué estás?, suena peor, no debes buscar verte ocupado virtualmente. Lo correcto es que los items de tu carril reflejen las actividades que estás haciendo ahora, o lo que te dispones a completar en el sprint. Engordar tu WIP (trabajo en progreso) del tablero del proyecto crea desconfianza y en lugar de ocultarte te señala. Genera un carril de trabajo bloqueado y asigna los items a ese carril para dejar en claro en que estas.
El trabajo bloqueado es desperdicio.
Si tienes muchos items en progreso que llevan varios sprint arrastrándose tienes un problema, obvio, no están en progreso, se detuvieron hace mucho. Cada sprint en el que siguen vivos los está haciendo más costosos de pagar y con menos valor para el usuario. Si ya generaste un carril para mantener los items detenidos, entonces ¡felicidades!, tu trabajo de marcar los items como hechos o borrarlos del backlog acaba de empezar. Estos elementos una vez identificados deberían de tener prioridad alta para poderse deshacer de ellos cuanto antes. Si a nadie le interesa deshacerse de un item en concreto, puedes regresarlo al backlog o borrarlo definitivamente.
El carril de bloqueados es una herramienta útil para detectar cuellos de botella.
Si el trabajo que se detiene tiene orígenes comunes o circunstancias comunes, estas ante un cuello de botella que hay que remover. Por ejemplo: todas las adecuaciones de determinado cliente están en progreso desde hace 2 sprints, no se ha avanzado en la actividad debido a que el cliente en cuestión ha cancelado la reuniones varias veces. Bueno, el trabajo no es urgente, ni tampoco importante, estos items pueden regresar al backlog con problemas para que los desarrolladores tomen items más valiosos y que si pueden completarse, ya habrá tiempo más adelante para resolver esas adecuaciones.
Conclusiones.
El carril de bloqueados es más afín a Kanban, otras metodologías ágiles no lo contemplan explícitamente; sin embargo, lo veo como una herramienta útil a la hora de usar el tablero como herramienta de diagnóstico y toma de decisiones del proyecto. Es tentador decir que algo está en progreso cuando no lo está, le da al programador un aura de multitasking, pero no es útil a la hora de llevar un proyecto. La atención de las personas es limitada, cada cambio de actividad o multitasking es costoso y representa desperdicio. Si el trabajo se detuvo, hay que marcarlo de ese modo, no es necesario inventar rebuscadas historias de porque algo que no está en progreso, lo está.
Autor imagen: Bernard Spragg. NZ
- 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
1 comments On Agile: El carril de items detenidos o bloqueados.
Pingback: Kanban: Mi primer reunión de retrospectiva. | Happy Devops ()
Comments are closed.