Resultados de búsqueda de enero 2nd 2016

¿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: