¡CONTENIDO BLOQUEADO!
Aquí hay un vídeo que no puedes ver debido a tu configuración de cookies.
Puedes ver nuestra política de cookies o abrir el vídeo en youtube.com
En el encuentro organizado por Inetum y CloudBees, en el que Computing ejerció de maestro de ceremonias, y al que asistieron técnicos de Acciona, Banco de España, BBVA, Cepsa, Mapfre y Sacyr, se puso sobre la mesa la vieja ‘pugna’ existente entre los mundos de negocio y de tecnología al afrontar proyectos de desarrollo de aplicaciones con eficacia y agilidad.
María Jesús Larraya, directora de Arquitectura de Desarrollo de Inetum, constató esta problemática: “Como integradores, en algunos casos nos sorprendía que dentro de una misma compañía hubiera muchas discrepancias entre negocio y tecnología”. En consecuencia, consideró al respecto que “los equipos de desarrollo deben evolucionar para facilitar la puesta en producción de una respuesta acorde a las nuevas necesidades del cliente. Es necesario instalar en las organizaciones una cultura DevOps, pero es un camino largo, y hay que buscar el entendimiento con el negocio; TI debe ser un habilitador de este cambio”.
El reto es cómo alcanzar este entendimiento y cómo engranarlo dentro de la organización. Así quedó explicado: “El movimiento DevOps que nace desde abajo, de la parte técnica, persigue un cambio cultural. Pero reconocemos nuestras carencias para liderar, como técnicos que somos, aunque tenemos la capacitación de ayudar a cumplir con las métricas, mejorar procesos y adaptar buenos patrones y buenas prácticas”. Hay herramientas de desarrollo (como CloudBees) y un modelo Agile que pueden impulsar este cambio y culminar en la entrega de productos “pensando en la experiencia del desarrollador y del cliente final”.
Un experto veterano en estas lides comentó que “siempre estamos a vueltas con el cambio cultural, pero opino que los cambios culturales no se imponen”. No existe esa piedra filosofal que va a arreglar todo. “Las herramientas son habilitadoras, pero no solucionan los problemas, es algo que no tenemos interiorizado en el día a día”. El cambio cultural, concluyó, tiene que ir calando, y no estar supeditado a personas que asumen un papel de ‘megalisto’ desde sus tarimas de seguridad o calidad. Para otro interlocutor, lo importante es “levantarse de la silla y propiciar la comunicación entre las áreas”. Y romper las fronteras, especialmente si vienes de una empresa tradicional donde abundan los silos: “Si tienes un departamento de seguridad, otro de desarrollo y otro de DevOps, por fuerza ya tienes tres silos”. Otro aconsejó salir de la “zona de confort y no ser tan especialistas y sí más transversales”.
Automatizar y normalizar
En este proceso de transformación, los reunidos consideraron la necesidad de estandarizar, normalizar y mostrar el valor que supone “no solo para los equipos de negocio sino también para el equipo de desarrollo, que puedan sacar un valor medible y tangible”.
Una idea que se recalcó es que la tecnología tiene que ser la palanca que ayude a simplificar DevOps y adoptar una manera distinta de colaboración, “no por tener una herramienta tienes DevOps, debe ser la base para poner en marcha un mecanismo y poder trabajar de una forma homogénea y sostenible”.
DevOps no cuenta con un manifiesto como Agile, pero se basa en unos presupuestos básicos: la colaboración, la transparencia y la comunicación, fruto de los cuales se puede conseguir que los equipos adopten de una manera más natural y proactiva este sistema.
Desde una de las aseguradoras se decidió montar un equipo multidisciplinar en el área de DevOps, de infraestructura, de gobierno, metodologías, desarrollo, seguridad… y después de tres años se ha conseguido “ese sentimiento de equipo” en el que todos suman y que les ha permitido mayor velocidad en puntos que les pedía la compañía en torno a soluciones core; otros han pasado a una segunda velocidad, pero que se han retroalimentado y se han visto a su vez impulsados.
Otro aspecto interesante es que DevOps es fácil de asimilar en entornos pequeños, pero en grandes escalas se complica, por eso algunas compañías prefieren partir de equipos reducidos que van madurando y ayudando a su vez a otros equipos. “Cuando el tamaño importa es muy importante adoptar una cultura industrial de automatización, eficiencia e inventario”. La trazabilidad entra en juego especialmente en el mundo del cumplimiento, que tanto condiciona a las empresas financieras y de seguros. “No es tan evidente saber dónde tengo mi software, dónde están mis activos, o cuántos hackers han entrado en mi datacenter”.
Para conseguir esta trazabilidad en el desarrollo de las aplicaciones es importante contar con la complicidad del área de negocio. “Resulta muy difícil entenderse con negocio, pues utilizamos lenguajes y sensibilidades diferentes. Hemos intentado involucrarlo en el ciclo de desarrollo y que lo ‘sufran’ para que comprendan lo que supone dar una vuelta más a un proyecto y decidan con mayor conocimiento de causa”. Según explicó el técnico de una entidad bancaria presente: “Este movimiento lo hemos aplicado en las primeras fases del proyecto, desde cómo se idea y cuantifica, de la manera más transparente posible, con un lenguaje lo más accesible para que se pueda entender por la gente de negocio”.
La segunda fase de esta búsqueda del entendimiento reside en trabajar de forma conjunta para “saber lo que se quiere”. Una cosa es construir una solución de software que esté bien y otra es que sea la solución adecuada. De la misma manera, hay aplicaciones antiguas que funcionan a medias y el negocio “no te permite ni tocarlas”. Y es en ese modelo de conversación entre las dos áreas cuando se unen sensibilidades y mejora la visión común de las cosas.
En último término, toda cultura no se entiende de la misma forma. “DevOps es un concepto general que cada uno lo aplica como quiere. Es importante dar autonomía a los proyectos para que puedan progresar y no nos perdamos en un ciclo constante de cambios y problemas. Y, al final, algo tan positivo como DevOps termina degenerando en un hándicap para la organización”.
