Etiqueta: ley de Little

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).

Little's Law

  • El Lead time: El período entre la entrada de un 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 Process): 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 para los Jefes de proyectos?

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.

Artículos relacionados:

Referencias

  1. Little’s Law on wikipedia
  2. Little’s Law – artículo en formato .pdf

Los principios de la gestión de proyectos que (casi) nadie enseña

Me dedico a la gestión de proyectos desde hace ya diecisiete años. He llevado a cabo proyectos de desarrollo de software para banca, para ingenieros civiles y para gestión documental.

He aplicado las prácticas deProjectMgmt_Sp

  • Rational Unified Process (RUP)
  • Método de Valor Ganado
  • PMBoK
  • CMMI™
  • Gestión de proyecto ágil (basada en Scrum)

Aunque siempre estaba tratando de aplicar correctamente los métodos, identificar y abordar los riesgos adecuadamente, hablar con el equipo a diario (la comunicación nunca ha sido un problema en nuestros proyectos), comunicar con el cliente a menudo, he sufrido los problemas de:

  • Estimaciones inexactas
  • Tener que trabajar largas horas y los fines de semana para cumplir fechas
  • “Todo es urgente” y se tiene que implementar en la iteración en curso
  • Tener que parar todo el proyecto para corregir un error en el diseño de la arquitectura
  • Subir a producción sin haber hecho todas las pruebas por falta de tiempo.
  • No saber cómo exactamente actuar para eliminar una desviación de plazo o de presupuesto y volver el proyecto a lo estimado

Hasta que aprendí Kanban y asistí al curso Kanban Coaching Professional con David Anderson, ninguno de los métodos me había enseñado que para que fuese bien el trabajo en los proyectos tenía que enfocarme también en lo siguiente:

  • Asegurar un flujo de trabajo suave
  • Aplicar la Ley de Little para equilibrar la demanda de trabajo y la capacidad del equipo
  • Resolver los cuellos de botella para mejorar el flujo de trabajo
  • Conocer la variación de los procesos y los efectos de esta.
  • Hoy me pregunto ¿por qué nadie me enseñó esto antes?

Si tuviera estos conocimientos antes, mis proyectos hubieran ido mucho más suave…

En fin, la máquina del tiempo todavía existe sólo en las películas.

De todos modos, si eres Jefe de proyecto, Team leader o Scrum Master, cuando tengas un rato, échales un vistazo a estos temas. Te ahorrarán algún que otro fuego.

Artículos relacionados:

Analíticas Kanban: Rendimiento

La métrica rendimiento (tasa de entrega) es relativamente poco conocida en las empresas de gestión de proyectos tradicional (basadas en PMBOK, PRINCE2, CMMI). Sin embargo, con la difusión de los conceptos Lean, creo que empezará a ganar más respeto en el futuro próximo.

El rendimiento es la cantidad de elementos de trabajo entregados en un período determinado de tiempo (p.ej. semana, mes, trimestre).

Cuando decimos ‘entregado’ nos referimos realmente a trabajo terminado y, posiblemente, entregado al cliente. Es decir, al final del proceso se cobra.

Para entender el concepto de rendimiento, vamos a suponer que durante las últimas cinco semanas un equipo ha entregado respectivamente 4, 6, 4, 2, y 3 historias de usuario (requisitos) por semana. Si hay historias empezadas, pero no terminadas, estas no forman parte de los cálculos.

El rendimiento promedio del equipo durante estas cinco semanas es (4 +6 +4 +2 +3) / 5 = 4 historias / semana (redondeado). La desviación estándar se redondea a 1 historia / semana.

El rendimiento se basa en datos reales de la capacidad del equipo de terminar/entregar trabajos. La variabilidad del rendimiento refleja el impacto de factores como el tamaño de las historias, su complejidad, urgencia, así como las habilidades de la personas.

El rendimiento se puede utilizar para planificar un proyecto. Por ejemplo, siguiendo con el ejemplo anterior, el equipo puede estimar que su rendimiento (capacidad de la entrega) será de 4 ± 1 historias por semana sin hacer ninguna estimación detallada de los requisitos individuales.

En Kanban, sin embargo, el rendimiento se utiliza principalmente para dar seguimiento al ritmo de producción (entrega) del equipo. Lógicamente, el objetivo es mejorar continuamente.

El rendimiento es una medida del número de elementos de trabajo que el equipo es
capaz de producir en un determinado período de tiempo (por ejemplo, semanas,
meses), siempre y cuando se mantenga una carga de trabajo uniforme.

