La Ley de Little
El origen de la ley de Little es la Teoría de las Colas. Es quizás la ley más conocida en el modelado del
rendimiento de los sistemas TI.
La ley demuestra las relaciones entre el Lead Time, el Trabajo en curso (WIP) y
el Rendimiento (Throughput).
El Lead time: El período entre la entrada de una petición en el sistema (petición solicitada) y la
recepción de la petición. Se mide por el tiempo transcurrido (minutos, horas, etc). La petición puede ser un
requisito, una historia de usuario, una incidencia, material, una solicitud de un usuario, etc.
Trabajo en curso (WIP - Work In Progress): el número de peticiones (unidades de trabajo) que
se están procesando, es decir las que han entrado en el sistema, pero todavía no han salido.
Rendimiento (Throughput): el número de unidades de trabajo que salen del sistema en un
tiempo determinado, p.ej., 3 historias de usuario por día.
Las conclusiones de esta ley son igual de interesantes e importantes:
Cuanto más grande es el WIP, más largo es el Lead time, es decir más tardamos en terminar el
trabajo empezado. Dicho de otra manera, para cumplir los plazos de desarrollo o de los servicios, hay que
reducir el trabajo en curso, o sea procurar de cerrar trabajos antes de abrir nuevos.
Sin embargo, en muchas ocasiones ocurre justo lo contrario: los equipos empiezan a trabajar sobre
muchas tareas para que así el proyecto entero “avance” más rápidamente. Otra razón por la que se busca
asegurar mucho trabajo en curso es conseguir una alta utilización de los recursos.
Independientemente del motivo, suponiendo que el rendimiento no cambia, el aumento del trabajo en
curso aumenta también el tiempo necesario para su realización.
Aunque parezca contra intuitivo, recuerda que reducir el trabajo en curso ayuda a cumplir los ANS
y reducir los tiempos de desarrollo.
Enfocándose en reducir el Lead time ayuda identificar las actividades obsoletas que se están
llevando a cabo. Eliminándolas tiene dos efectos positivos: (1) se eliminan desperdicios en los
procesos, (2) se reduce el trabajo el curso total que resulta en un ciclo de desarrollo más corto y más
eficiente.
Cuanto mayor es el Rendimiento, tanto más corto es el Lead time.
Existen diferentes formas de mejorar el rendimiento: automatizando las actividades de valor (automatizar
actividades que no aportan valor es equivalente a automatizar la producción de desperdicios), mejorando
los procesos o añadiendo más recursos. Si decides añadir más recursos, observa el Lead time porque en
general los recursos adicionales añaden más trabajo en curso.
Cada iniciativa Lean procura de minimizar los desperdicios y de reducir los ciclos de producción.
Reduciendo el ciclo de producción es equivalente a reducir el Lead time. Minimizar los desperdicios
incluye un análisis del inventario actual y los pasos para reducirlos. Esto es equivalente a la reducción del
WIP.
¿Por qué esta ley es importante?
La ley de Little es una herramienta de conocer el rendimiento real de un equipo de operaciones o de
desarrollo de software
Proporciona previsibilidad en el proceso.
P.ej., si tenemos que implementar 50 requisitos y la capacidad del equipo es de unos 5 requisitos por
semana, el tiempo que necesitaremos es
50 requisitos/5 requisitos por semana = 10 semanas.
Demuestra que cuanto más grandes son los batches de trabajo, tanto más largo es el tiempo
de su procesamiento, el Lead time.
Explica por qué las multi-tareas retrasan en lugar de acelerar la terminación de trabajo.
Habitualmente las personas creen que trabajar sobre varias tareas en paralelo aumenta la productividad.
Por eso asignar unas cuantas tareas a una persona es una práctica común en las empresas. Sin
embargo, a diferencia de las máquinas, las personas no son tan buenas en la ejecución de procesos
paralelos. Aumentando el Trabajo en curso aumenta también en tiempo de cambiar y re-tomar las tareas y
por lo tanto reduce el Rendimiento. A consecuencia, el tiempo para ejecutar el proyecto resulta
insuficiente, el trabajo empezado y no terminado empieza a acumularse.
En breve, la ley de Little ayuda a encontrar el punto de equilibrio entre el Trabajo en curso y el Lead
time.
Proporciona los fundamentos para llegar a los óptimos límites de WIP. Si los límites de WIP
están por debajo del nivel óptimo, hay recursos infrautilizados y el rendimiento es bajo. Si los límites WIP
superan el nivel óptimo, entonces las unidades de trabajo empiezan a montar colas y el rendimiento baja.
Ayuda entender qué efectos tendrá sobre los plazos del proyecto o el servicio el bloquear un
trabajo o tener que corregir errores. En ambos casos baja el rendimiento y de ahí aumenta el Lead time.
Condiciones importantes para que funcione la ley de Little
La ley de Little es muy útil, pero además de conocer la formula tienes que tener en cuenta las condiciones
necesarias que se deben cumplir para que la ley de Little te sirva:
Se cogen valores medios de todos los parámetros: promedio del Lead time, promedio del trabajo
en curso, y promedio del rendimiento
Las unidades deben ser coherentes, p.ej. si medimos el rendimiento en una semana, el lead time
también tiene que ser en semana, así como el promedio del trabajo en curso
El sistema tiene que estar estable, es decir todo el trabajo que entra en el sistema, sale de este, el
WIP total al inicio y al final del periodo es constante, la tasa media de llegada de trabajo es igual a la tasa
media de salida de trabajo del sistema.
Para resumir, el uso correcto de la ley de Little ayuda conseguir un flujo de trabajo suave y
estable, y a mejorar la previsibilidad de los proyectos y los servicios TI. El Trabajo en curso (WIP) es un
factor clave para el rendimiento y el tiempo necesario para el desarrollo de software y/o la ejecución de los
servicios. Limitar el trabajo en curso además de reducir el Lead time lleva a una reducción de los
desperdicios en el flujo de trabajo.
La Ley del cuello de botella
La ley del cuello de botella tiene su origen en la Teoría de las Restricciones, creada por Dr Eliyahu
Goldratt y publicada en el año 1984 en su libro “La meta”.
La ley dice que cada sistema, independientemente de cuánto de bien funciona, tiene por lo menos
una restricción (un cuello de botella) que limita su rendimiento.
La ley permite deducir el tiempo de respuesta y los límites de rendimiento de un proceso - una
información imprescindible para los servicios TI y los proyectos de desarrollos de software.
Centrar los esfuerzos de mejora en resolver el cuello de botella es el camino más rápido y más
eficaz para la mejora de la rentabilidad. Los cuellos de botella pueden involucrar personas, información,
herramientas, procedimientos y pueden ser internos o externos para la organización.
El cuello de botella es la fase en el proceso en forma de sub-procesos o actividades individuales que
limitan o bloquean el flujo. En el cuello de botella el rendimiento es más bajo. O bien, es la fase en la
que una unidad de trabajo tarda más tiempo entre entrar y salir de la fase - el Lead time de esta fase es
más largo.
Por ejemplo, miremos el proceso de “lavar la ropa – secarla – doblarla”.
El cuello de botella es la secadora porque en esta fase del proceso completo el Lead time es más grande.
Los procesos involucran distintas personas, actividades y herramientas y cada uno de estos tiene un
rendimiento distinto. Por lo tanto, si las actividades de un proceso se deben ejecutar en un orden
secuencial, por ejemplo
lavar-secar-doblar
registrar para el vuelo – control de equipaje – embarque al avión
tomar requisitos – análisis-diseño-implementación – pruebas – entrega,
siempre habrá un cuello de botella en el proceso completo, especialmente si las fronteras del sistema
están establecidas relativamente ancho.
¿Cómo resolver un cuello de botella?
En el libro Kanban: Cambio Evolutivo Exitoso Para su Negocio de Tecnología de David Anderson se
pueden leer en más detalle, cómo resolver un cuello de botella en función de si está causado por una
limitación en la capacidad o en la disponibilidad del recurso.
Aquí voy a resumir los métodos de resolución de un cuello de botella:
Utilizar lo máximo del recurso: hacer que el recurso se dedique sólo a las actividades propias de
este y asignar el resto de las actividades a otros recursos
Por ejemplo, disponemos de un especialista en integración de software y debido a su participación en
varios proyectos se convierte en un cuello de botella. Una opción será dejarle que se dedique
explícitamente a las tareas de integración y asignar sus tareas de otro tipo a otros miembros del equipo.
Aumentar la disponibilidad del recurso – la frecuencia con la que el recurso está disponible
aunque sea para un tiempo más corto.
Ejemplo: El especialista en integración puede dedicar un día a la semana a cada proyecto. Una solución
más eficiente es que la persona dedique a cada proyecto media jornada dos veces a la semana, en lugar
de una jornada completa sólo un día a la semana.
Automatizar parte de las actividades.
Aumentar el recurso – suele ser la solución más cara.
Siguiendo el ejemplo de antes esto es equivalente a contratar a otra persona con los conocimientos y la
experiencia necesaria en integración de software.
FUENTE: http://old.berriprocess.com/es
0
