Muchos pueden pensar a DevOps como una serie de herramientas para cambiar la forma de gestionar la operación de los sistemas y su relación con las áreas de desarrollo, mientras otros pueden definirlo como una serie de prácticas para extender las prácticas de desarrollo ágiles (SCRUM, KANBAN) hacia las áreas de operaciones. Otros, los escépticos, pueden decir que son un montón de gente loca intentando cambiar el mundo, y que obviamente fracasaran porque lo que funciona en este mundo es la previsibilidad, monitoreo y gestión de prácticas tradicionales como ITIL, y que lo propuesto por DevOps lo único que traerá es mas caos. Por último, están quienes creen que es un nuevo área de la organización IT que viene a salvarnos de todos nuestros problemas (estos últimos para mi son los mas errados).
Para mi, no es ninguna de todas las definiciones anteriores, y al mismo tiempo todas. Me gusta definir a DevOps basándome en un paper de Mandi Walls (Building a DevOps Culture), como un movimiento cultural combinado con una serie de prácticas de desarrollo de software soportadas por herramientas que juntas habilitan a un desarrollo mas rápido (o a fallar mas rápido mas seguido). Por lo que es muy importante tener en cuenta que implementar un cambio a un nivel que mejore nuestra capacidad de entregar software de calidad mas seguido no es algo que pueda ser realizado de un día para el otro, y requiere su tiempo de maduración y soporte de la organización completa (o al menos aquellas áreas impactadas).
DevOps no es algo nuevo (Patrick Debois acuñó el término en 2009, mientras organizaba la primer DevOps conference en Bélgica), sino que es un muy buen blend entre prácticas maduras con enfoques novedosos para enfrentar desafíos comunes en la entrega y operación de soluciones de software. Mezcla la visión de desarrollo (no solo los desarrolladores, sino también testers y QA) y operaciones (incluyendo no solo a los operadores, sino también a administradores de sistemas, DBA), poniendo foco en la colaboración y feedback constante para soportar la mejora contínua de la forma de trabajo.
Según cuenta Michael Hüttermann en su libro DevOps for Developers, DevOps abarca numerosas actividades y aspectos:
- Cultura: Las personas son mas importantes que los procesos y herramientas. Hay que tener siempre en cuenta que el software es hecho por personas y para personas. Debemos buscar la forma de ser felices haciéndolo, y hacer felices a los que obtienen el resultado de nuestro trabajo.
- Automatización: Es esencial obtener feedback rápido y minimizar los errores en tareas repetitivas.
- Medición: Se debe encontrar una forma única de medir, acompañado por incentivos de calidad y compartidos (o al menos alineados).
- Compartir: Es imprescindible crear una cultura en la que las personas compartan ideas, procesos y herramientas.
Hablamos entonces de cambiar la cultura de dos áreas históricamente enfrentadas (desarrolladores vs operadores) para que se vean como un único equipo (con objetivos alineados), compartiendo información y apoyados en la medición continua y automatización de tareas que no aportan valor para mejorar el día a día de su trabajo, y paso a paso, como diría el Tolo Gallego.
¿Como podemos entonces emprender este cambio cultural para poder trabajar mejor? Debemos enfocarnos en generar una nueva cultura, con base en los siguientes pilares:
- Comunicación abierta, donde nadie tenga miedo a participar y decir su opinión, y donde la decisiones sean tomadas de manera global, con responsabilidad compartida entre todos. Basta de ocultar información para sacarse de encima problemas.
- Incentivos alineados, tal como lo comenta Michael Hütterman y tal como lo nombré en párrafos anteriores.
- Responsabilidad alineada. Debe quedar en claro que la responsabilidad de un área no termina cuando culminó su porción de tarea y la pasó la pelota al siguiente pipe en el pipeline de desarrollo. La responsabilidad de todos los involucrados termina cuando se alcanzó el nivel de aceptación acordado entre TODOS.
- Respeto. Todos deben respetarse. Puede ser que no se quieran (ya eso va de la mano de los sentimientos de cada uno), pero es vital que cada uno reconozca el valor del otro en el pipeline completo.
- Confianza. Esto si es realmente desafiante. Los desarrolladores deben confiar en que lo que los encargados de operaciones les indican sobre el funcionamiento en producción, y estos últimos deben confiar en que lo que desarrollo produce es lo mejor dadas las circunstancias, y trabajar en conjunto para llegar a los objetivos planteados en conjunto.
Tenemos que tener en cuenta que algo es seguro: No es posible refactorizar una persona o resetearla tal como lo podemos hacer con las aplicaciones o los servidores. Se trata de un cambio interno de las personas, y debemos encontrar la forma de trabajar con los pre-conceptos, experiencias pasadas y prejuicios, para transformar la energía negativa actual en el combustible del cambio.
0 comentarios:
Publicar un comentario