7 perfiles DevOps para triunfar

Casi todas las organizaciones TI quieren adoptar el enfoque DevOps, con la intención de conseguir una mayor velocidad de desarrollo de software y una mayor agilidad empresarial que se deriva en la optimización y la aceleración de las interacciones entre el desarrollo y las operaciones.

El problema es que no hay una forma fácil o rápida de lograrlo. «Muchas organizaciones han elegido este camino, considerándolo algo puramente tecnológico: consigamos una herramienta DevOps, y la vida será mucho mejor», dice Rohit Antao, partner y enterprise solution líder de DevOps con la consultora mundial de TI PwC. Estos intentos a menudo fallan. Para lograr el éxito es clave contar con las personas adecuadas en los puestos DevOps indicados y con las habilidades necesarias – y la disposición a colaborar.

Los líderes de TI necesitan encontrar y potenciar siete roles profesionales nuevos o en desarrollo. Además de una persona que lidere el cambio para supervisar la transformación al enfoque DevOps, estos roles incluyen release managers, arquitectos de automatización, developer-testers, expertos en experience assurance, ingenieros de seguridad y utility technology player que entiendan el desarrollo y las operaciones.

Nuevas habilidades, nuevos roles para DevOps

No existe un equipo de DevOps como tal, dicen Antao y otros expertos. Más bien, es un enfoque, y lo que todavía está menos claro son sus roles. No es sorprendente, después de ver que DevOps se describe como «algo que todo el mundo quiere, pero nadie quiere hacer», dice Mark Warren, director de marketing de producto para el fabricante de la plataforma de colaboración y gestión de código fuente Perforce.

Descubrir los roles adecuados de DevOps es un viaje, no un destino, dice Martin Croker, director general de la consultora de TI Accenture – y es un viaje largo.

Una compañía de software, cliente de PwC cambió su modelo de negocio pasando de ofrecer un producto desde su organización a atender a los clientes en la nube. El cambio repercutió en cada área de la empresa, desde ventas y marketing hasta recursos humanos e I + D. Pero el mayor cambio tuvo lugar en la tecnología de la organización, que de repente incluía características y capacidades nuevas a diario y semanalmente, en lugar de hacerlo anualmente. Para lograrlo, adoptó el enfoque DevOps.

«El modelo de negocio cambió drásticamente, y de repente tuvieron una gran necesidad de velocidad», dice Antao. IT necesitaba más que implementar una serie de herramientas DevOps: reorganizarse y desarrollar nuevas habilidades tanto en los equipos de TI como en los de operaciones para alcanzar una mayor velocidad. El proceso hasta ahora, ha durado cinco años. «No hubo respuestas durante el primer año. Gran parte se basa en prueba y error para descubrir qué funciona y qué no», dice Antao.

 Transición a los roles de DevOps

Mientras no haya un plan específico que se pueda aplicar para reorganizar y desarrollar las nuevas habilidades, las experiencias de los pioneros al implementarlas sirven como referencia en cuanto a mejores prácticas. «DevOps representa una tecnología y un cambio cultural», dice Croker. «Dónde más se equivoca la gente es al tratar de abordar las áreas idénticas de Desarrollo y Operaciones creando una tercera DevOps, sin pensar en un contexto más amplio». Esa es una respuesta superficial, y no funciona, añade. «Las nuevas etiquetas, roles y nombres de puestos no siempre llevan a un cambio real».

Decir simplemente que hay roles clave en DevOps induce a error, dice Neeharika Nagisetty, gerente de marketing de productos de Vantiv, un proveedor de servicios de procesamiento de pagos. «La clave de DevOps es una mayor colaboración entre desarrollo y operaciones». Eso significa darle una vuelta a los roles de desarrollo y operaciones que existen y reorientarlos en torno al delivery continuo de software, desde ideas y desarrollo hasta producción y mantenimiento. «DevOps abarca al completo los roles existentes de los equipos ágiles, productos, ingeniería, seguridad, tecnología de la información, control de calidad y operaciones, todo orquestado por un enfoque de negocios preciso».

«Si reflexionas sobre lo que implica este movimiento -aumentar la velocidad del software a lo largo de la cadena de valor-, cada rol está cambiando», dice Antao de PwC. Cada función TI debe previamente formar parte de la cadena de valor, tanto si las operaciones de TI participan en el diseño o el testing se convierte en parte integral del desarrollo. «Todos los involucrados en DevOps deben entender el enfoque de una manera más amplia y completa de lo que se necesita que consigan. Un desarrollador ya no es solo un desarrollador responsable de asignar X líneas de código. Se les pide que entiendan por qué es necesario hacerlo, que lo implementen, que lo prueben y que lo utilicen”, dice Yoram Mizrachi, director de tecnología de Perfecto Mobile, un proveedor de infraestructura de pruebas de estructura móvil on-demand. «Quien realiza los tests ya no es responsable simplemente de asegurarse que la funcionalidad sea la esperada. Se les pide que validen la experiencia del usuario con la aplicación probando que funcione como se espera ante condiciones, dispositivos y redes de la vida real».

 Los siete roles DevOps principales

Adoptar roles nuevos o redefinidos no es suficiente para una transformación exitosa de DevOps, pero es un primer paso fundamental. «En las implementaciones DevOps que no prosperan, las organizaciones no se dan cuenta de que las personas son la parte más importante de la ecuación», dice Gerry Leitao, vicepresidente de managed delivery services y plataformas para la consultora Capgemini North America. «Estas organizaciones a menudo incorporan miembros a sus nuevos equipos DevOps antes de que hayan entendido completamente las habilidades técnicas y soft que se requieren para un equipo DevOps de alto rendimiento. No se dan cuenta de que no todo el personal tiene la visión o las ganas necesarias para tener éxito en un entorno altamente colaborativo y fluido «.

Estos son los siete roles – y habilidades relacionadas, – que son esenciales para cualquier organización que quiera adoptar un enfoque DevOps con éxito».

1. El DevOps pionero “evangelist”

«Hay organizaciones de TI que han evolucionado para sacarle partido a las prácticas y capacidades de DevOps, y hay otras que están en proceso de hacerlo», dice Croker. «Esa evolución no va a producirse sola, y el role principal lo tiene la persona que va a liderar ese cambio». El evangelista de DevOps es tu líder.

Esta persona debe promover los beneficios de DevOps identificando y cuantificando los beneficios comerciales resultantes de la mayor agilidad que ofrece DevOps. Como agente de cambio, DevOps evangelist asegura la coordinación de los equipos de desarrollo y operativos, identifica los roles clave que apoyen los métodos de DevOps y se asegura de que los profesionales de TI estén capacitados para llevar a cabo esos cambios, dice Nagisetty. Además, el líder de tu movimiento DevOps necesita eliminar el miedo al fracaso de la organización, dice Antao. «Tienes que crear una cultura que sea de aprendizaje donde no pase nada por fracasar, se haga rápido, se aprenda y se mejore con ello».

Croker está de acuerdo. «En una organización dirigida por DevOps, hay algunos roles nuevos… pero es mucho más importante es que se logre un cambio cultural para afrontar los retos que surgen al proporcionar servicios TI y de las operaciones de TI», afirma.

2. El release manager

Tanto si llamas a este role release manager, release engineer o product stability manager, el enfoque es el mismo: «Los release managers se encargan de la gestión y coordinación del producto desde el desarrollo hasta la producción», dice Nagisetty. «Normalmente se centran en más detalles técnicos y obstáculos en los que un project manager típico no estaría involucrado». Los release managers supervisan la coordinación, la integración y el flujo de desarrollo, testing e implementación para apoyar la entrega continua del servicio. Están enfocados no solo en crear, sino también en mantener la cadena de aplicaciones de principio a fin, dice Antao.

3. El arquitecto de automatización

Debido a que DevOps depende en gran medida de los sistemas automatizados, este role es fundamental. A veces, se les conoce como especialistas en integración, los arquitectos de automatización analizan, diseñan e implementan estrategias para despliegues continuos, al tiempo que garantizan una alta disponibilidad en los sistemas de producción y preproducción, dice Nagisetty.

«Los arquitectos de automatización tienen un rol integral de automatización sobre las herramientas de DevOps y las plataformas cloud», dice Leitao. «Este rol también puede abarcar el lean thinking en los procesos clave de DevOps».

El rol de arquitecto de automatización se ha vuelto clave en el mundo de DevOps. «Las organizaciones DevOps deben crear un entorno de mucha confianza que esté completamente automatizado y libre de obstáculos», dice Mizrachi. «En determinadas circunstancias, todo el mundo tiene que disponer de vehículos 4×4 para conducir fuera de la carretera por terrenos difíciles. La función de la automatización de DevOps tiene la tarea de construir la carretera para que podamos usar coches rápidos».

El puesto es especialmente importante para las organizaciones que se organizan por aspectos geográficos, añade.

4. El developer/probador de software

El desarrollador de software es el corazón de la organización DevOps. En DevOps, la categoría de desarrollador de software puede seguir siendo la mismo, pero el nuevo rol del developer/tester de software aumenta drásticamente el alcance de las responsabilidades. Los desarrolladores son responsables no solo de convertir los nuevos requisitos en códigos, sino también en testing, implementación y monitoreo continuo. «No solo crean códigos para algo específico y lo pasan al equipo de control de calidad», dice Antao de PwC.

Así como DevOps implica una colaboración más amplia entre los equipos de desarrollo y operaciones, a veces también se lo denomina DevTestOps, lo que refuerza la idea de que el testing es una parte del proceso, dice Nagisetty.

Este cambio a menudo requiere que se realice un testing más automatizado para que la calidad no se vea perjudicada. «El problema es que los equipos aún piensan que pueden hacer los tests de forma manual y aun así ser ágiles. No se puede», dice Mizrachi. «Si necesitas testear nuevas versiones todos los días y lo haces de forma manual tardando dos semanas, es prácticamente imposible. La calidad del producto generalmente se deteriora hasta que la organización y los procesos cambian».

5. El profesional de experience assurance (XA)

Si bien la función de garantía de calidad (QA) a menudo forma parte del desarrollo de software, se necesita un nuevo tipo de control cuando las organizaciones adoptan el enfoque DevOps. La necesidad contar con los testers de control de calidad es reemplazada por la necesidad de que los expertos de XA se encarguen de garantizar que todas las características y funciones nuevas se lancen teniendo en cuenta la experiencia del usuario final. «Lo que se espera actualmente de los roles de QA es probar la funcionalidad, pero el rol debe evolucionar para incluir el testing de la experiencia del usuario», dice Mizrachi.

6. El ingeniero de seguridad

En el tradicional desarrollo en cascada, la seguridad del sistema ha surgido tarde. Es un «requisito no funcional» que, al igual que la garantía de calidad, a menudo se agrega al final del desarrollo del sistema, dice Antao de PwC.

El enfoque DevOps cuenta con ingenieros de seguridad que trabajan codo a codo con los desarrolladores, integrando sus recomendaciones mucho antes en el proceso. «Le dan seguridad al producto, no al final», dice Antao.

7. La importancia del technology player

Los profesionales de operaciones de TI o administración de sistemas tradicionales se centran en mantener los servidores en funcionamiento. «En general, sus máquinas funcionan mejor cuando hay pocos cambios», dice Perforce’s Warren. «Es probable que la causa más común de las interrupciones del servicio sean las aplicaciones que se ejecutan en estos servidores, por lo que los administradores incluyen controles muy estrictos sobre lo que está permitido ejecutar en sus servidores. Requieren un amplio control de calidad en un entorno de prueba, un gran delivery, documentación de operaciones y lanzamientos poco frecuentes». Los desarrolladores típicos han sido codificadores directos sin involucrarse en los sistemas de postproducción.

El entorno rápido de DevOps requiere un nuevo perfil. «Los expertos en operaciones o administración ahora se están involucrando a lo largo del proceso de desarrollo», dice Warren. «Hoy en día, no sería raro que estos expertos en operaciones, que a veces se conocen como ingenieros de DevOps, participen en la planificación de sprints para garantizar que se priorice una mejor calidad de servicio, gestión de recursos o seguridad por parte de la compañía».

Teniendo como antecedente el desarrollo o las operaciones de TI, «DevOps requiere miembros para su equipo que puedan operar de manera efectiva en plataformas de desarrollo, herramientas, redes, servidores y bases de datos, e incluso en desarrollo y soporte», dice Leitao.

Una transición efectiva al entorno de DevOps es más una cuestión de las personas que integran el equipo y de la manera en que trabajan juntas para ofrecer productos de una forma diferente que de la tecnología. Al reclutar o volver a formar a los profesionales de TI para ocupar estos siete roles de DevOps, los líderes de TI pueden dar un primer paso importante hacia el logro de un modelo DevOps exitoso.

Puedes leer el artículo original aquí.