Seguimiento de lo que importa: Indicadores clave de rendimiento y cuadros de mando

En nuestro capítulo anterior, Diseñar para la comprobabilidad: Romper la siguiente barreraexploramos cómo la comprobabilidad se convirtió en un enfoque clave después de resolver los cuellos de botella iniciales en la configuración del equipo y las pruebas manuales. Ese capítulo marcó un punto de inflexión en nuestra transformación DevOps, ya que cambiamos la atención a los principios de diseño de software más profundos que permitieron pruebas más suaves y rápidas.

Ahora, en el capítulo 4, pasamos a una fase crítica: la definición y el seguimiento de los KPI adecuados y la creación de cuadros de mando para medir nuestro progreso. Una vez establecidas las prácticas básicas y mejorada la capacidad de prueba, necesitábamos métodos objetivos y basados en datos para visualizar el flujo, identificar las limitaciones y mejorar continuamente.

Por qué los KPI y los cuadros de mando son importantes en DevOps

A medida que avanzábamos en nuestro viaje para agilizar la entrega de principio a fin, reconocimos la necesidad de un mecanismo visual y objetivo para realizar un seguimiento del trabajo y descubrir los cuellos de botella. Para ello, tuvimos que definir unos indicadores clave de rendimiento que no se limitaran a los números, sino que pusieran de relieve información práctica e impulsaran los comportamientos adecuados.

Al establecer los KPI, es esencial reconocer que los equipos y las organizaciones tienden a optimizar las métricas que supervisan. Esto se ajusta a la Ley de Goodhart, que afirma:

"Cuando una medida se convierte en un objetivo, deja de ser una buena medida".

Este principio subraya la importancia de seleccionar KPI que guíen a los equipos hacia los resultados correctos en lugar de animarles simplemente a alcanzar objetivos. El propósito de estos KPI es medir el progreso hacia nuestro objetivo general. Pero, ¿cuál es exactamente ese objetivo?

Definir el objetivo

Como se explica en El objetivo, de Eliyahu M. Goldratt, el objetivo de una empresa es aumentar el beneficio neto y, al mismo tiempo, mejorar el ROI y el flujo de caja. Trasladando esto al contexto del desarrollo de software, donde actualmente nos encontramos en la fase de inversión, hemos identificado el objetivo como:

 "Desarrollar y entregar un producto de software comercializable que genere ingresos sostenibles".

Alcanzar este objetivo exige cumplir varias condiciones necesarias, entre ellas:

• Tiempo de comercialización → Ofrecer funciones y productos con rapidez para captar oportunidades de mercado.
• Escalabilidad futura → Garantizar que el software está diseñado para crecer con la demanda sin comprometer el rendimiento.
• Optimización de costes → Equilibrar los gastos de desarrollo al tiempo que se maximiza la entrega de valor.
• Retorno de la inversión (ROI) → Garantizar que el producto ofrece beneficios financieros a largo plazo que justifican la inversión.

Estas condiciones guiaron nuestra definición de los indicadores clave de rendimiento, queno sólo se centraronen la velocidad y la eficiencia, sino también en la creación de un producto escalable y rentable que ofrezca valor empresarial a largo plazo.

Visualización del flujo: creación de cuadros de mando

Como se indica en Accelerate de Nicole Forsgren, Jez Humble y Gene Kim, nuestro objetivo era crear un cuadro de mandos que pudiera visualizar y realizar un seguimiento de las cuatro métricas clave de DevOps:

• Frecuencia de despliegue → Frecuencia con la que los equipos despliegan código en producción.
• Tiempo de espera de los cambios → Rapidez con la que el código pasa de commit a producción.
• Change Failure Rate → Porcentaje de despliegues que causan fallos.
• Tiempo medio de restauración (MTTR) → Rapidez con la que los equipos se recuperan de los fallos.

Sin embargo, la generación de estas métricas de una manera significativa fue inicialmente un reto debido a la falta de seguimiento sistemático del trabajo en todos los equipos. Aquí es donde la adopción de Azure DevOps como solución de gestión del trabajo única y común para todos los equipos marcó una diferencia significativa.

Empezamos creando paneles de control específicos para cada equipo:

• Todos los elementos de trabajo asignados por equipo.
• Trabajo en curso.
• Obra terminada.
• Defectos clasificados por etapa y prioridad.

Primer reto: uso incoherente

Incluso con directrices claras, los equipos utilizaban los estados y las categorías de defectos de forma diferente. Esta incoherencia hacía casi imposible el análisis de flujos entre equipos.

El primer problema que encontramos fue el uso incoherente de los estados de los elementos de trabajo y las clasificaciones de defectos, a pesar de contar con directrices claras. Los distintos equipos utilizaban los estados de forma diferente, lo que dificultaba la identificación de problemas de flujo entre equipos. La coherencia en el seguimiento del trabajo se convirtió en un factor crítico para garantizar que los cuadros de mando pudieran utilizarse no sólo para los equipos individuales, sino para optimizar el flujo en toda la organización.

A continuación, nos centramos en definir correctamente los elementos de trabajo, asegurándonos de que pudieran reflejar con precisión en qué punto de la cadena de valor se encuentra el trabajo, sin dejar de ser lo suficientemente genéricos como para poder utilizarse en varios equipos. La mayoría de las herramientas ofrecen categorías de estado por defecto, pero no siempre eran suficientes. Era importante definir categorías de estado que se ajustaran a la estructura de nuestro equipo, a la forma en que fluía el trabajo y a nuestros cuellos de botella conocidos.

Analizar el flujo de trabajo para detectar cuellos de botella

Los primeros cuadros de mando se crearon principalmente para visualizar el trabajo en curso y obtener una imagen clara de lo que estaba ocurriendo en los equipos. Incluían historias de características, historias de usuario, defectos y planes de pruebas. Ofrecían una instantánea del trabajo en curso, pero no una imagen clara del flujo global de trabajo y valor.

Tener visibilidad del trabajo en curso era un primer paso importante, pero el siguiente reto era conectar esta visibilidad con métricas basadas en el flujo que pudieran poner de relieve dónde se atascaba el trabajo y dónde necesitábamos mejorar.

Utilizando el estado de los elementos de trabajo, creamos métricas para mostrar el número de elementos de trabajo en cada estado. Al principio, sólo disponíamos de información sobre el número de elementos de trabajo en diferentes estados. Un análisis más avanzado, como el seguimiento del tiempo que los elementos de trabajo permanecían en cada estado, requería herramientas adicionales, que presentamos más adelante. En esta fase inicial, sin embargo, comenzamos nuestro análisis utilizando sólo los recuentos.

Incluso con estos datos básicos, los cuadros de mando resultaron valiosos para identificar los principales cuellos de botella:

• Demasiados elementos de trabajo en curso en comparación con el número de elementos que se completan en un periodo determinado.
• Una creciente acumulación de nuevos trabajos que superaba con creces lo que podíamos completar de forma realista en los próximos 3 a 6 meses.
• Equipos con el mayor número de tareas pendientes, lo que indica dónde se necesita más atención y apoyo.

Cada una de estas perspectivas requería una solución diferente, pero la capacidad de visualizar el flujo de trabajo supuso un gran avance. Esta mejora llevó más lejos el aspecto de las herramientas de nuestro triángulo DevOps, impulsando el progreso en los otros dos aspectos: la arquitectura y las personas.

Utilizar los indicadores clave de rendimiento para impulsar la mejora continua

Volvimos al tema de los KPI en varias etapas a lo largo de nuestra transformación de DevOps. A medida que mejoraban nuestras capacidades de seguimiento, pudimos generar métricas más detalladas que us ayudaron a:

• Medir el progreso a lo largo del tiempo para asegurarnos de que avanzábamos hacia nuestro objetivo de desarrollar un producto de software comercializable.
• Identificar las dependencias y traspasos que causaban retrasos en el flujo de trabajo.
• Señalar las áreas en las que los equipos necesitan apoyo adicional o mejoras de los procesos.
• Alinear nuestros KPI más estrechamente con las cuatro métricas DevOps clave de Accelerate, proporcionando una medida objetiva de nuestro éxito.

Al alinear las herramientas, la arquitectura y las personas con los indicadores clave de rendimiento (KPI) adecuados, creamos un sistema que proporcionaba una visibilidad clara de nuestro progreso, us ayudaba aidentificar y desbloquear los cuellos de botella y garantizaba que nos mantuviéramos centrados en ofrecer valor empresarial a largo plazo.

¿Y ahora qué? Bifurcación y despliegue continuo

Con nuestros KPI y paneles de control implementados, ahora estamos listos para optimizar el flujo de código a través de los entornos y hacia la producción. En el capítulo 5, profundizaremos en cómo abordamos la ramificación y la implementación continua, y los cambios culturales y técnicos que us permitieron us más rápida y segura.

Permanezca atento.