Exploración de la mejora continua
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 considerable entre el plazo 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.
Fuente: Forrester, Faster Software Delivery Will Accelerate Digital Transformation, 9 de marzo de 2017, de Diego Lo Giudice, Christopher Condo con Christopher Mines, 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 %.
¿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.
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 mediciones de rendimiento de la entrega de software más importantes son:
- Plazo del cambio: una medida del ritmo del rendimiento de la 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: medida directa o indirecta del tiempo de respuesta, la cohesión del equipo, las capacidades de los desarrolladores, la eficacia de las herramientas de desarrollo y la eficiencia general del equipo de DevOps.
- Tiempo medio de restauración: cuánto tiempo se tarda en general en restaurar una aplicación o un servicio principales cuando se produce un incidente.
- Porcentaje de errores de cambio: el porcentaje de cambios en producción (lo que incluye, por ejemplo, las versiones de software y los cambios de configuración de la infraestructura) que generan un error.
Es responsabilidad de la dirección 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.
Aspectos que se miden:
Uso
Velocidad
Estado del sitio activo
- Adquisición
- Involucración
- Satisfacción
- Renovación
- 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
Aspectos que no se vigilan:
- Estimación original
- Horas completadas
- Líneas de código
- Capacidad del equipo
- Evolución del equipo
- Progreso 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 organizativa: qué, cómo y por qué se compila. 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.
- Enfoque en el cliente: todos los esfuerzos deben tener un impacto directo o indirecto en el valor del cliente.
- Mentalidad de primero en producción: una mentalidad que no diferencie el modo en que se tratan las características y los errores durante el desarrollo, las pruebas y el soporte operativo. Todo debe estar automatizado, controlado y ajustado en producción.
- Desplazamiento a la izquierda de la calidad y al final de los errores: fomente las revisiones, las validaciones y las aprobaciones para pruebas y seguridad en una fase lo más temprana posible del ciclo de entrega de características para impulsar la calidad y una mentalidad de ocuparse de los errores al final.
Reacciones continuas
A continuación se va a hablar de cómo usar las reacciones continuas 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
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 entregarlas cuando lo solicita el 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.
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 trabajo sin valor añadido innecesario y necesario para ayudar a identificar los cambios futuros para la mejora del proceso.
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.
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.
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.