Los items rezagados son un síntoma de mal funcionamiento o defectos en tu producción cuando trabajas con Kanban. Este es un marco de trabajo que va del flujo, el movimiento de actividades de izquierda a derecha o pull es lo que mantiene vivo el tablero. Cuando detectes items que se mueven más lento de lo normal o carriles más recargados que otros puede deberse a una serie de problemas en cómo se está trabajando la actividad o como fue planteada. A continuación te menciono algunos motivos por los cuales tienes atascos:
Caso 1: La persona asignada a la actividad está bloqueada o necesita ayuda.
Una forma común de desperdicio es cuando el programador tiene un handoffs. Esto significa que él o ella ha detenido su trabajo por causas ajenas o externas, por ejemplo, se está esperando observaciones del cliente, su actividad tiene dependencias con otra que aún no ha finalizado o simplemente la definición de hecho de la actividad es vaga o incompleta. Todos estos factores van a retrasar el avance.
También es posible que tengas factores técnicos, internos o de infraestructura que hagan difícil completar una tarea, desde usar un nuevo framework o api, un bug difícil de reproducir o poca experiencia del programador asignado.
Debes ser capaz de detectar cuando un compañero está detenido. Hablando desde mi propia perspectiva de programador he tenido momentos en donde yo no fui capaz de percibir que estaba bloqueado. Tenía la idea de que las cosas se movían lento, no de que necesitara la ayuda de mi equipo. Solo fue hasta que una persona de mi equipo se acercó para ofrecerme su ayuda cuando entendí que estaba cavando el hoyo en el que estaba metido.
Caso 2: El item debería ser dividido en actividades más pequeñas.
Dividir tareas no es una ciencia exacta, con el tiempo vas teniendo intuición para dividir tareas en unidades atómicas. Algunas tareas van a ser engañosas, las vas a ver como tareas pequeñas de horas o algunos días y poco a poco van a ir terminando en hilos de conversación de 60 o 70 comentarios que llevan más de dos semanas «en progreso» o «liberada en QA«.
Esto se puede deber a miedo de reconocer un regreso, reconocer que el trabajo no cumplió con los requisitos mínimos de calidad puede ser un sapo difícil de tragar para algunos. También podemos hablar de pereza, algunas personas pueden preferir llevar todo en la misma actividad para evitar tener que administrar sus tareas; este es un punto difícil, ya que es bastante debatible que tan grande o qué tan pequeña debería ser una actividad. Lo recomendable en mi caso es registrar una actividad de micro-mejora, corrección o comentario de cliente en una actividad nueva y dejar morir la actividad original.
Caso 3: Se necesita más trabajo de diseño.
Diseñar en el papel es una actividad infravalorada, últimamente, la ventaja del diseño es que es barato. Si haces un mal diseño que no soluciona las necesidades de tu usuario, borras o modificas y ya. En cambio, si te das cuenta de que tu diseño es malo o insuficiente en la etapa de construcción con toda seguridad, vas a tener que tirar trabajo a la basura generando desperdicio. Es preferible fallar en una hoja de papel que en un primer entregable.
Caso 4: La persona asignada a la actividad está expandiendo el alcance de la actividad inapropiadamente.
Este caso es una variante del caso 2, y suele pasar cuando se quieren empujar muchos cambios en la fase final y se etiqueta todo este trabajo no planeado como «seguimiento» o «fase de estabilización». El programador mete cambios que no fueron requeridos o que no pudo completar en el transcurso de la actividad inicial. Es válido que te equivoques en las estimaciones o que tengas que hacer trabajo adicional que no estuvo contemplado en la planeación inicial, refleja las actividades de este trabajo en tu tablero, de lo contrario los demás interesados del proyecto tendrán una mala imagen de tu trabajo.
Caso 5: Existen bugs sin resolver.
Los bugs son inevitables, la única pregunta que debes de hacerte acerca de ellos es ¿cuándo y donde aparecerán?. No está mal que surjan comportamientos no esperados en tus entregables, corregir estas desviaciones es tu trabajo y obviamente, si hubieras sabido desde el principio que un bug iba a ocurrir este jamás habría llegado a producción. Termina la actividad que ocasionó el error lo más pronto posible o en su lugar registra los bugs aparecidos en nuevas actividades para que sea visible el porqué un determinado item no se está moviendo.
Conclusiones.
Un carril recargado es un síntoma de que algo no funciona como debería, siempre debes entender el porqué. Kanban te ayuda a ver tu flujo completo y después de hacer un análisis entender cómo puedes optimizar tu línea de producción, no se trata de buscar culpables, se trata de optimizar el producto que entregaras.
Autor imagen: Photo Monkey
- 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
