Resultados de búsqueda de enero 2016

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:

¿Cómo interpretar un gráfico de control?

El uso de los gráficos de control a veces da miedo porque suena a ‘estadística’, ‘solo para los avanzados’, ‘solo si el proceso es estable’, etc.

¡Todo esto es absolutamente incorrecto!

Si tenemos sobrepeso ¿no vamos a mirar la báscula hasta que se estabilice/baje nuestro peso?

Muy a menudo no se le da uso al gráfico porque no se sabe interpretar bien.

Mira esta foto, por favor.

Carretera

Las líneas blancas marcan los límites de la carretera entre las que tiene que ir un coche (por ahora supongamos que hay sólo un carril). Un coche en movimiento siempre va un poco más cerca o más lejos de las líneas blancas, pero lo importante es que esté dentro de estos límites. Salir fuera de ellas se paga y se investiga (exagerando un poco).

En términos matemáticos estas líneas se llaman límites de control.

Los límites de control determinan el rango en el que naturalmente varían los valores de algún parámetro. Estos límites pueden ser diferentes para cada producto, tecnología o acuerdo de nivel de servicio (ANS). Por ejemplo, el esfuerzo de corrección de incidencias en tu aplicación para .net puede variar entre 2 y 5 horas, y la corrección de las incidencias en la misma aplicación para Android puede variar entre 1 y 3 horas.

Tu análisis del parámetro tiene que estar enfocado en los siguientes aspectos:

  • Los valores ¿están dentro de los límites de control?
  • Si en algún caso el valor sobresale los límites de control (p.ej. se ha dedicado más esfuerzo a la corrección de alguna incidencias), ¿por qué ha ocurrido esto? Analizar las causas, tomar acciones y aprender, para que el caso no se vuelva a dar
  • Mirar la tendencia de los datos; si los valores están uniformemente distribuidos o tienden a acercarse a alguno de los límites

Ahora mira esta otra foto.

parked_cars_with_road_lines

Debido a que hay otros coches aparcados en la calle, nuestro coche no puede acercarse a los límites de control y debe moverse entre las líneas naranjas (que he añadido yo). Este es el caso cuando la organización ha definido límites que determinan el rango de variación (movimiento) aceptable para un parámetro.

En los términos de los gráficos de control estos límites se llaman límites de especificaciones.

Las razones por las que una organización define límites de especificación pueden ser varias: ANS, expectativas del cliente, margen económico, motivos de competencia, etc.

En el caso que un parámetro tiene que respetar los límites de especificación establecidos, tu análisis incluirá también los siguientes aspectos:

  • Los valores ¿están dentro de los límites de especificación?
  • Si en algún caso el valor sobresale los límites de especificación, ¿por qué ha ocurrido esto? Analizar las causas, tomar acciones y aprender, para que el caso no se vuelva a dar

Aquí tienes un ejemplo de un gráfico de control con los límites de control (en azul) y el límite superior de especificación (en naranja) establecidos.

GraficoControlConLimites

En este caso todos los puntos rojos se tienen que analizar porque unos están por encima de los límites de especificación (establecidos por la organización) y los otros sobre salen los límites de control (de variación natural).

Cualquier duda, me dices.

Teodora Bozheva
Accredited Kanban Trainer & Consultant
Co-autora del Kanban Maturity Model
www.berriprocess.com

 

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: