DevOps: el reto mayor de la agilidad en TI

Durante ya años se ha hablado de DevOps, de esta práctica que busca unificar el desarrollo de software y la operación del mismo en producción, para tener con ello agilidad no solo para desarrollar sino también para implementar, ¿se lee muy fácil no? Pues no ha sido fácil implementarlo.

La esencia más importante de la agilidad es la entrega de valor frecuente a nuestros clientes, pero esas entregas no las hacen solo los equipos de desarrollo, sino también los equipos de infraestructura.

Ha llegado el momento de tomar en serio este tema, porque los negocios han cambiado y no podemos seguir trabajando de la misma forma. De nada sirve que agilicemos el desarrollo si la implementación va a estar llena de obstáculos y retrasos. La sinergia entre equipos de desarrollo y equipos de infraestructura es necesaria.

DevOps tiene, como toda práctica, factores técnicos y factores humanos; hablaré primero de algunos factores técnicos a manera de contexto:

• Microservicios – Son necesarios para tener autonomía en los componentes de desarrollo, de tal forma que una vez que se desplieguen no se requiera tumbar servidores ni tirar otras aplicaciones, facilitando así implementaciones y cambios/mejoras a los sistemas. Esto no es obligatorio, hay empresas que pueden llegar a desplegar continuamente sin tener arquitecturas diseñadas bajo microservicios, sin embargo, esta característica es un acelerador importante para DevOps.
• Servidores de integración continua – Hay plataformas que facilitan las implementaciones para no alentar el proceso de subir a producción nuevas versiones de aplicaciones.
• Ambientación – En mi opinión, todos hemos vivido la frustración que representa contar con ambientes adecuados para desarrollar, para probar y para implementar; para esto existen herramientas para realizar las configuraciones necesarias para evitar estas situaciones frustrantes.
• Gestores de liberaciones – Se requieren herramientas que den visión y certeza sobre el software que se va a subir a producción para estar seguros que está listo y mitigar los riesgos y problemas, sobretodo si existen riesgos de detener o afectar la operación de una empresa.

Ahora toca hablar de los factores humanos. Bendita complejidad accidental que le inyectamos a nuestros proyectos de TI, ¿verdad?

• Sinergia entre desarrollo e infraestructura – Si se continúa viendo como estas disciplinas como áreas o equipos independientes, DevOps no va a funcionar. Es impresionante ver cómo en varias empresas se ven estas áreas como áreas enemigas en las que se gestan batallas diarias para señalar culpables y no para señalar soluciones. Donde cada una hace iniciativas de mejora sin tomar en cuenta a la otra. Si los directivos de estas áreas no están dispuestos a borrar las líneas que dividen a sus equipos, DevOps no es opción. ¿Pero qué creen? Tampoco van a ser buena opción para los clientes, porque seguirán ganando terreno quienes sean ágiles no solo para desarrollar sino también para implementar.
• Comunicación temprana – Si utilizan Scrum, el momento ideal para comenzar la comunicación con áreas de infraestructura es durante el Sprint 0 o el Sprint Gardening, y continuamente estar alimentando el backlog con los requerimientos técnicos y administrativos que se requieren para subir a producción nuestras aplicaciones. Si trabajan con Kanban, el momento oportuno para comunicarse es durante las Service Delivery Reviews que se hacen cada semana, las Operations Reviews que se hacen cada mes y las Strategy Reviews.
• Cultura integradora – DevOps es un conjunto de herramientas que no sirven de nada sin una cultura que integre a las personas, una cultura que no ponga metas verticales donde la gente se interese más por buscar la justificación hacia los errores o los culpables en vez de buscar soluciones. Se invierte más tiempo buscando evidencias para culparse entre equipos que buscando soluciones de fondo que les haga la vida mas llevadera a ellos y sea de más calidad para los clientes. DevOps no se implementa desde un equipo, es una estrategia organizacional.

En lo personal, no estoy de acuerdo con un nuevo rol que ha surgido que se llama Ingeniero DevOps, al que se le pide que haga el trabajo técnico y gestione equipos múltiples con diferentes prioridades. No estoy de acuerdo porque ponen en un perfil el objetivo de integrar cuando ya vimos que no es un rol, no es un perfil; no es un equipo, DevOps es una cultura.

Estoy de acuerdo en que las empresas necesitan guía para fomentar la sinergia entre áreas de desarrollo y áreas de operaciones, pero solo como guía, que no se convierta en responsabilidad de alguien la unificación y al priorización, ya que eso es tarea de todos los involucrados.

Muchos soñamos con implementaciones livianas y automáticas en producción. También soñamos con comer mucho y no engordar… lo segundo, lamentablemente, siempre será un sueño pero DevOps hace del primer sueño una realidad donde las implementaciones son mucho más livianas y casi automáticas.

Sobre el autor: Vanessa Amaya es Agile Delivery Manager en la empresa Wave. Co-fundadora de la Comunidad Agile Nights y representante del nodo México de la Comunidad Internacional Agile Women. 15 años de experiencia en la industria de TI. Conferencista. Miembro del Comité Académico del Programa TSU de Software de la Universidad IBERO.