Desarrolladores e Ingenieros a cargo de operaciones de diseño y proyectos software tienen una relación compleja en la que, en muchas ocasiones, se genera una lucha sobre quién domina a quien o sobre quién debe liderar y protagonizar el ciclo de proyectos de ingeniería de software.
Las técnicas de DevOps se han ofrecido como panacea a la complejidad de creación y mantenimiento de múltiples proyectos en un equipo de creación de software. Como es habitual con las píldoras mágicas, no es oro todo lo que reluce, y las buenas técnicas con deficientes gobernanzas son un seguro de fracaso y frustración.
Las primeras dificultades del DevOps se detectan a nivel humano. La creación de nuevos de circuitos de trabajo e interacción requieren cambios de actitud en los participantes. Este factor humano y la gestión de equipos se suele obviar o minusvalorar y se ha convertido de facto en el principal escollo para el DevOps.
Unir fuerzas entre personas que no han trabajado juntos o incluso han sido «rivales» dentro de una organización no es algo baladí. La cooperación debe ser punto focal incluso antes de diseñar cualquier idea de integración entre desarrolladores e ingenieros de software. El factor humano y cultural son por tanto claves en un proyecto DevOps.
Síntomas de que DevOps está fracasando
Existen síntomas claros que indican que la aproximación al DevOps de un equipo o un proyecto está fracasando.
1.- El mal ambiente es quizás el más evidente. Si se observan malas relaciones entre desarrolladores y personal de operaciones seguramente los procesos marcados no se estén llevando a cabo correctamente.
«…si detecta a parte del equipo retomando antiguas prácticas podemos asegurar que en poco tiempo volverán al 100% a las costumbres anteriores»
2.- Quizás el síntoma más habitual es la recuperación de viejas prácticas, en cuanto se detecte que parte del equipo está retomando algunas antiguas formas de proceder podremos asegurar que en poco tiempo se volverá al 100% a las costumbres anteriores al modelo DevOps que se desea. Esto suele suceder cuando los participantes encuentran dificultades y en lugar de porfiar en su resolución desandan el camino hacia las viejas prácticas. Algo muy común.
3.- Infra-estimación del tiempo de aprendizaje. Las personas necesitan tiempo y motivación para desarrollar procesos de cambio. Es fundamental, establecer periodos de transición y métricas de control con fechas y fases claras para digerir los cambios en la forma de desarrollar el Software.
4.- Conseguir valedores o sponsors populares en los grupos de desarrolladores y en el de los ingenieros de software es vital. Hay que encontrar a aquellos que más reconocidos sean por sus conocimientos y habilidad en sus funciones y atraerles hacia la dirección del proyecto DevOps. Tener a los «gurus» internos en contra de un cambio de modelo es una bomba de relojería que nadie quiere tener en sus manos.
5.- Mostrar los beneficios a corto, medio y largo plazo tanto a nivel individual como colectivo. Es otro de los grandes catalizadores del éxito. Sin mostrar el premio en sus múltiples facetas, es más difícil que el equipo prospere.
DevOps y las herramientas que lo tangibilizan son sin duda un camino de éxito, control, reutilización, y mantenimiento ágil del software desarrollado por cualquier empresa o división. Pero adopciones exitosas del modelo conviven con verdaderos fracasos no deseados. El camino empieza por la gente y sigue por la tecnología, los procesos y las normas de trabajo en equipo. La tenacidad en esta vía diferencia a los «challengers» de los que que conquistan su objetivo.