Devops con Scrum ¿Merece la pena? • Jeronimo Palacios

Durante los últimos cinco años, cada vez son más los que han ido apostando por acercar el desarrollo y las operaciones de IT, aunque sigue siendo una asignatura pendiente en las grandes organizaciones. Cuando hacemos Scrum, ¿merece la pena DevOps?

En primer lugar, ¿Qué es DevOps?

DevOps es un movimiento. Una cultura. No es una metodología o una herramienta específica. Para entender el movimiento DevOps, hay que remontarse a cómo se han hecho las cosas en el mundo del desarrollo de Software.

Hace muchos años, había una clara división entre aquellos que desarrollaban software y aquellos que se encargaban de poner el software en producción y mantenerlo. Además, existía un tercer sector: calidad -aquellos que se aseguran de que el software cumple con lo que se espera-.

La división venía de la cultura de producción industrial. Al fin y al cabo, en España, informática es una ingeniería y se enseña siguiendo los mismos modelos que se siguen en ingenierías clásicas. Además, esto permitía que no todo el poder recayera en un sólo grupo que pudiera secuestrar todo el proceso en una organización. Las metodologías en cascada contribuyeron a este proceso dividido.

Al fin y al cabo, tiene todo el sentido del mundo. Primero diseño lo que voy a hacer, luego lo planifico, lo desarrollo, lo pruebo y lo pongo en producción. El problema es que hacer software tiene una ligera diferencia con hacer cacerolas en una fábrica. Mientras que cuando hacemos producción industrial siempre producimos lo mismo y podemos optimizar procesos, cuando hacemos software siempre hacemos algo distinto y además no tenemos muy claro lo que queremos conseguir.

Las cosas cambiaron. Nuevos métodos como XP, Crystal y Scrum irrumpen en el mercado. Hay un manifiesto ágil que no hace sino reconocer la complejidad del desarrollo de software y que el proceso en cascada directamente no es válido por su diseño.

DevOps es un movimiento que irrumpe en los últimos años, promoviendo que el desarrollo de software se haga orientado a operaciones, y que los ingenieros que trabajan en uno y otro colaboren para facilitar la puesta del software en producción.

DevOps y Scrum, el matrimonio perfecto

El objetivo de un equipo Scrum es entregar un incremento de producto terminado al final de cada Sprint. La única manera de conseguirlo es mediante la integración de negocio, desarrollo, calidad y operaciones en un mismo grupo, en equipos pequeños, autoorganizados.

Este modelo de organización es el que resulta muy difícil de aceptar para organizaciones que se han construido a sí mismas en torno a pequeños reinos de taifas donde el poder es lo más importante. El poder se mide en dos variables: gente a tu cargo y presupuesto que manejas.

Cuando una organización grande plantea modelos de trabajo más o menos ágiles, se enfrenta a la disyuntiva. No se puede ser ágil si tu organización obliga a unos procesos lentos y pesados por diseño. No solamente DevOps y Scrum son el matrimonio perfecto, sino que además no queda otra manera de hacerlo.

Igual alguna vez has escuchado la frase: Nadie ha sido nunca despedido por contratar a IBM. Esta frase implica mucho más en la cultura de desarrollo de productos y proyectos de lo que pueda parecer en principio. Las consultoras han sido las más interesadas en que movimientos como DevOps o Scrum no salgan adelante. En el caso del primero porque Operaciones era muy importante para dejarlo a cargo de una máquina. En el segundo porque Scrum no es potente para abordar proyectos complejos. Eso, unido a una ignorancia de como funcionan los ciclos de vida de desarrollo de software en los altos niveles, ha llevado a una pérdida de ventajas competitivas para las organizaciones.

¿Y que beneficios me aporta DevOps?

En el informe de Puppet Labs de 2016 «The state of DevOps report» hay algunos datos interesantes. Las organizaciones que incorporan DevOps:

Despliegan 200 veces más frecuentemente que las que menos
Tienen unos tiempos de entregan 2,555 más rápidos
Tiempos de recuperación 24 veces mejores y 3 veces menos errores provocados por cambios
Los equipos IT de alto rendimiento pasan un 50% de tiempo menos resolviendo incidencias de seguridad
Y un 22% menos de tiempo resolviendo errores y problemas.

Este es el link para descargar el informe completo.

The Phoenix Project

Si tienes interés en leer más sobre DevOps y además pasar un rato muy entretenido leyendo una novela excelentemente escrita sobre un proyecto IT, te recomiendo que compres «The Phoenix Project». A través de la visión de un gerente de operaciones, describe cuales son los puntos de fricción más importantes en su compañía y cuales han sido los pasos que le han llevado a implementar DevOps con éxito.