La gravedad de desestimar DevOps en los desarrollo de software

Comenzaré este escrito afirmando algo que es una premisa en la compañía que fundé hace una década: LA TECNOLOGÍA SÓLO ES ÚTIL, SI MEJORA LA VIDA DE LAS PERSONAS Es el derrotero en A&A y sus filiales.

Y en estos tiempos modernos y llenos de “Transformación Digital” ha surgido en especial una filosofía de trabajo DevOps que no ha acabado de madurar y ya se habla de DevSecOps, pero que, en cualquiera de los casos, trata de nada diferente que buscar cómo engrano todas las piezas de la máquina que fabrica productos de software de tal manera que “produzcan” de forma ininterrumpida (de ahí el símbolo de infinito para dibujar el flujo) soluciones de software que terminan en el escenario público, que en la jerga del gremio se llama Producción.

Esto aplica al interior de toda empresa de tecnología, incluídas las de Software, puesto que en casa de herrero, no puede haber cuchillo de palo; sin embargo, en muchas oportunidades caemos en el gravísimo error de incluir nuevas tecnologías, o nuevas herramientas al servicio de nuestros procesos de desarrollo y terminen siendo un adorno que, lejos está de generar el valor por el cual fueron traídas al asunto.

Y ahí es cuando los equipos de desarrollo cometen varios errores, entre los cuales sobresalen por ejemplo:

Tener plenamente identificado el ser y quehacer de cada miembro del equipo es fundamental, que el sentir personal sea, que entiende su propósito en esa creación, y por ende, sea responsable de que esto suceda. Ahí existen varios problemas que enfrentamos, en algunas ocasiones es falta de liderazgo, en otras de visión, en otras de orden, de comprensión del producto, peor aún, de malos requerimientos, mal reclutamiento y muchos otros agobian el desarrollo normal de un proyecto.

Si a esto le sumamos que, el equipo se haga dependiente de un work flow sobre el papel interesante, divertido y muy inteligente, pero nadie lo parametriza bien, nadie lo controla y nadie se asoma a ver si está funcionando como debiera, da como resultado que estas inversiones en tiempo, dinero en licencias y muchas otras cosas se vean perdidas, y que contrario al objetivo inicial, que era generar valor dentro del proyecto, termina siendo el nicho de confusión y mediocridad.

Desestimar la importancia que tiene la metodología no solo es grave, es un acto de negligencia de quien comete este “abuso”, más, si se ha planificado dentro del proyecto el utilizar buenas herramientas y tener un ecosistema robusto y confiable que permita que todo fluya como se debe.

Y ahí es cuando tener una herramienta que te permita llevar un control de versiones, CI/CD y otras tantas funciones termina siendo un juguete inútil, y no por la herramienta en si, posiblemente tampoco por el despliegue, pero si en el uso regular y frecuente no se le exprime su potencial, estamos trabajando igual que cuando se hacían despliegues subiendo vía FTP archivos para sobrescribir los cambios.

Los equipos de negocios y desarrollo han visto un cambio de los enfoques tradicionales en cascada al desarrollo iterativo: de ágil a escalado ágil y, finalmente, DevOps. Pero cambiar el enfoque de una organización desde el desarrollo hasta la entrega está lejos de ser sencillo.

DevOps es una cultura de trabajo multifuncional e infraestructura, para ofrecer valor constante a los clientes. Esto significa que el diálogo siempre debe contener personas y tomadores de decisiones de todo el negocio, no solo los desarrolladores.

Sin embargo, reunir diferentes funciones es difícil porque se completan con diferentes incentivos, personalidades, procesos, culturas. Después de la decisión inicial de ‘hacer DevOps’, es fácil para todos retirarse a sus silos y hacer lo suyo, y esta es posiblemente la razón más grande para el fracaso.

Pero, dado el ritmo del cambio, los equipos podrían ser perdonados por ser acusados ​​de no mantenerse a la par. Aunque es completamente comprensible, hay señales de advertencia que, si se identifican lo suficientemente temprano, pueden abordarse. Por ejemplo, no busque más allá de la conversación. Si las discusiones son sobre herramental e infraestructura, eso es un signo revelador. La implementación de personas específicas o la revalidación de títulos de trabajos no equivale automáticamente a DevOps.

Para cerrar este post, quiero reflexionar el rol de la cultura, las herramientas, la organización y el equipo, ya que, sin estos elementos perfectamente en sintonía, el tema no se va a llevar a buen puerto, existirán problemas en desarrollo, en pruebas, en lanzamientos, en mantenimiento y en la concepción misma del producto, el cual se va desdibujando a medida que esto se va tergiversando.

La única forma en que DevOps funcione y fluya a favor de, es precisamente sacándole el provecho a la metodología, acompañada de herramientas y de un equipo conectado con el objetivo propuesto desde el inicio, estableciendo un plan que día a día se itera y que, con la ayuda de todos los mencionados anteriormente, logran suplir las necesidades presentadas por nuestro cliente y que se traduce en entregables estables, usables y que generan valor. Si esto no se cumple, tendremos nada más que un pesebre lleno de figuritas… inmóviles.