Rendimiento y velocidad

El rendimiento es similar a la métrica ágil velocidad, sin embargo, se utiliza de manera diferente.

La velocidad se utiliza en eXtreme Programming y Scrum. Muestra la cantidad de trabajo que un equipo puede completar en una iteración o sprint. El trabajo se mide en puntos de la historia (story points).

Volviendo al ejemplo del equipo anterior, supongamos que los cinco casos de uso completados durante las últimas dos semanas, son de 3, 4, 1, 5 y 3 puntos de historia respectivamente.

Entonces, el número total de puntos de la historia que el quipo puede completar en un sprint de 2 semanas es 3 +4 +1 +5 +3 = 16. Es decir, la velocidad del equipo es de 16 puntos de la historia por sprint.

La velocidad también varía debido a factores como la complejidad de las historias, su tamaño, los cambios, el nivel de habilidades de equipo, etc.

Los equipos ágiles utilizan la velocidad promedia para estimar cuántas historias serán capaces de implementar en los sprints futuros. A pesar de todo, tienen que estimar los casos de usuario individuales con el fin de definir el backlog (el alcance) de un sprint.

Así que, aunque la métrica velocidad se asocia con rapidez, de hecho se trata de la carga, (medida habitualmente en puntos de historia) que un equipo puede llevar a cabo durante un período de tiempo determinado (iteración, sprint).

Rendimiento y estimación de los recursos

El rendimiento se puede utilizar para estimar los recursos necesarios para realizar un desarrollo o servicio.

Según la Ley de Little:

ThroughputFormulae_Sp

Si un equipo mantiene a un ritmo constante de trabajo, el tiempo promedio de entrega (lead time) para un determinado tipo de trabajo o una clase de servicio puede considerarse como una constante.

El rendimiento (throughput) es el objetivo que debe lograrse con el fin de cumplir la fecha fin definida por el cliente.

Aplicando la ley de Little calculamos el número de elementos de trabajo que hay que procesar en el tiempo determino.

Ejemplo: supongamos que el tiempo de entrega de una historia es de 0,25 semana. El rendimiento objetivo es de 20 historias/semana.

Entonces, El trabajo en curso (WIP) = 20*0,25 = 5 historias.

Asumiendo que una persona sólo puede trabajar sobre un único requisito, deducimos que necesitamos un mínimo de 5 personas para la implementación de todo el trabajo a tiempo. Por si acaso (no hay fórmulas precisas para esto), estaría mejor contar con un equipo de 6 personas. :-)

La ley de Little y el rendimiento permiten estimar los recursos necesarios
para llevar a cabo un trabajo.

En resumen, el rendimiento es fácil de recoger. Es una medida valiosa, ya que mantiene el foco centrado en la capacidad productiva del equipo. Asimismo, conociendo el rendimiento del equipo disminuye el esfuerzo para la estimación de las historias (requisitos), siempre y cuando estas se desglosan a trozos relativamente pequeños. Además, a través de la ley de Little, el rendimiento permite estimar los recursos necesarios para completar un trabajo determinado en el tiempo esperado por el cliente.

Artículos relacionados

Diagrama de flujo acumulado. ¿Todavía no lo utilizas?

Si eres responsable de la entrega de resultados a tus clientes y todavía no utilizas un diagrama de flujo acumulado (DFA) para gestionar tus proyectos de desarrollo y / o servicios, abre los ojos para esta herramienta. La querrás consultar a diario.

El trabajo se considera terminado cuando está entregado al cliente, ¿verdad? Sólo entonces podemos cobrar por ello.

Por tanto los equipos ágiles miden el progreso de un proyecto mediante el número de historias / requisitos entregados al cliente. Al principio en Scrum se usaba el gráfico burn down que mostraba el número de horas (o story point) restantes para completar el backlog. Luego se empezó a usar el gráfico burn up. Este muestra el número de features/funcionalidades realizadas por el equipo cada día. Esta información, junto con la métrica de velocidad se utiliza para proyectar una terminación sprint / iteración.

BurnUpChart_Sp
Sin embargo, teniendo en cuenta sólo el trabajo terminado no es suficiente.

La Ley de Little nos dice que el tiempo de entrega depende del trabajo en curso (TEC; WIP). WIP es todo el trabajo que se ha iniciado y aún no ha terminado, es decir, todo el trabajo entre Análisis y Despliegue, suponiendo que la etapa antes de Análisis es Backlog y la después de Despliegue es Hecho.

