¿Sus equipos de desarrollo realmente adoptan DevOps o simplemente siguen la corriente? Aprenda a detectar las señales de advertencia de ‘DevOps Kabuki’.
No hay duda de que DevOps ha ayudado a muchas organizaciones de TI a lograr su objetivo de entregar aplicaciones y servicios más rápido y mejor que los procesos tradicionales de desarrollo de software. Desafortunadamente, mientras que algunos líderes de TI hacen un buen trabajo pregonando los beneficios de DevOps, sus equipos van en la dirección equivocada, adoptando herramientas y prácticas a medias o completamente equivocadas.
Es responsabilidad del CIO asegurarse de que los equipos de desarrollo no se desvíen intencionalmente -o sin intención- del camino de DevOps. Estas son las siete señales de advertencia que le alertarán sobre la posible presencia de DevOps falsos en su organización.
- Colocar DevOps en un silo
La primera señal de una implementación falsa de DevOps se puede detectar fácilmente, simplemente viendo un organigrama. «Si encuentra DevOps en su propio silo, separado de Ingeniería y Operaciones, es una señal inicial de que su responsabilidad de DevOps no está allí”, afirma Fernando Cuadra, consultor principal de la firma de asesoría e investigación tecnológica, ISG. «Al crear un equipo de DevOps separado, el CIO esencialmente ha agregado otra capa de complejidad, otro silo y otro paso que administrar”.
El organigrama debe reflejar un diseño que permita a los equipos resolver problemas de manera integral en todas las áreas relevantes. «Opte por crear equipos multifuncionales de principio a fin, desde Diseño hasta Operaciones”, aconseja Cuadra. «DevOps no se trata de pipelines y CI/CD; se trata de ser dueño de su entrega de valor con una fricción mínima en toda la empresa”.
DevOps es solo una herramienta en lo que debería ser una conversación mucho más amplia sobre el lado humano de la tecnología, observa Cuadra. «Requiere una comprensión profunda de los componentes básicos de los equipos de alto rendimiento, y cómo los CIO pueden refrescar su percepción de cómo se ven los equipos muy funcionales”.
- Centrarse en las herramientas por encima de las personas
Una organización que se enfoca en una cultura DevOps centrada en herramientas y tecnología, en lugar de personas y procesos, está 180 grados fuera de sincronía. «Es crucial evaluar las prácticas y necesidades de negocio actuales”, afirma Mohan Kumar, arquitecto senior de TEKsystems, una empresa de administración de servicios de TI.
Kumar recomienda priorizar los equipos. «Inculque la cultura DevOps en la comunicación, la colaboración, la recopilación de comentarios y el análisis”, sugiere Kumar. «Un ambiente amigable con los experimentos, que permite a los desarrolladores fallar rápido, recuperarse rápido y aprender más rápido, crea una cultura libre de culpas dentro de la organización”. Kumar también sugiere fomentar un flujo de ideas creativas aprovechando la inteligencia colectiva de los equipos.
La adopción de DevOps es un proceso iterativo, por lo que el CIO debe comenzar evaluando el estado actual del equipo de desarrollo y luego construir gradualmente una estrategia de mejora continua que involucre personas, procesos y herramientas que puedan evolucionar junto con las necesidades y desarrollos futuros. «En última instancia, la creatividad es un músculo que debe ejercitarse continuamente para crecer”, observa Kumar.
- Muy poca automatización
Las DevOps falsas pueden ocurrir cuando los líderes de los equipos carecen de una mentalidad de automatización, particularmente la capacidad de invertir el tiempo y los recursos necesarios para construir una arquitectura sólida con entrega de código automatizada.
Antes de seguir adelante con una iniciativa de automatización, considere cuidadosamente las necesidades de desarrollo, los contratos existentes y los equipos de proyecto actuales. «Vea si las habilidades de la organización están al nivel en el que puede automatizar la infraestructura”, afirma Ian Fogarty, director general de tecnología y operaciones de la consultora Accenture Federal Services.
Sin embargo, la automatización puede ser un arma de doble filo. Kumar observa que es muy fácil cambiar involuntariamente de procesos manuales defectuosos a procesos automatizados defectuosos. Aconseja resistirse la tentación de automatizar tanto como sea posible. En su lugar, automatice tanto como sea razonable. El objetivo final, señala Kumar, debería ser convertir las versiones de software en un proceso de implementación automatizado, confiable y repetible.
- Automatización al azar
Aunque la automatización es muy beneficiosa, muchas organizaciones se lanzan a la automatización de DevOps sin suficiente análisis y planificación. «Hemos visto organizaciones que dan prioridad a la automatización sin tener en cuenta otros aspectos, como la gobernanza, las personas, los procesos y la tecnología”, afirma Aaron Oh, director general de DevSecOps en Deloitte Risk & Financial Advisory. Estas organizaciones generalmente terminan perdiendo una cantidad significativa de tiempo revisando y arreglando el trabajo de automatización.
Antes de pasar directamente a la automatización, Oh sugiere establecer una gobernanza sólida y estandarizar los requisitos y procesos. «La colaboración entre las unidades de negocio es una parte esencial de DevOps”, señala Oh. Aborde cualquier barrera organizativa que pueda existir. «La orientación del liderazgo va a ser importante para establecer el tono”, afirma Oh. «Además, aproveche las herramientas de orquestación inteligente para ayudar a eliminar aún más los silos y lograr eficiencia en la comunicación”.
- Tener expectativas poco realistas
Los líderes tecnológicos senior deben centrarse en un compromiso que se extienda más allá de la simple introducción de nuevas herramientas y prácticas tecnológicas. «Necesitan priorizar una cultura cambiante y la mentalidad de los empleados”, afirma Tim Potter, director de Deloitte Consulting. «También deben establecer plazos realistas para que la transformación arraigue en la organización”.
Una organización que simplemente implementa más herramientas automatizadas y cambia el nombre de los equipos de Aplicaciones existentes a «equipos DevOps”, comprometidos con los problemas de producción de principio a fin, probablemente se sentirá decepcionada con los resultados, explica Potter.
Los líderes tecnológicos también deberían estar dispuestos a aceptar el hecho de que, después de comprometerse con DevOps, la producción puede disminuir inicialmente antes de mejorar. «Deben estar preparados para brindar ‘cobertura aérea’ a sus equipos de Aplicaciones, permitiéndoles probar y aprender y sentirse cómodos operando en un nuevo modelo”, aconseja Potter. «Establecer expectativas inapropiadas y no proporcionar suficiente tiempo para la transformación puede llevar a las organizaciones a adoptar DevOps solo en nombre”.
- Equipos estancados en el pasado
Los viejos hábitos tardan en morir. Durante décadas, el desarrollo de software siguió la metodología tradicional en cascada, un proceso que exigía recopilar requerimientos con anticipación, crear funciones y, finalmente, enviar los resultados al control de calidad y otros equipos para su lanzamiento, afirma Ashish Kakran, director de la firma de capital de riesgo de TI Thomvest Ventures. «Solía pasar meses antes de que los clientes vieran las funciones nuevas”, señala.
Cuando los equipos de desarrollo no logran salir por completo de la cascada, terminan con extrañas combinaciones de procesos que pueden describirse como «cataratas ágiles”, afirma Kakran. «Indica que no se ha realizado un movimiento completo para aprovechar los últimos avances en el desarrollo de software”.
Kakran sugiere que una manera rápida y fácil de detectar un equipo con dificultades es examinar sus «Epics” y «Stories” de DevOps.
«El contexto completo de un proyecto en curso a menudo se captura en estas tareas”, explica. «Si siente que el proyecto de un mes ya está dividido en tareas con poca o ninguna retroalimentación continua de los clientes, es una señal de que el equipo se está preparando para el fracaso, ya sea por no cumplir con los plazos del proyecto o por no brindar experiencias de usuario útiles”.
- Inflexibilidad
DevOps no es una metodología única para todos. Para obtener la máxima eficacia, los flujos y las herramientas de DevOps deben ajustarse a las necesidades específicas de la organización, que pueden variar ampliamente según su tamaño, tipos de aplicaciones y experiencia en desarrollo.
DevOps nunca debe ser estático. Los procesos y las herramientas deben adaptarse a medida que la organización crece y sigue su búsqueda de mejora continua. Estos objetivos requieren herramientas flexibles, así como la capacidad de analizar los KPI para revelar oportunidades de mejora, afirma Wing To, vicepresidente de Ingeniería de Digitial.ai, que comercializa una plataforma DevOps basada en inteligencia artificial. Los líderes de TI también deben tener en cuenta el cambio cultural necesario para unir a los equipos de Desarrollo y Operaciones. En lugar de crear un departamento de DevOps separado, que solo crea más silos y cuellos de botella en los procesos, la metodología debe integrarse en cada área comercial.
DevOps se trata básicamente de personas y procesos. Los líderes de TI deben comprender que estos recursos deben ser específicos de acuerdo al contexto. «La forma óptima de usar las herramientas y los procesos cambia con el tiempo, es dinámica, no estática, y las herramientas y los procesos necesitan un entrenamiento cuidadoso para usarlos correctamente”, señala To.
Llegar a un equilibrio
Hay un equilibrio entre empujar y jalar que se debe lograr cuando se lanza una transformación DevOps exitosa. «Si tiene suerte, los equipos entusiastas se ofrecerán como voluntarios para estar entre los primeros en realizar la adopción”, afirma Potter. «Es importante apoyar a estos equipos –recompensarlos por su coraje y celebrar su éxito, mientras que al mismo tiempo se mantiene el enfoque en la hoja de ruta de transformación de toda la organización”.
Recuerde, sin embargo, que los beneficios serán limitados y tardarán si toda la organización no acepta la transformación. «Inevitablemente, habrá interdependencias que reducirán la velocidad de un equipo de Aplicaciones si la organización en general no ha hecho el cambio”, afirma Potter.
Basado en el artículo de John Edwards (CIO)
Spanish 
English