¿Qué busca una organización cuando transforma su forma de operar, organizarse y colaborar hasta ‘sentir’ haber adoptado DevOps? ¿Cuándo se percibe haber llegado a ese nivel de madurez y cómo se llega al mismo? Lo que todas las organizaciones pretenden conseguir se puede resumir en los siguientes objetivos:
- Entendimiento compartido de necesidades y objetivos entre los propietarios del producto o servicio y los equipos de desarrollo, operaciones y mantenimiento, incrementando la interacción y colaboración.
- Desarrollar sin tiempos de espera o sobrecostes, proporcionando a los desarrolladores una plataforma para codificar, construir y probar bajo demanda con todos los elementos necesarios y dotada de independencia.
- Probar inmediatamente con la mayor cobertura de escenarios posible y de forma independiente, automatizada y repetitiva si es necesario. Reduciendo al mínimo que sea que el usuario final descubra o sufra fallos, con su correspondiente impacto negativo.
- Desplegar cambios o nueva funcionalidad frecuente, ágil y fiablemente, poniendo a disposición de cada tipo usuario el cambio en tiempo y forma para que obtenga valor del mismo.
- Monitorizar y recopilar información del proceso extremo a extremo y de cada una de sus etapas. Desde el número de funcionalidades incluidas por versión hasta el nivel de uso que se realiza por los usuarios finales de las nuevas funcionalidades, pasando por el nivel de uso de infraestructura por etapa o la identificación de vulnerabilidades.
- Analizar y reaccionar para remediar vulnerabilidades identificadas, descubrir tendencias de uso y actuar en consecuencia.
En definitiva, disponer de la capacidad de satisfacer la demanda de los propietarios del servicio o aplicación al ritmo que necesiten, eficientemente y con fiabilidad. En mi experiencia, este ritmo se percibe cuando se dan al menos dos factores.
El primer factor se basa en calcular el ratio de ‘éxitos rápidos’ (Quick Wins) incluido en cada versión de producto liberada, frente al número de éxitos rápidos pendientes de construir. Un éxito rápido podría definirse como una característica funcional o técnica de la aplicación o servicio cuyo valor es considerado medio-alto y el esfuerzo para llevarlo a cabo es medio-bajo.
El segundo factor es que los diferentes roles o perfiles que típicamente pertenecen a departamentos bien definidos como negocio, desarrollo, calidad, operaciones, recepción de aplicaciones, etc., colaboran coordinadamente o incluso están incentivados, para que el valor del primer factor sea uno o menor que uno. Cuando una organización mantiene el ratio anterior en un valor inferior o igual a uno por producto, es que está liberando nuevas características clave al mismo ritmo que se van generando, y además el entendimiento de éxito rápido y la colaboración para discernir las características que lo cumplen es común y consensuado entre los distintos perfiles denotando la madurez referida.
También es obvio que la misma transformación requiere de adquirir habilidades y cambiar procesos y cultura
Es obvio que la transformación descrita está condicionada por la tecnología, y en mi experiencia, uno de los mayores aceleradores de esta transformación es el concepto Plataforma Como Servicio (PaaS en Inglés) y en particular la implementación de Red Hat con su solución Openshift, que facilita la mayoría de los objetivos descritos anteriormente, simplificando los procesos y el uso coordinado de múltiples herramientas de desarrollo y operación.
También es obvio que la misma transformación requiere de adquirir habilidades y cambiar procesos y cultura, y para ello, recomiendo apoyarse en una experiencia inmersiva como la que propone Red Hat con sus ‘Open Innovation Labs’, que permiten vivir esa transformación de forma didáctica y práctica aplicando el modelo 70/20/10, según el cual un 70% de los conocimientos vienen de la ‘experiencia en la tarea’, un 20% de lo aprendido de otros y el 10% restante de formación tradicional.
