¿Por qué quiero realizar una evaluación de DevOps?
Sara, QA lead de un gran banco, intenta analizar el último resultado de las métricas que su organización utiliza para calcular su grado de madurez en DevOps.
Se da cuenta que su organización se encuentra en el rango de Medium para “Deployment frequency” y “Change failure rate”, y Low en “Lead time for changes” y “Time to restore service”.
Se pregunta qué cosas puede hacer ella y su equipo para mejorar esta situación, realiza una lista:
- Generar datos de prueba para todos los entornos y automatizar su actualización/promoción.
- Automatizar las pruebas más costosas/repetidas.
- Definir un proceso de pruebas contínuas.
- Empoderar a los equipos para realicen ellos mismos sus pruebas.
- Definir, crear y automatizar pruebas end2end.
Al cabo de 6 meses, y con todas estas tareas realizadas, espera que las métricas DevOps hayan mejorado, pero desafortunadamente siguen iguales, no ha cambiado nada.
¿¡Por qué!? Se pregunta Sara, frustrada. Entonces decide llamarme y explicarme la situación.
En un primer momento me quedo asombrado, la verdad es que después de todas las acciones realizadas por Sara y su equipo, conociendo lo profesionales y capaces que son, y con lo acertadas que parecen, uno estaría convencido de que los resultados globales de la organización tendrían que haber mejorado. Pero no ha sido así.
Creo que voy intuyendo el porqué, pero no estoy seguro, y le sugiero a Sara que proponga a su organización realizar una evaluación de DevOps, de esta forma podrá ver en que estado se encuentran los distintos dominios/áreas y posteriormente evaluar cuál es el estado de la organización, para posteriormente evaluar cuales tienen que ser las próximas acciones por tomar para maximizar el resultado.
Una vez realizada la evaluación de DevOps, tal y cómo imaginaba, se puede ver que el área de “Continuous Testing” es uno de los más desarrollados.
Eso explicaría porque las mejoras en el área de Sara no han implicado ninguna mejora visible para la organización.
“Any improvements made anywhere besides the bottleneck are an illusion.”
― Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
Tal y cómo explica Gene Kim en su libro “The Phoenix Project”, si mejoramos el sistema, pero no eliminamos sus restricciones/cuellos de botella, no conseguiremos mejorar sus resultados.
Tal y cómo muestra la evaluación, la organización tiene buenos niveles de “Test Automation” y “Test Environments & Data” además de otras dimensiones, pero tiene algunas áreas que podrían ser una restricción, cómo podría ser el “Team Structure & Operating Model”, “Development Environments & Data”, “Developement Practices” o “Release Strategies”.
En conclusión, la organización debería priorizar la mejora de esas áreas para ver mejorar las métricas de DevOps.
Para ayudar a lograr ese propósito, sería conveniente listar, estimar y priorizar iniciativas que maximicen la posibilidad de lograr los objetivos de la organización y volver a realizar evaluaciones DevOps de forma periódica, para realizar un proceso de mejora continua.
En definitiva, quiero realizar una evaluación DevOps para saber que iniciativas debo llevar a cabo para mejorar la calidad y la velocidad de la forma más eficiente y segura.
Autor del artículo
Marçal Nebot, senior specialist (DevOps/Agile)
