DevOps: fundamentos, beneficios y cómo implementarlo (PARTE II)

Continuamos con la segunda parte sobre Dev Ops, en la primera parte definimos lo que era, mientras que en esta segunda parte hablaremos sobre los beneficios de usar DevOps, cómo implementarlo, y los principios que lo cimentan.

Algunos beneficios de usar DevOps

De todo lo dicho la mejor prueba de que DevOps funciona es en base a la experiencia de equipos y organizaciones que ya trabajan con este método. En una reciente encuesta recogida en el whitepaper “State of DevOps Report “, donde han participado más de 3000 empresas y profesionales de todo el mundo, se destacan los siguientes beneficios obtenidos:

  • Recuperación frente a un fallo total: 96 veces más rápido.
  • El tiempo entre que un cambio de código es introducido y se pone en producción es 440 veces más rápido.
  • Automatización de tareas antes redundantes entre equipos y mejora de detección de errores.
  • La frecuencia de los despliegues es 46 veces más común.
  • Se duplica las veces que se alcanzan objetivos clave de negocio
  • Tasa de errores 5 veces menor: Del 38,5 % al 7,5 %.

Cómo puedo implementar DevOps

De todo lo dicho seguro que estás pensando “Yo quiero un poco de esa magia”, pero DevOps no es magia, es el resultado de un duro trabajo para entender cómo funciona una organización y sus diferentes áreas. Los cambios no se dan de la noche a la mañana pero siempre puedes comenzar por hablar con tu equipo de cambiar las cosas, comenzar a mejorar la organización interna, trabajando en equipo para implementar pequeños cambios y comenzar a involucrar a otras áreas, para que de forma gradual esos cambios acaben por transformarlo todo. Citando al VP de Operaciones IT de Linkedin: “No puedes cambiar directamente la cultura. Pero puedes cambiar el comportamiento, y el comportamiento se convierte en cultura.”

Los principios que lo cimentan

Como ya se ha mencionado no hay un método milagroso o definitivo para implementar DevOps, dado que cada organización es diferente, pero entre los profesionales del sector sí es común hablar de CALMS como los pilares fundamentales sobre los cuales llevar a cabo nuestro proyecto en todos los aspectos.

CALMS, es un acrónimo que significa Cultura, Automatización, Lean, Medición y Sharing (Compartir). Una serie de puntos clave que resultan particularmente útiles para analizar la estructura de una organización. Simple pero efectivo, CALMS marca las directrices para todas las partes interesadas, marcando claramente qué hay que implementar, así como pautas y herramientas para articular e integrar las diferentes partes y procesos de cara a automatizarlos u optimizarlos al máximo para lograr los mejores resultados posibles y esto, de alguna manera, es lo que permite hablar plenamente de DevOps dentro de una organización.

Cultura

Este punto es crucial en una organización. El conocimiento de cómo funciona una organización y conseguir involucrar a sus actores para generar valor es especialmente importante para lograr que todos los actores se involucren y no solo los departamentos técnicos.

La cultura en una organización es el conjuntos de saberes, creencias y pautas de conducta, incluyendo los medios materiales que usan sus miembros para comunicarse entre sí, y resolver sus necesidades.

Automatización

Liberar a los equipos de tareas repetitivas o redundantes, logra que los diferentes equipos puedan concentrarse en tareas más productivas.

En este sentido, DevOps propone la aplicación de herramientas que automaticen gran parte de los procesos existentes a lo largo del ciclo de vida como:

  • Automatización de las revisiones de código.
  • Automatización de la construcción y del despliegue.
  • Automatización de los controles de calidad.
  • Automatización del aprovisionamiento de infraestructuras.

Lean

El desarrollo de software Lean tiene 7 principios, y el primero es “eliminar los desperdicios”, es decir, todo aquello redundante y que supone una pérdida de tiempo ya que no aporta valor. Estos son:

  • Código o funcionalidad innecesaria en las aplicaciones.
  • Sobrepasar la capacidad del equipo, o empezar más de lo que puede terminarse.
  • Requisitos poco claros o con cambios constantes.
  • Burocracia.
  • Comunicación lenta o inefectiva
  • Trabajo parcialmente terminado
  • Defectos o problemas de calidad
  • Cambio de tareas

Medición (Metrics)

Lo que puede medirse puede gestionarse. Dicho de otra manera, lo que se mide se puede gestionar de forma eficaz, y DevOps también pone el foco en esta parte.

El uso de métricas da visibilidad sobre el estado real de un proyecto de forma que los responsables de los equipos, y sus miembros coordinen acciones coherentes con los objetivos corporativos, alineando la visión y la estrategia de la organización.

La medición es el combustible que alimenta el motor DevOps que se centra en la mejora continua basada en el “empirismo”, y por tanto en la experiencia y los datos obtenidos.

Compartir (Share)

La creación de valor surge de la colaboración, del aprovechamiento de experiencias y conocimientos multidisciplinares del equipo. Gracias a compartir conocimiento los integrantes del equipo, y de otras áreas, pueden tener acceso al mismo, de modo que formaran parte del modelo de referencia para un proceso iterativo de aprendizaje y mejora continua, optimizando iterativamente los procesos de la organización.

Compartir también implica invertir en políticas de desarrollo de talento e innovación, que faciliten o permitan cambios dentro de la cultura de la organización.

Busca, compara y si encuentras algo mejor compártelo.

De todo lo dicho y a modo resumen debemos decir que DevOps ha llegado para quedarse. No es una moda pasajera y más tarde o más temprano los equipos de software, negocio, infraestructura y gerencia de las organizaciones deberán valorar su adaptación puesto que marcará, casi con total seguridad, una ventaja competitiva insalvable en caso de no ser así.

Algunas preguntas simples que pueden ayudar a detectar por dónde comenzar a mejorar alguno de los puntos descritos anteriormente podrían ser algunas de las siguientes:

  • ¿Cuánto tiempo se ha tardado en realizar un despliegue completo de un desarrollo?
  • ¿Con qué frecuencia tienen lugar errores o fallos?
  • ¿Cuánto tiempo se tarda en recuperarse tras un fallo crítico?
  • ¿Qué impedimentos o bloqueos encontrarnos durante la implementación?
  • ¿Cuántas personas pueden aportar valor? ¿Y cómo pueden compartirlo al resto de la organización?

Estas y otras preguntas, más o menos adaptadas a cada organización o puesto en concreto, ayudarán a detectar dónde debe prestarse atención. Con dicha información y las métricas obtenidas en los procesos se podrá ir confeccionando una hoja de ruta inicial que irá mejorando iterativamente hasta hablar definitivamente de una organización que implementa ‘DevOps’.

No te pierdas la primera parte... DevOps: Qué es, mitos y leyendas (PARTE I)

 

Guía de Posibilidades Profesionales en el Ecosistema de Java