CFD_LittleLaw_Sp

Así que hay que mantener un ojo sobre el WIP.

Si el WIP aumenta, la fecha de entrega está en riesgo.

Por lo tanto, es mucho mejor trabajar con menor tamaño del sprint backlog / iteración que con los más grande. También, manteniendo el WIP menor, reduce el esfuerzo gastado en cambiar de tarea (task switching).

La reducción de tamaño del alcance (de una iteración o sprint)
aumenta la velocidad de entrega.

 

Como un buen gestor, además de conocer lo que se está desarrollando actualmente, tendrás que saber cuál es el estado del trabajo, cuáles de las unidades de trabajo están experimentando problemas, tienen defectos, o impiden la implementación de los demás. Es tu trabajo lo de resolver los obstáculos y asegurar un flujo de trabajo continuo.

Según la Teoría de las Limitaciones, cada sistema tiene al menos una restricción (cuello de botella). Así que hay que

  1. Identificar la restricción
  2. Decidir cómo explotar la restricción
  3. Subordinar todos los demás procesos de la decisión adoptada en el paso 2.
  4. Si después del paso 2 y 3, se necesita más capacidad, elevar la restricción.
  5. Ir al paso 1

¿Cómo detectar el cuello de botella en el flujo de trabajo?

De la Ley del cuello de botella, sabes que un cuello de botella es el lugar donde el rendimiento es más bajo. Por lo general, antes de este lugar hay una cola y después de él el rendimiento no es óptimo. Como ejemplo, piensa en un peaje en una autopista, un puente (ej. Puente Colgante de Bizkaia) en una hora pico, o un punto de control de seguridad en un aeropuerto.

Volviendo a nuestro flujo de trabajo de desarrollo de software, podemos visualizar la cantidad de elementos de trabajo en cada etapa diferente (análisis, implementación, prueba, despliegue, hecho) utilizando bandas de diferentes colores.

CFD_Sp

Ahora hay que observar si hay una banda que está cada vez más delgada, mientras que la correspondiente a la etapa anterior en el flujo de trabajo es cada vez más ancha (equivalente a una cola creciente).

CFD_CuelloDeBotella_Sp

Si ves este patrón, aplica los pasos mencionados arriba para resolver el cuello de botella.

Ten en cuenta que cuando vemos un cuello de botella, instintivamente pensamos que necesitamos más recursos. Sin embargo esta suele ser la solución más cara y no siempre la mejor. Ver el capítulo 17 Cuellos de botella y disponibilidad no instantánea en el libro «Kanban» de David Anderson para más detalles sobre cómo resolver los cuellos de botella. También te podría resultar interesante la historia de Esteban, el cuello de botella.

En Cumulative Flow Diagram Pawel Brodzinski muestra otros patrones de DFA que puedes ver si utilizas este gráfico.

Para resumir,

El Diagrama de Flujo Acumulado es una herramienta práctica que te ayuda a ver el estado del trabajo en curso, el ritmo del proyecto e identificar rápidamente los riesgos asociados al tiempo de entrega, así como los cuellos de botella.

Dibujar un DFA manualmente requiere concentración y buenas habilidades de representación numérica. Sin embargo, la mayoría de las herramientas de Kanban te proporcionan este gráfico automáticamente. Además, puedes elegir qué etapas del flujo de trabajo visualizar.

Para las organizaciones de gestión tradicional:

Si estás acostumbrado a monitorizar el progreso de un proyecto contra su plan y estimar la fecha fin en base al camino crítico del proyecto, utilizar el DFA también te resultará útil para lo siguiente:

  • Identificar los riesgos de retraso del proyecto antes de recibir el próximo informe del estado del proyecto
  • Detectar los obstáculos en el flujo de trabajo y eliminarlos antes de sufrir su impacto en el cumplimiento del calendario del proyecto
  • Obtener de un vistazo un imagen completa del estado del trabajo actual y el ritmo del proyecto.

Por otra parte, los datos que necesitas para hacer el DFA son sólo los estados de los elementos de trabajo (tareas, requisito, historia, boleto, incidente) y el tiempo que cada uno de ellos ha estado en el proceso (lead time). Las herramientas corporativas suelen tener estos datos. Lo que es crucial, por supuesto, es que los datos sean correctos, no manipulados.

Artículos relacionados: