Etiqueta: tiempo de entrega

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

Analíticas Kanban: Gestión de proyectos pragmática

Los buenos viejos tiempos

Empecé a trabajar como jefe de proyectos de desarrollo de software en 1996. Éramos un equipo de 5 personas, jóvenes y motivados, y desarrollábamos un sistema de gestión de instalaciones (inglés: facility management) para un banco.

Sólo para darte una idea de aquel tiempo, teníamos acceso a Internet en un solo ordenador, por lo que comprobábamos el correo electrónico de todo el equipo (no el personal) dos o tres veces al día. Los teléfonos móviles eran como ves en la foto, es decir, no SMS, no WhatsApp, ni nada de este estilo.

Computer_Handy_1996

Este fue el único proyecto sobre que trabajábamos, no compartíamos recursos con otros proyectos y los otros desarrollos tampoco nos impactaban tanto.

¿Tu también te acuerdas de ese tiempo?  :-)

Como jefe de proyecto era responsable de planificar, dar seguimiento y reportar el progreso del proyecto.

El cliente esperaba un producto de alta calidad, sin embargo, fue lo suficientemente paciente para trabajar con nosotros en los requisitos y dejarnos el tiempo necesario para implementarlos y hacer las pruebas.

Está chupado, ¿verdad?

Aun así, antes de cada entrega teníamos que trabajar largas hora para asegurarnos que todo funcionaba bien. Es decir, las estimaciones no se ajustaban a los números reales.

Las estimaciones y los datos reales son diferentes valores del mismo parámetro.
No fuerces (manipules) los reales para que coincidan con las estimaciones.

La supervivencia y la sostenibilidad requieren pragmatismo

Menos de 20 años después, pocos jefes de proyectos, más bien ninguno, se puede imaginar llevar un único proyecto, con un equipo totalmente dedicado a este, sin interacciones con otros desarrollos, casi sin interrupciones, con algunos cambios de requisitos manejables, y problemas relacionados sobre todo con la tecnología.

Lo interesante es que la complejidad de los métodos de gestión de proyectos ha aumentado en paralelo con el aumento de la complejidad del desarrollo de software, mientras que el tiempo para hacer las decisiones correctas es cada vez más corto y las expectativas de los clientes cada vez superiores.

Revisé mis apuntes de los últimos años. Los jefes de proyecto comparten los siguiente acerca de su trabajo:

  • Es difícil manejar la variedad de factores que influyen en un proyecto: la claridad de los requisitos, la estabilidad de las tecnologías, el nivel de conocimientos y habilidades de los miembros del equipo, los riesgos, las dependencias de otros proyectos, etc
  • Cuanto más sofisticado sea el método de estimación, más esfuerzo (y tiempo) se necesita para hacer un buen plan de proyecto. De todos modos este tiene una vida muy corta hasta que cambie de nuevo
  • Estimación, planificación, seguimiento y re-planificación es una carga administrativa muy alta, difícil de vender a los clientes, y por lo tanto sostener
  • Hay mucha presión para dar estimaciones rápidamente y después cumplirlas
  • Difícil coordinación de los proyectos.

En una situación como esta, ¿no deberíamos de revisar las prácticas de gestión de proyectos bien establecidas y buscar algunas más pragmáticas?

Aplicar métodos complejos a situaciones
complejas las complica aún más.

 

Enfoque Kanban de gestión de proyectos

¿Cuál es el propósito de gestión de proyectos? – Asegurarse que el proyecto se ajusta a los criterios de sus interesados (clientes y organización). ¿Correcto?

Aquí los tienes:

Aptitud del trabajo: Perspectivas
Cliente

  • Entregar rápidamente (tiempo)
  • Entregar a tiempo (previsibilidad)
  • Precio competitivo
  • Calidad (obtener el producto/servicio correcto)

 

 

 

 

 Organización

a. Nivel de proyecto

  • Estimaciones (tiempo, coste)
  • Previsibilidad
  • Calidad
  • Coordinación de los proyectos

b. Nivel de negocio *

  • Sostenibilidad
  • Orientación a servicio
  • Supervivencia

* Ver la charla de David J Anderson sobre las 3 agendas de Kanban.

Entonces, las dimensiones de la aptitud de un proyecto y las herramientas analíticas correspondientes se pueden resumir de la siguiente manera:

Aptitud del trabajo: Dimensiones
Tiempo de entrega

  • Tiempo de entrega (inglés: Lead time)
  • Rendimiento (inglés: throughput)

Coste

  • Coste de las actividades de valor añadido, transaccionales y de coordinación>
  • Coste de los desperdicios (corrección de defectos, re-trabajo, espera)
  • Requisitos/historias descartados
  • Eficiencia

 

 Previsibilidad

  • Cumplimiento de ANS
  • Cumplimiento de fecha fin

Calidad

  • Número de defectos
  • Esfuerzo y duración de re-trabajo

Negocio

  • Eficiencia
  • Perseverancia del flujo de trabajo (Diagrama de flujo acumulado, DFA)
  • Cumplimiento de ANS (historgrama, gráfico de control)

Pincha en los enlaces para ver cómo se utiliza cada una de las herramientas y la valiosa información que aporta a tu proyecto.

Si te fijas en las herramientas que necesitas para gestionar la aptitud del trabajo de tu proyecto con respecto a cualquier criterio, cliente o organización, te darás cuenta que lo que necesitas fundamentalmente es suficiente y, por supuesto, buenos datos reales. (En cuanto a los datos, siempre tenemos que recordar que si entra basura – sale basura).

El poder de los datos reales, no las estimaciones especulativas, te da confianza
en tus compromisos y te permite dormir tranquilo, porque
reduce los riesgos de no cumplir tus promesas.

 

Además, ahorras todo el esfuerzo para inventar y actualizar un método de estimación formal y tratar de adaptarlo a las características únicas de cada proyecto.

Para las empresas CMMI:

  • El tiempo de entrega se recoge principalmente en proyectos orientados a los servicios (por las necesidades de la gestión los ANS). Sin embargo este es un dato valioso para los proyectos de desarrollo de software también.
  • En los proyectos de desarrollo de software por lo general se registra el esfuerzo de realización de la tarea, pero no el tiempo de entrega (el Lead time) de un requisito o historia. Esfuerzo y duración no es lo mismo. Conocer la distribución del Lead time para los tipos de trabajo o las clases de servicios ayuda a conseguir una planificación más realista.
  • Conociendo el Rendimiento permite (a través de la ley de Little) dar una estimación rápida y fiable del tiempo de entrega necesario para implementar un conjunto de historias / requisitos.
  • La visualización del trabajo en curso facilitan enormemente la coordinación de los proyectos.
  • El DFA es quizás el mejor indicador en tiempo real del ritmo del trabajo (proyecto) y los riesgos.

Artículos relacionados:

Analíticas Kanban: Eficiencia

Efficiency_Sp

La eficiencia es indicador de cuánto de lean es vuestra organización.

 

En cuanto a las empresas TIC:

  • Eficiencia de flujo de unos 2% ha sido reportada [Zsolt Fabok, Lean Agile Scotland, Sep 2012].
  • Eficiencia de 5% a 15% es normal
  • Eficiencia de > 40% es buena!

Como bien se explica en el libro «This is Lean», existen tres fuentes principales de la baja eficiencia:

¿Qué causa la eficiencia baja?

Largo tiempo de entrega

Esperar demasiado tiempo para obtener un producto o servicio genera necesidades adicionales para el cliente. Estos también deben ser abordadas, y por lo tanto suelen causar retrasos adicionales.

Para dar un ejemplo: cuánto más espera un cliente la aplicación o el servicio que haya solicitado, tanto mayor será la probabilidad de pedir cambios o incluso cancelar la petición. Además, la gestión de los cambios aumenta el tiempo de entrega aún más.

De aquí…

Los equipos ágiles son más eficientes porque utilizan iteraciones de corto tiempo.

Disminuir el tiempo de entrega es uno de los medios para aumentar la eficiencia.

Una manera de reducir el tiempo de entrega es reduciendo el tamaño de las unidades de trabajo y los lotes. Por eso, cuando veo requisitos de 500-1000+ persona-horas cada uno e iteraciones de 3+ meses, siempre recomiendo reducir tanto el tamaño de los requisitos como la duración de la iteración.

Reducir el tamaño de los requisitos para aumentar la eficiencia.

Demasiados unidades de trabajo en curso

Trabajando sobre muchos requisitos / servicios / peticiones en paralelo

  • requiere esfuerzo, tiempo y recursos adicionales para su gestión: saber que se ha hecho en cada uno de ellos, dónde se almacena, que está pendiente, etc
  • lleva a multitareas (cambio frecuente de tareas) – otra fuente principal de ineficiencia. Aquí puedes ver un buen resumen del alto coste de las multitareas
  • oculta problemas porque cuando hay muchas unidades de trabajo abiertas, es difícil de detectar y corregir los problemas de calidad
  • causa ansiedad y estrés. Esto reduce la calidad del trabajo, aumenta el tiempo de corrección de problemas y, como consecuencia, reduce la eficiencia.
    Por lo tanto,

Reduciendo el trabajo en curso en un sistema kanban aumenta
la eficiencia del flujo de trabajo.

Demasiados traspasos

Piensa cómo te sientes cuando llamas, por ejemplo, a tu proveedor de telefonía móvil y te pasan de un operador a otro, y cada vez tienes que volver a explicar tu problema desde el principio. Des de la perspectiva del cliente los traspasos generan frustración ¿verdad?

Desde la perspectiva del proveedor de servicio el traspaso de un trabajo a otra persona siempre conlleva el riesgo de pérdida de información y generación de defectos. Además, cualquier traspaso de trabajo requiere esfuerzo y tiempo adicional para explicar, de forma oral o por escrito, el estado actual del trabajo y lo que ha de tener en consideración en las etapas posteriores.

Los traspasos no siempre se pueden evitar, sin embargo el trabajo en equipos
multidisciplinarios reduce sus efectos negativos.

 

Artículos relacionados:

Analíticas Kanban: Lead time

Lead time

(Tiempo de entrega, Tiempo de ejecución, Tiempo de entrega del sistema)

Lead time es el tiempo que transcurre desde el principio hasta el final del procesamiento de un elemento de trabajo.

Ejemplos:

  • Decides comprar por internet un billete de avión para tus vacaciones. El Lead time de adquirir el billete empieza a correr en el momento en el que te sientas en frente al ordenador y abres un navegador, y termina cuando tienes tu billete electrónico en tu buzón.
  • Quieres ver a tu médico. El Lead time de la obtención de tu diagnóstico es el tiempo entre el momento de llamar para pedir una cita y el de salir de la consulta con tu diagnóstico en mano.
  • El tiempo de ejecución para el desarrollo de un requisito de cliente es el tiempo desde el momento en que tu equipo empieza a trabajar en él hasta el momento en que la funcionalidad está lista para subirla en producción. Es decir, el tiempo que transcurre entre el momento en que el requisito entre y salga del sistema kanban (alcanza una columna con límite WIP infinito).

SystemLeadTime_Sp

Para medir bien y consistentemente el Lead time, es importante establecer los límites del sistema kanban.

¿Por qué el Lead time es importante para ti?

  • El tiempo de entrega es un indicador del valor. Cuanto más rápido ofreces valor a tus clientes, mejor. Sin embargo, hay que tener en cuenta las expectativas del cliente también. Entregando demasiado rápido no siempre aporta valor. Por ejemplo impartiendo una clase de 8 horas en solo 6 horas no hará los alumnos más contentos.
  • El plazo de ejecución es crucial para las empresas orientadas a servicios, porque ayuda a establecer ANS realistas, así como gestionar el cumplimiento de estos.
  • Conocer la distribución del tiempo de entrega proporciona previsibilidad. Desde luego, es importante conocer la distribución del tiempo de entrega por tipo de trabajo o clase de servicio.
  • Si además del plazo de ejecución del sistema, observas el tiempo que cada unidad de trabajo pasa en una columna (un estado), podrás reducir la espera y de esta manera, acelerar el desarrollo o el servicio y mantenerse lean (la espera es una forma de desperdicio).
  • Te podría resultar útil comparar el tiempo de valor añadido y el tiempo de ejecución. En otras palabras, comprobar la eficiencia de vuestro trabajo. Un momento esencial para un cliente mío fue cuando se dieron cuenta que el trabajo desarrollado en 6-10 horas se entregaba a sus clientes en 35-52 días!
  • En un sistema kanban estable conocer el trabajo en proceso (WIP) y el tiempo de ejecución permite calcular el rendimiento (aplicando la ley de Little). El rendimiento es similar a la métrica Ágil velocidad. Observar su tendencia te da una indicación del rendimiento general de tu equipo.

Herramientas para analizar el Tiempo de entrega

Histograma

Histograma_Sp

Conociendo la variación del tiempo de entrega para requisitos de tamaño Pequeño, y teniendo entendimiento del contexto (claridad del requisitos a desarrollar, el nivel de experiencia del equipo, tecnología, riesgos) puedes prever más fácilmente el tiempo que le llevará a tu equipo implementar una funcionalidad concreta.

Los datos reales ya incluyen información del impacto de los factores que influyen en el desarrollo de esta clase de requisitos. Por lo tanto, no necesitas una fórmula estricta para estimar el tiempo de desarrollo de un nuevo requisito.

Asegúrate que conoces la distribución del tiempo de entrega de los tipos
de trabajo y clases de servicios y deja de preocuparte por tus compromisos.

 

Histograma_2Modas_Sp

Algo importante. Si obtienes un histograma como éste, con dos modas, esto significa que has mezclado datos de diferentes tipos. Continuando con el ejemplo anterior, esto probablemente significa que mezclado datos de requisitos de tamaño Pequeño y Mediano.

Estratificar los datos para hacer conclusiones sólidas.

 

Gráfico de control

ControlChart_Sp

El gráfico de control es otra forma de visualizar los mismos datos que ves en el histograma, juntos con su media y los límites de control superior e inferior.

Ver ¿Cómo interpretar un gráfico de control? para más detalles.

Analiza las causas para los puntos que quedan fuera de los límites de control. Estas causas se denominan causas especiales o causas asignables. Si no estás satisfecho con la distancia entre los límites de control, puedes analizar las causas comunes para la variación y abordarlas para reducir la variación. De esta manera mejorarás la previsibilidad.

Uso de los gráficos para tomar decisiones

Histograma_Estimation_SpEstos gráficos son particularmente útiles cuando tienes que estimar el riesgo de cumplir las expectativas del cliente.
Imagínate que tu cliente espera una nueva funcionalidad pequeña en un día sólo (teóricamente 8 horas de trabajo :-)).

¿Con qué confianza te comprometerás entregársela a tiempo?

¿Y si el cliente espera tenerla en 6 horas?

Herramientas

Las herramientas Kanban suelen construir estos gráficos de los datos en el sistema.

Artículos relacionados: