5 min de lectura
En nuestro capítulo anterior, Diseño para la capacidad de prueba: rompiendo la siguiente barrera, analizamos cómo la capacidad de prueba se convirtió en un enfoque clave tras resolver los cuellos de botella iniciales en la configuración de los equipos y las pruebas manuales. Dicho capítulo marcó un punto de inflexión en nuestra transformación DevOps, ya que centramos la atención en principios de diseño de software más profundos que permitieron realizar pruebas más ágiles y rápidas.
Ahora, en el capítulo 4, avanzamos hacia una siguiente fase fundamental: la definición y el seguimiento de los KPI adecuados, así como la configuración de paneles para medir nuestro progreso. Con las prácticas básicas implementadas y la mejora en la capacidad de prueba, necesitábamos formas objetivas y basadas en datos para visualizar el flujo, identificar limitaciones y mejorar de manera continua.
Por qué son importantes los KPI y los paneles en DevOps
A medida que avanzábamos en nuestro camino para agilizar la entrega de punta a punta, reconocimos la necesidad de contar con un mecanismo visual y objetivo para realizar un seguimiento del trabajo y detectar los cuellos de botella. Esto significaba definir indicadores clave de rendimiento (KPI) que no se centraran únicamente en cifras, sino en destacar información práctica y fomentar los comportamientos adecuados.
Al configurar los KPI, es fundamental reconocer que los equipos y las organizaciones tienden a optimizar las métricas que supervisan. Esto coincide con la ley de Goodhart, que establece lo siguiente:
"Cuando una medida se convierte en un objetivo, deja de ser una buena medida".
Este principio recalca la importancia de seleccionar KPI que orienten a los equipos hacia los resultados correctos, en lugar de incitarlos simplemente a alcanzar metas. El propósito de estos indicadores es medir el progreso hacia nuestro objetivo general. Pero ¿cuál es exactamente ese objetivo?
Definición del objetivo
Tal como se analiza en La meta, 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. Si trasladamos esto a nuestro contexto de desarrollo de software, en el que actualmente nos encontramos en la fase de inversión, identificamos el objetivo de la siguiente manera:
«Desarrollar y entregar un producto de software comercializable que genere ingresos sostenibles».
Para alcanzar este objetivo, es necesario cumplir varias condiciones esenciales, entre las que se incluyen:
- Tiempo de comercialización → Entregar funciones y productos con rapidez para aprovechar las oportunidades del mercado.
- Escalabilidad futura → Garantizar que el software esté diseñado para crecer según la demanda sin comprometer el rendimiento.
- Optimización de costos → Equilibrar los gastos de desarrollo y maximizar la entrega de valor.
- Retorno de la inversión (ROI) → garantizar que el producto proporcione beneficios financieros a largo plazo que justifiquen la inversión.
Estas condiciones guiaron la forma en que definimos nuestros KPI, centrándonos no solo en la velocidad y la eficiencia, sino también en la creación de un producto escalable y rentable que aporte valor comercial a largo plazo.
Visualización del flujo: configuración de paneles
Tal como se indica en Accelerate, de Nicole Forsgren, Jez Humble y Gene Kim, nuestro objetivo era configurar un panel capaz de visualizar y realizar un seguimiento de las cuatro métricas clave de DevOps:
- Frecuencia de implementación → Con qué frecuencia los equipos implementan código en producción.
- Tiempo de entrega de los cambios → La rapidez con la que el código pasa de la confirmación a la producción.
- Tasa de errores en los cambios → El porcentaje de implementaciones que provocan errores.
- Tiempo medio de recuperación (MTTR) → La rapidez con la que los equipos se recuperan de los errores.
Sin embargo, generar estas métricas de forma significativa supuso un desafío al principio debido a la falta de un seguimiento sistemático del trabajo entre los equipos. Aquí es donde la adopción de Azure DevOps como una solución de gestión de trabajo común y única para todos los equipos marcó una diferencia considerable.
Comenzamos configurando paneles específicos para cada equipo con el fin de realizar un seguimiento de:
- Todos los elementos de trabajo asignados por equipo.
- El trabajo en curso actual.
- Trabajo completado.
- Defectos clasificados por etapa y prioridad.
Primer desafío: Uso incoherente
Incluso con directrices claras, los equipos utilizaban los estados y las categorías de defectos de manera diferente. Esta incoherencia hizo que el análisis del flujo entre equipos fuera casi imposible.
El primer desafío con el que nos 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 equipos utilizaban los estados de forma diferente, lo que dificultaba la identificación de problemas de flujo entre ellos. Lograr coherencia en la forma de realizar el seguimiento del trabajo se volvió fundamental para garantizar que los paneles pudieran utilizarse no solo para equipos individuales, sino para optimizar el flujo en toda la organización.
A continuación, nos centramos en definir adecuadamente los elementos de trabajo para garantizar que reflejaran con precisión en qué punto del ciclo de valor se encontraba el trabajo, manteniéndose lo suficientemente genéricos como para usarse en varios equipos. La mayoría de las herramientas proporcionan categorías de estado predeterminadas, pero estas no siempre eran suficientes. Era importante definir categorías de estado que se alinearan con nuestra estructura de equipo, la forma en que fluía el trabajo y nuestros cuellos de botella conocidos.
Análisis del flujo de trabajo para identificar cuellos de botella
Los primeros paneles se configuraron principalmente para visualizar el trabajo en curso y obtener una imagen clara de lo que estaba sucediendo en los equipos. Esto incluyó historias de funciones, historias de usuario, defectos y planes de prueba. Estos proporcionaron una instantánea del trabajo en curso, pero aún no ofrecían una visión clara del flujo general del trabajo y del valor.
Tener visibilidad del trabajo en curso fue un primer paso importante, pero el siguiente desafío consistió en conectar esta visibilidad con métricas basadas en el flujo que pudieran destacar dónde se estancaba el trabajo y dónde debíamos mejorar.
Utilizando el estado de los elementos de trabajo, creamos métricas para mostrar el número de elementos en cada estado. Al principio, solo disponíamos de información sobre el recuento de los elementos de trabajo en los diferentes estados. Un análisis más avanzado, como el seguimiento del tiempo que los elementos permanecían en cada estado, requirió herramientas adicionales que introdujimos más adelante. Sin embargo, en esta fase inicial, comenzamos nuestro análisis utilizando únicamente los recuentos.
Incluso con estos datos básicos, los paneles demostraron ser valiosos para identificar cuellos de botella clave:
- Demasiados elementos de trabajo en curso en comparación con el número de elementos completados en un período determinado.
- Una acumulación creciente de nuevos elementos de trabajo que superaba con creces lo que podíamos completar de forma realista en los próximos 3 a 6 meses.
- Equipos con la mayor acumulación de elementos de trabajo sin terminar, lo que indicaba dónde se necesitaba más atención y apoyo.
Cada una de estas percepciones requirió una solución diferente, pero la capacidad de visualizar el flujo de trabajo supuso un gran avance. Esta mejora impulsó aún más el aspecto de Herramientas de nuestro Triángulo de DevOps, proporcionando el ímpetu para avanzar en los otros dos aspectos: Arquitectura y Personas.
Uso de los indicadores clave de rendimiento (KPI) para impulsar la mejora continua
Volvimos a abordar el tema de los KPI en varias etapas de nuestra transformación DevOps. A medida que mejoraban nuestras capacidades de seguimiento, pudimos generar métricas más detalladas que nos ayudaron a:
- Medir el progreso a lo largo del tiempo para garantizar que avanzábamos hacia nuestro objetivo de desarrollar un producto de software comercializable.
- Identificar dependencias y transferencias que provocaban retrasos en el flujo de trabajo.
- Identificar las áreas en las que los equipos necesitaban apoyo adicional o mejoras en los procesos.
- Alinear nuestros KPI de forma más estrecha con las cuatro métricas clave de DevOps de Accelerate, proporcionando una medida objetiva de nuestro éxito.
Al alinear las herramientas, la arquitectura y las personas con los KPI adecuados, creamos un sistema que proporcionó una visibilidad clara de nuestro progreso, nos ayudó a identificar y eliminar cuellos de botella, y garantizó que siguiéramos centrados en ofrecer valor empresarial a largo plazo.
¿Qué sigue? Ramificación y despliegue continuo
Una vez establecidos nuestros KPI y paneles, ya 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 creación de ramas y el despliegue continuo, así como en los cambios culturales y técnicos que nos permitieron realizar despliegues más rápidos y seguros.
¡Manténgase atento!
