Hace más de 5 años, me preguntaba aquello de “¿Por qué lo llaman DevOps cuando quieren decir sentido común?” y la verdad es que sigo con la duda porque me sigue sorprendiendo que a día de hoy sigamos teniendo que justificar el por qué es bueno la colaboración entre los equipos de trabajo.
Porque, básicamente, DevOps es eso: una forma de colaborar entre equipos o, más bien, de trabajar juntos, formando parte de un todo.
Evidentemente, esto en muchas compañías, acostumbradas a trabajar en silos y donde cada uno mira por sus propios intereses, es complicado de implantar, porque ya sabemos de nuestra aversión al cambio.
El problema no está en los silos en sí, sino entre la colaboración entre esos silos.
Además, DevOps está muy relacionado con el área tecnológica, donde aquí suele haber 2 grandes silos: los de desarrollo (programación, aplicaciones, software, llámalo como quieras…) y los de operaciones (infraestructura, sistemas, hardware o como sea) que llevan año siendo “enemigos”, cada uno mirando por lo suyo.
Así que ahora, en los tiempos de desarrollo e integración continua (CD/CI) no queda más remedio que buscar una solución a este problema, toca aplicar el sentido común y colaborar.
Y de cómo aplicar todo esto en nuestros entornos SAP es de lo que nos hablan en el curso de openSAP “Efficient DevOps with SAP”, que es de donde he sacado las imágenes que veis en este artículo.
En la primera semana hacen hincapié en que todo esto es, principalmente, un tema de cultura empresarial, más que de herramientas y que todo se basa en un valor principal: LA CONFIANZA.
Y esta se puede conseguir, teniendo en cuenta 3 variables: tamaño del equipo, diversidad del mismo y seguridad aportada.
Ya sabemos que muchas veces, el meter más gente cuando algo se “atasca” más que una solución termina siendo un problema.
O que si el equipo está formado por gente que tiene una misma forma de pensar y no se admiten otros puntos de vista, la opinión del mismo está totalmente sesgada.
Y, por supuesto, debemos tener cierta tolerancia al fallo. Si nos equivocamos rápido, tendremos margen de maniobra para corregir ese error.
Me gusta también el concepto de que todo esto se basa en la calma. Concretamente, en el acrónimo CALMS:
- Culture: si no cambio mi cultura, no hay nada que hacer.
- Automation: las tareas repetitivas no aportan valor.
- Lean: fuera lo innecesario, vivimos en un ciclo de mejora continua.
- Measurment: sólo puedes mejorar lo que se mide.
- Sharing: el equipo y la colaboración es clave.
Después de esa primera semana de “concienciación” entran en materia sobre cómo aplicar todo esto en los desarrollos ABAP, principalmente en todo los temas relacionado con trasportes entre los distintos entornos, que nos permiten hacer un desarrollo e integración continua, manteniendo la seguridad y la integración de nuestros sistemas.
Entonces, ¿eso de tenga que pasar un mes para que una orden de desarrollo llegue a producción se ha terminado? Me temo que no, que no será algo que cambie de hoy para mañana, pero es evidente que tu forma de trabajar tiene que adaptarse a los tiempos que corren.
Así que deja de “pelearte” con tus compañeros de desarrollo/operaciones y poneos a trabajar con sentido común… 😉
