Exploración de la mejora continua

  • 5 minutos

La mejora continua es una de las ocho capacidades de la taxonomía de DevOps.

Explicación de la necesidad de la mejora continua

La mejora continua implica y requiere mediciones. ¿Cómo se identifica la mejora si no se mide?

El informe de Forrester Faster Software Delivery Will Accelerate Digital Transformation, publicado en 2017, muestra un desperdicio significativo entre el tiempo de espera y el tiempo de proceso. Nos recuerda que, si no se mide, no se puede saber la diferencia, es decir, cuánto desperdicia la organización.

Después de medir el impacto que tienen los desperdicios específicos sobre el proceso, es fácil priorizar el trabajo para realizar mejoras.

Diagrama que muestra un desperdicio significativo entre el tiempo de ejecución de 123 días y el tiempo de proceso de 39 días. Esto equivale a un tiempo de espera de 84 días.

Fuente: Forrester, La entrega más rápida de software acelerará la transformación digital, 9 de marzo de 2017, por Diego Lo Giudice y Christopher Condo con Christopher Mines y Luis Deya

¿Pero cómo se mejora la experiencia del cliente si no se mide? Forrester Research ha demostrado que "una pequeña superposición entre las características probadas y usadas significa que los desarrolladores necesitan una mejor información del cliente". La superposición entre las características de la aplicación probadas y las usadas es de aproximadamente el 35 %.

En el diagrama se muestra que solo hay una superposición de 35% entre las características que se están probando y las que se usan.

¿Cómo se puede compilar el software adecuado si no se miden el uso y el impacto de las nuevas características? Con una posibilidad del 65 % de equivocarse, conocer la diferencia es fundamental.

Descripción de la mejora continua

La observación continua y con una mente abierta del proceso de DevOps permite a los equipos identificar posibles puntos de mejora.

Toda mejora exige cambios, pero no todos los cambios suponen una mejora. Por eso la medición es un factor de éxito crítico para las organizaciones que usan DevOps. Como dice Peter Drucker, "si no se puede medir, no se puede mejorar".

La falta de un mecanismo de reacciones eficaz dificulta la mejora del impacto de las aplicaciones en el negocio. Por eso es importante crear un entorno que fomente un enfoque centrado en el aprendizaje para la mejora de DevOps cuyo énfasis se ponga en la realización de ajustes basados en los datos. En el diagrama se muestra que debemos usar medidas e impactos para generar mejoras. La medida debe dar lugar a un cambio de comportamiento positivo. Las organizaciones deben evolucionar a una práctica de aprendizaje continuo y comentarios para crear una mejora continua en el rendimiento de la entrega de software.

Mediciones y métricas

En primer lugar, vamos a hablar de las mediciones. Según el libro Accelerate de Nicole Forsgren, Jez Humble y Gene Kim, las cuatro medidas más importantes del rendimiento de entrega de software son:

  • Tiempo de espera para el cambio: una medida del tempo de rendimiento de entrega de software. El tiempo necesario para pasar del código confirmado al código que se ejecuta correctamente en producción.
  • Frecuencia de implementación: una medida directa o indirecta del tiempo de respuesta, la cohesividad del equipo, las funcionalidades de desarrollador, la eficacia de las herramientas de desarrollo y la eficacia general del equipo de DevOps.
  • Tiempo medio para restaurar: cuánto tiempo tarda normalmente restaurar una aplicación o servicio principal cuando se produce un incidente de servicio.
  • Porcentaje de error de cambio: el porcentaje de cambios en producción (incluidos, por ejemplo, versiones de software y cambios de configuración de infraestructura) que producen un error.

Es responsabilidad del liderazgo de DevOps medir aspectos como las métricas de estado operativo, el uso, la velocidad y el estado del sitio activo. Es decir, medir el IMPACTO, no la ACTIVIDAD. Una métrica solo es útil si permite actuar.

Aunque los equipos Scrum miden la capacidad del equipo, la velocidad de este, la evolución y el número de errores, estas métricas solo son relevantes en el contexto del equipo. Pero es importante que la dirección de DevOps permanezca centrada en el impacto.

Importante

Mida el impacto, no la actividad.

Cosas que medimos:

Uso

Velocidad

Salud en tiempo real del sitio

  • Adquisición
  • Involucración
  • Satisfacción
  • Abandono
  • Uso de características
  • Tiempo de compilación
  • Tiempo de prueba automática
  • Tiempo de implementación
  • Tiempo de aprendizaje
  • Tiempo de detección
  • Tiempo de comunicación
  • Tiempo de mitigación
  • Impacto en el cliente
  • Elementos de prevención de incidentes
  • Problemas de sitios activos antiguos
  • SLA por cliente
  • Métricas de soporte al cliente

Cosas que no vemos:

  • Estimación original
  • Horas completadas
  • Líneas de código
  • Capacidad del equipo
  • Evolución del equipo
  • Velocidad del equipo
  • Número de errores detectados

Importante

Las métricas afectan a los resultados empresariales.

La alineación de los KPI con los hábitos es importante. Ayuda a lograr resultados empresariales positivos.

Los hábitos importantes para reforzar los KPI y llevar a los equipos al éxito deberían incluir:

  • Autonomía del equipo y alineación de la organización: Qué, cómo y por qué creamos. Se necesita una cadencia común, o latido, en toda la organización para permitir que la dirección y los equipos de características colaboren de forma transparente y eficaz.
  • Atención al cliente: todos los esfuerzos deben tener un impacto directo o indirecto en el valor del cliente.
  • Mentalidad orientada a la producción: una mentalidad que no diferencia cómo se gestionan las funcionalidades y los errores durante el desarrollo, las pruebas y el soporte operativo. Todo debe estar automatizado, controlado y ajustado en producción.
  • Integrar actividades de garantía de calidad (QA) lo más temprano posible en el ciclo de desarrollo y respuesta rápida a errores: fomenta las revisiones, validaciones y aprobaciones tanto de pruebas como de seguridad lo antes posible en el ciclo de entrega de funcionalidades, para impulsar la calidad y una mentalidad con respuesta rápida a errores.

Diagrama que muestra la relación entre métricas, KPI, hábitos y resultados empresariales. Las métricas admiten KPI, que deben alinearse con los hábitos para lograr los resultados empresariales. Entre los ejemplos de KPI se incluyen el tiempo de ejecución, la frecuencia de implementación, el tiempo medio de restauración y la tasa de errores de cambio. Estos KPI deben alinearse con los hábitos como: autonomía del equipo y alineación de la organización, enfoque del cliente, mentalidad de primera producción y cambio de calidad a la izquierda y rápido. Esta alineación ayuda a lograr resultados empresariales como un tiempo de comercialización más rápido, mayor calidad, menos residuos y seguridad de un extremo a otro.

Reacciones continuas

A continuación, consideremos cómo usar comentarios continuos para la colaboración.

Los desarrolladores de aplicaciones modernas de los que más se habla provienen de startups. ¿Por qué tienen tanto éxito? Porque sus procedimientos de producción ajustada no están lastrados por años de procesos mejorados.

Las startups de producción ajustada han establecido una ruta óptima para el desarrollo, la entrega y la mejora de ideas gracias a la creación de una cultura de reacciones continuas increíblemente positiva:

  • Publique pronto y publique a menudo
  • Comience con un producto viable mínimo
  • Use desarrollo basado en hipótesis
  • Mejore de forma continua mediante las reacciones de los clientes

Diagrama que muestra el ciclo de comentarios continuos. Comenzamos con ideas, compilamos el código y medimos los resultados para recopilar datos. La fecha nos ayudará a aprender y generar nuevas ideas. Los comentarios continuos minimizan el tiempo total a través del bucle.

Mejora continua por medio de la asignación de flujo de valor

Cuando se tienen medidas y reacciones, la mejora se convierte en un ejercicio controlado por datos.

Una manera eficaz de respaldar la mejora continua es por medio de la asignación de flujo de valor. Un flujo de valor es una secuencia de actividades que una organización realiza para entregar una solicitud de cliente.

La asignación de flujo de valor es una manera muy eficaz de aprender a ver y resolver desconexiones, redundancias y brechas en el modo en que se realiza el trabajo. No se trata simplemente de una herramienta, sino de una metodología basada en el equipo que creemos que es la base de un procedimiento de administración probado.

El análisis del flujo de valor permite desglosar el proceso de entrega y medir el plazo, el tiempo de ciclo y el tiempo de inactividad, lo que ayuda a los equipos a realizar ajustes basados en los datos en el flujo de trabajo.

Estas medidas ayudan a los equipos a planear, detectar variaciones de eficacia e identificar posibles problemas del proceso.

Diagrama que muestra las fases del proceso de entrega. El tiempo de espera es el tiempo total en todas las fases. El tiempo de inactividad es el tiempo entre dos fases. El tiempo de proceso o ciclo mide la duración de una fase.

Sugerencia

Cuanto menores sean el plazo y el tiempo de ciclo, más rápido es el rendimiento del equipo.

Es necesario poder identificar la diferencia entre el trabajo innecesario que no agrega valor y el trabajo necesario que no agrega valor para ayudar a identificar los cambios futuros para la mejora de procesos.

Un trabajo sin valor añadido innecesario es un verdadero desperdicio: el cliente no lo valora y la organización no tiene que hacerlo para ser una empresa viable. Consume recursos sin agregar ningún valor al producto.

El diagrama muestra que el tiempo de ejecución incluye tiempo de proceso innecesario y necesario que no aporta valor, así como tiempo de proceso que aporta valor.

DevOps controlado por datos: las métricas guían el recorrido

La transformación de DevOps es un recorrido, y la manera mejor y más eficaz de orientarse a lo largo del recorrido de DevOps es por medio de DevOps controlado por datos.

Diagrama que muestra el flujo del recorrido de DevOps. Los equipos comienzan la transformación e identifican las ganancias rápidas. La automatización ayuda a que los de bajo rendimiento progresen a medianos. La automatización aumenta los requisitos de prueba, que se abordan manualmente. Una montaña de deuda técnica bloquea el progreso. La deuda técnica y la mayor complejidad provocan controles manuales y capas de proceso adicionales en torno a los cambios, lo que ralentiza el trabajo. ¡El trabajo de mejora constante conduce a la excelencia y al alto rendimiento! Los de alto y élite rendimiento aprovechan la experiencia y aprenden de sus entornos para ver incrementos en la productividad.

Se sugiere establecer un enfoque holístico para medir la eficacia de DevOps y ofrecer transparencia en las iniciativas de transformación de DevOps. Cree una cultura que fomente el aprendizaje y la experimentación que DevOps necesita centrándose en las métricas que enfatizan el éxito. Acepte esos éxitos celebrando el comportamiento correcto en lugar de castigando el erróneo.