¿Cómo puede alguien en el equipo ayudar a introducir DevOps en la organización?

El otro día leía, que la mayoría de las implementaciones exitosas de DevOps han empezado desde “dentro” no desde dirección. Esto significa que hay una oportunidad para que todos los miembros del equipo se involucren en la introducción de DevOps en la organización desde el principio. El objetivo principal de DevOps es permitir a las organizaciones a reaccionar a los cambios de forma más rápida y eficiente posible, y la manera de hacerlo es con Integración Contínua.

DevOps es un cambio cultural; es una filosofía acerca de hacer que todos colaboren, se comuniquen juntos y averigüen cómo mejorar procesos. Aplica los principios ágiles de colaboración y comunicación, haciendo que todos trabajen juntos en equipo, extendiéndolo a operaciones y consiguiendo la implicación de todos en el ciclo de vida del software, desde la toma de requisitos hasta la puesta en marcha, con el objetivo común de hacer un producto más eficiente.

Integración contínua, es una práctica del desarrollo del software que realiza integraciones automáticas del código desarrollado por cada programador del equipo, con el objectivo de detectar errores de integración lo antes posible.

Entonces, ¿cómo podría alguien en el equipo ayudar a introducir DevOps en la organización?.

  1. Primer paso, es entender el contexto en el que estamos trabajando. Se necesita entender que significa DevOps para tu organización.
  2. Una clave para DevOps es romper con lo tradicional y debemos pasar a crear equipos funcionales (Dev, Ux, PO, QA, BA y Ops, RM). Una vez definido el equipo, analicemos que significa devOps para cada miembro del equipo ( velocidad Release, calidad de lo subido, estabilidad…).
  3. Empezar con definir una estrategia, para saber si todos en el equipo están alineados y saber qué objetivos se quieren abarcar.
  4. Adopción de metodologías ágiles: Las personas del negocio y el equipo de desarrollo deben trabajar juntos de forma cotidiana con comunicación frecuente y si es posible mejor cara a cara.
  5. Uso de técnicas y metodologías de test: Las pruebas han adquirido gran protagonismo en el desarrollo de software, para mejorar su eficiencia.
  6. La última clave, pero no menos importante, es la de educar a los demás. Dado que DevOps se basa en los principios, procesos y herramientas, QA también se basa en estos mismos principios, por lo que es natural que QA ayude a educar a los demás. Desde mi punto de vista, una organización que intente moverse a DevOps va a fracasar si simplemente quiere adoptar sus herramientas.

Y acompañando en el proceso de Integración Continua, podríamos ir aún más allá:

  1. Tratar de introducir metodologías de desarrollo de software centrado en la realización de pruebas:
    • BDD (Behavior-Driven Development), con el que se busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común donde arranque el Testing y, desde ahí, el desarrollo.
    • ATDD (Acceptance Test-Driven Development):  es una práctica en la que todo el equipo, destacando, e incluyendo, a los usuarios y/o al Product Owner, desarrolladores y tester, analizan conjuntamente los criterios de aceptación, antes de que comience el desarrollo.
  2. Uso de microservicios en el diseño de desarrollo.
  3. Otra área dónde podemos participar, es en las pruebas automatizadas. DevOps apoya la automatización de pruebas y debería ser tarea de un QA definirlas. Comenzar con temas de automatización, puede ser un poco complicado, ya que normalmente un QA no tiene un backgroung sólido, pero, yo siempre me he encontrado con mucha ayuda por parte del equipo de desarrolladores y afortunadamente hay una fuerte comunidad en Internet que facilita estas tareas. Una manera para mostrar a la organización los beneficios de las pruebas automatizadas es la creación de un conjunto simple de pruebas de humo.
  4. Uso de métodos de integración/despliegue/entrega continua.

Y ayuda a la organización a descubrir cómo crear cultura para inspirar la mejora continua, el aprendizaje continuo y la retroalimentación continua para hacerlo lo mejor posible. Para ello hay que:

  • Definir los objetivos a largo plazo.
  • Determinar los objetivos a corto plazo para saber que se está en el camino correcto.
  • Crear un mapa\dibujo de flujo de la organización, productos, aplicaciones, sistema y equipo.
  • Decidir las métricas para valorar resultados.
  • Detectar cuellos de botella.