Las ventajas de DevOps y sus metodologías de trabajo

Todos hemos escuchado alguna vez que con DevOps mejoraríamos nuestros tiempos de entrega, se desplegará más veces a lo largo del día y reduciremos el tiempo dedicado a solucionar errores y problemas.

Pero antes de adoptar esta forma de trabajo y ponernos manos a la obra, nos pararemos a pensar: ¿Cómo asumimos los cambios para que los diferentes equipos (Desarrollo, Sistemas y QA) puedan confluir y llevar a cabo dicha cultura? Pues bien, de todas las formas y maneras posibles tendremos que utilizar una u otra, o puede que quizás algún equipo tenga que ser como el camaleón que se adapte a ello.

Scrum o Kanban ¿con cuál me caso?

Puede parecer sencillo cuando son uno o dos equipos los afectados, pero cuando este número crece hay que tener claro que cada uno tiene sus tiempos (aparte de sus “ceremonias” realizadas) al adaptarse a una metodología u otra.

Pero si cuentas con varios equipos de desarrollo con sus correspondientes QA (los cuales se aseguran de reducir los posibles errores y problemas), ¿qué haces si tienes un único equipo cross de Sistemas? Estos, además de mejorar la infraestructura para seguir cerca del fin DevOps reduciendo tiempos en temas de despliegues, tienen que dar soporte a los equipos ante las posibles necesidades que les surjan en el día a día.

En este caso, puede llegar a nacer el híbrido conocido como ScrumBan. Pero…¿qué es esto de Scrumban? Se podría decir que Scrumban es (definición de Kanban Tool):

“Scrumban combina las mejores características de ambos métodos. Reúne la naturaleza preceptiva de Scrum y la capacidad de mejora del proceso de Kanban, permitiendo a los equipos moverse hacia el desarrollo Agile y a mejorar constantemente sus procesos”

El equipo de sistemas (el cual siempre ha estado más enfocado a Kanban) podría hacer la función que antes mencionaba de camaleón y que así se ajustara perfectamente a los tiempos de Scrum de los diferentes equipos para poder desbloquear posibles problemas, cuyas historias entrarían por la parte de Kanban.

Sin olvidar un foco común ( que es lo que ofrece Scrum con su backlog) para aportar valor en el cliente a través de mejoras en la infraestructura, y gracias a las herramientas de CI/CD llegar en conjunto a reducir los tiempos de entrega.

DevOps involucra a todos los equipos en desarrollo del software mejorando la calidad

DevOps is love, DevOps is life

Gracias a la cultura/filosofía DevOps no tiene por qué ser el equipo de sistemas el encargado de llevar el software a producción, puesto que con un trabajo conjunto y bien organizado gracias a las herramientas que existen a día de hoy, un equipo de Desarrollo puede desplegar en producción, siempre y cuando se cumplan los estándares estipulados con sus respectivas pruebas.

Pues así es como gracias a la preocupación de todos los apartados se realiza DevOps. Se rompen los silos y el equipo de Desarrollo, por ejemplo, se preocupa por cómo se va promocionando por los diferentes entornos o que el equipo de Sistemas esté al tanto de cómo se realizan las pruebas de QA. Del mismo modo, también el equipo de QA busca la mejora del código para que este sea menos propenso a tener bugs, ya que una entrega de valor a cliente se produce gracias a el conjunto de TODOS y no sólo al mérito de un equipo.

¿Por qué debería adoptar DevOps?

Todos los años, desde Puppet Labs publican un extenso reporte del estado de DevOps en las empresas y qué beneficios tienen las compañías que han adoptado DevOps frente a las que no. Veamos algunas de estas ventajas

• Despliegan 200 veces más frecuentemente
• Sus tiempos de entrega son 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

Sin duda alguna, DevOps ayuda a romper los silos de los diferentes departamentos, mejorando en conjunto la eficacia de los equipos.