Introducción
Bienvenidos a la tercera parte sobre mi serie de artículos sobre el futuro de DevOps. Tras haber introducido esta reconstrucción «opinionada» sobre los principios y prácticas DevOps, nuestro entendimiento de lo que significan y lo que funciona y no funciona en las organizaciones con las que he trabajado, y tras haber introducido en la segunda parte las propuestas de valor de la entrega continua y la ingeniería de fiabilidad de sitios (continuous delivery & site reliability engineering) llega el turno de hablar de la experiencia del desarrollador (developer experience), comúnmente abreviada como DevX o también como DevEx.
Para empezar a hablar de la experiencia del desarrollador, y por extensión de la experiencia de los ingenieros de software y de todas las personas implicadas en el ciclo de vida del desarrollo de software, voy a empezar por hablar de lo que no es:
- Noches sin dormir por un problema urgente sin tener los medios para conocer con certeza qué está pasando en producción.
- Tiempos de espera por peticiones de permisos de acceso o aprobaciones para hacer incluso la más trivial de las tareas.
- Requerimientos que no están claros al estar muy separado el negocio de los equipos de desarrollo, lo que ocasiona retrabajo continuo y muchos apuros para llegar a fechas de entrega comprometidas por alguien no implicado en el desarrollo.
- Aplicaciones que cuesta muchísimo poner en producción porque no se tienen claros los criterios que hay que seguir o no hay transparencia sobre cómo van a estar, o ya están, configurados los entornos.
Al final, todas estas situaciones generan frustración en los equipos. No son tan productivos en su día a día como podrían ser. Están «atrapados».
Y ahí es donde entra la experiencia del desarrollador.
Queremos proporcionar a nuestros equipos de desarrollo de una experiencia fabulosa cada día: que se sientan productivos, que realicen sus tareas con gran calidad, que las interacciones entre roles sean armoniosas. En definitiva: que cada persona se dedique a hacer aquello para lo que está mejor preparada, en lugar de «pelear contra molinos de viento».
Y eliminar, por tanto, todo aquello que causa retrasos, ineficiencias, y frustración.
Podemos ver la experiencia del desarrollador como un análogo a la experiencia de usuario o a la experiencia del cliente.
Cuando hablamos de experiencia del cliente, muchos visualizareis una tienda fantástica —esa tienda de referencia de una gran marca— donde cada segundo desde que un cliente potencial entra por la puerta hasta que finaliza su visita esté debidamente estudiada y planificada para generar satisfacción y vinculación a la marca.
Cuando hablamos de la experiencia de usuario, hablamos de dotar a las personas que están usando una aplicación —ya sea web o sea móvil, ya sea para el público general o sea una aplicación interna de la empresa—, con una interfaz intuitiva, fácil de utilizar, que no les frustre, que no les requiera estar todo el tiempo navegando «de aquí para allá» para tareas sencillas, sino que sea todo claro, preciso y rápido.
Siguiendo esa analogía, la experiencia del desarrollador busca diseñar e implantar acciones para que el día a día de los equipos de ingeniería sea fantástico. Se pone a los ingenieros en el centro como actores principales y de gran valor para la organización. Se cuida de sus necesidades y se prima que sean felices y se sientan valorados, como camino para alcanzar la excelencia mediante la productividad y la calidad.
Por qué son necesarias las estrategias de DevEx
Suena bien, ¿verdad? Tan bien que podríamos pensar que es algo que nos acompaña ya en nuestro día a día. Pero no es así y debemos trabajar para cambiarlo.
Si nos fijamos a nuestro alrededor, la verdad es que las organizaciones no lo ponen fácil a desarrolladores, ingenieros de plataformas e infraestructuras, analistas de datos o de seguridad, expertos en calidad y expertos en el negocio que participan en el desarrollo de soluciones:
- Existen grandes puntos de dolor desde que un proyecto o producto empieza a tomar forma hasta su fin de vida. Esos puntos de dolor se extienden a cada persona que empieza a trabajar en un equipo, y los puntos de dolor acompañan a las personas en su día a día mientras pertenecen a ese equipo.
- Hablamos de limitaciones y procesos tediosos, por ejemplo, para conseguir acceso a un repositorio de código, a una herramienta de gestión de proyectos, a un escritorio remoto, a un entorno de desarrollo o prueba, o conseguir una licencia para una herramienta necesaria.
- Hablamos de poca claridad o acceso limitado al conocimiento de la organización y la documentación que se necesita para conocer la tarea a realizar y poder completarla.
- Hablamos de indefinición o poca claridad en prescripciones de arquitectura: blueprints de soluciones, arquetipos de componentes y artefactos, herramientas recomendadas, estándares y buenas prácticas.
- Hablamos de la seguridad por oscuridad, donde objetivos, políticas y procesos de cumplimiento no son ampliamente conocidos, ocasionando retrabajo y retrasos, e incluso en ciertos casos exponiendo a la organización a riesgos adicionales cuando los equipos o individuos «se buscan la vida».
- Hablamos de carencias en las campañas de concienciación sobre la seguridad física y de la información, limitadas en su alcance y desconectadas de escenarios del mundo real.
- Y, por supuesto, mucho, muchísimo, trabajo manual, de bajo valor, sin capacidades de autoservicio para fomentar la autonomía de los equipos y la sensación de estar siempre dependiendo de otros.
Imaginad cualquiera de vuestros clientes con cientos, incluso miles de desarrolladores. Imaginad si pudiéramos eliminar tareas innecesarias que supongan tan solo una hora de trabajo a la semana por cada persona. Una pequeña mejora como esa tendría un efecto multiplicador impresionante: miles de horas semanales que se podrían dedicar a mejorar la calidad de los productos, a entregar con predictibilidad en los plazos acordados (o mejorarlos), o resultar en esfuerzos ahorrados si ya se cumplen el resto de los objetivos.
Se busca mucho la productividad de los desarrolladores, pero no siempre de la manera adecuada. No es raro hablar con equipos de desarrollo que se sienten presionados, con actores externos al equipo continuamente «encima de ellos» para que sean más productivos y entreguen en plazo «como sea». Pero solo con presionar y desear algo, no tiene por qué suceder.
Y es que pocas veces se hace el estudio de qué causa que los equipos de desarrollo no sean tan productivos como la organización desearía y se toman las acciones necesarias. No desear, sino actuar:
- ¿Les estamos dotando de las herramientas necesarias?
- ¿Establecemos procesos excesivamente complejos, con muchos puntos de aprobación que interrumpen el flujo de trabajo?
- ¿Se trasladan los retrasos causados por la incertidumbre en el trabajo a realizar hacia el equipo de desarrollo, o se producen continuos cambios en el alcance esperado sin que se modifiquen los hitos de entrega?
- ¿Se producen pausas esperando a que algo suceda porque parte del flujo de trabajo depende de otro departamento, de otro grupo, o de otro equipo? Por ejemplo, porque no haya comunicación fluida entre equipos y sus necesidades y dependencias no son conocidas, o se depende de un equipo externo que se convierte en cuello de botella, etc.
- ¿Hay suficiente automatización para que tareas cotidianas y sencillas no necesiten de intervención humana?
- ¿Establecemos silos organizativos con objetivos contradictorios que generan fricción entre los distintos roles?
- ¿Resulta fácil a las personas que incorporamos a los equipos tener acceso al conocimiento y herramientas que necesitan para hacer su trabajo de forma productiva?
Solamente cuando en una organización nos detengamos a hacer esas preguntas, analizando la cadena de valor desde que una idea surge en el negocio hasta que esa idea llega a producción, y descubriendo cómo el feedback de los usuarios finales se emplea en mejorar continuamente, podremos identificar los puntos de dolor y actuar para mejorar la experiencia de los equipos de desarrollo, y con estos actos ayudar a que la organización esté equipada para cumplir sus objetivos.
Sería maravilloso que nuestro día a día fuera radicalmente diferente.
Por qué es ahora el momento de DevEx
Me diréis: «Vale, todo esto es muy bonito. Pero ¿por qué precisamente ahora?»
Son muchos los retos de las organizaciones: incrementar beneficios, liderar en sus respectivos mercados, reinventarse para crecer y aspirar a ser los mejores. En un mundo donde todo negocio es un negocio tecnológico, los ingenieros de software, así como el resto de los perfiles que desarrollan y operan los sistemas tecnológicos se convierten en empleados clave de la organización. Tanto por su relevancia como por lo significativo en tamaño frente al resto de empleados de la organización.
Un banco puede tener los mejores productos financieros del mercado, pero si no puede ponerlos al «alcance de los dedos» de sus clientes lo tendrá muy difícil para prosperar. Una aseguradora puede tener la mejor red de asistencia a sus clientes, pero si éstos lo tienen difícil para ponerse en contacto con quien puede ayudarles, no conseguirá sus objetivos de retención.
Adicionalmente, experimentamos un crecimiento en la complejidad de los sistemas tecnológicos, tanto en su diseño como construcción y entrega del software, así como su operación y evolución posterior.
Necesitamos arquitecturas de sistemas más elaboradas, más distribuidas, con mejores capacidades y mucho más robustas para dar la funcionalidad que se requiere en el mundo digital. Y esa complejidad, si se traslada directamente a los equipos de desarrollo o de operaciones, puede causar sobrecarga y cuellos de botella en ellos, además de la propia presión cognitiva que supone tener que «saber de todo» o entrar en una dinámica donde «todo es urgente».
Finalmente, es también el momento de priorizar la experiencia del desarrollador porque nuestras fuerzas de trabajo son mucho más líquidas de lo que eran hace 5 o 10 años. Es muy común ver equipos que cambian en tamaño, en roles y responsabilidades, con skills técnicos que evolucionan con el ciclo de vida de los productos. Equipos que se reorganizan o que cambian completamente de área de negocio.
Por tanto, es fundamental el invertir en experiencias óptimas para las personas: tanto cuando aterrizan en el equipo y deben ponerse en marcha rápidamente, como durante su día a día a partir de ese momento. No basta con asumir una curva de aprendizaje larga y tediosa porque «solo pasa una vez en la vida». Cada día puede ser el primer día de alguien en el equipo, cada día puede ser el primer día que te enfrentes a una tarea nueva, y ese día debe ser fabuloso. No basta con «resolver» el día uno si luego cada día está salpicado de ineficiencias, fricciones, e incluso, miserias.
Cómo empezar a adoptar DevEx
De todo lo anterior ya se puede deducir que la DevEx no es algo «solamente» de los ingenieros de software ni «solamente» un problema de herramientas. Adoptar DevEx es un esfuerzo que embarca a toda la organización. La estrategia surgirá por tanto de la intersección de tres pilares de su arquitectura empresarial:
- Primero, la estrategia de talento y cultura.
- Segundo, el enfoque metodológico y las formas de trabajo.
- Tercero, la ingeniería de software y sus prácticas.
Y, en el centro de todos ellos, una estrategia orientada a plataformas.
A continuación, voy a describir con más detalle los aspectos que en mi experiencia son más relevantes a la hora de plantear un enfoque de DevEx en cualquier organización.
DevEx en la intersección de la estrategia de talento, las formas de trabajo, y las prácticas de ingeniería de software
El cambio cultural y la carrera interna de ingeniería de software
Empiezo por el cambio cultural ya que puede ser el más importante para potenciar la DevEx. Si no está presente difícilmente todo lo demás tenga el impacto deseado. Además, es normalmente el más difícil de articular y afinar a la realidad de cada empresa y grupo de profesionales.
No es fácil construir una marca atractiva para los ingenieros de software, no solamente ser una marca reconocida dentro del mundo de los negocios, sino también como un lugar donde desarrollar una carrera tecnológica.
El reto no es sencillo y tiene múltiples aspectos complementarios:
- Crear modelos de carrera específicos para los perfiles de ingeniería de software que sean atractivos y que se alineen a las expectativas de ese colectivo, alineadas a la presión que marca el mercado de talento.
- Promover un entorno de seguridad psicológica donde todo el mundo se sienta libre de opinar y de hablar, de disentir y donde todos reconozcamos que en la diversidad radica nuestra fuerza, pues para prosperar, mejorar y crecer todas las voces son bienvenidas.
- Promover también una cultura de la autorreflexión, que apuesta por la mejora continua con decisiones orientadas al dato: medir, formular hipótesis en base a esas mediciones, poner en marcha acciones y medir nuevamente el impacto de esas acciones para potenciarlas o descartarlas.
- Crear y facilitar el espacio y el tiempo para la innovación y el pensamiento sobre el futuro, analizar las tendencias tecnológicas y ver cómo nos pueden ayudar (y, por tanto, fomentar su adopción) o nos amenazan (y nos preparamos para ello).
En definitiva, una estrategia que potencie lo que se conoce, dentro de la tipología de organizaciones de Westrum, como una organización de tipo generativo.
Una consecuencia de este tipo de cambio cultural es que se destierran comportamientos no deseados como la «colampetición»: en un entorno empresarial donde la colaboración entre departamentos, equipos y roles, es fundamental para que los negocios prosperen, no hay cabida para la competición interna poco saludable, incluso tóxica, donde se antepongan objetivos personales o partidistas a los del conjunto de la organización.
Como esta no es mi área de conocimiento no voy a atreverme a profundizar, pero si te interesa el tema hay muchas fuentes solventes en las que inspirarse. Sin ir más lejos, en Codemotion Madrid los últimos años hemos tenido oportunidad de disfrutar de contenido excelente sobre las carreras de ingeniería de software y el cambio cultural y organizativo tan necesario en muchas empresas.
Fomento de la colaboración
El enfoque que la organización da para fomentar y potenciar la colaboración y la distribución del conocimiento entre departamentos, equipos o roles es de crucial importancia.
Una de las estrategias habituales es la creación de comunidades de práctica. Una comunidad de práctica es un grupo con una autonomía relativamente alta dentro de la organización que tiene la responsabilidad de conectar a las personas de una cierta tecnología, rol o área de negocio para hacer cosas como, entre otras:
- Fomentar que compartan el conocimiento por múltiples canales: wikis, charlas y talleres internos, hackathon, participación en eventos externos.
- Participar activamente en la construcción y evolución de productos y servicios internos con modelos inner source (p.ej. contribución al portal interno del desarrollador, contribución a la documentación de uso de una librería compartida).
- Prescribir arquetipos de soluciones, estándares y buenas prácticas.
- Diseñar los currículums formativos.
La gamificación es una herramienta muy útil para fomentar la participación en comunidades de práctica. Ya que no siempre es posible establecer un modelo 80%-20% para compaginar trabajo en proyectos con trabajo para la comunidad se torna necesario idear otras formas de compensar a las personas por su esfuerzo, ya sea mediante beneficios adicionales, bonos de fin de año, asistencia a eventos con gastos pagados, u otras vías.
Las formas son múltiples y muy variadas pero lo fundamental a nivel de estrategia es entender que todo esfuerzo debe tener su recompensa. Eso puede ser la diferencia entre desear que algo pase y tomar las acciones necesarias para que realmente pase.
Cuando los miembros de una comunidad participan en las actividades de esta los beneficios son múltiples. Por supuesto, el valor intrínseco de lo que se produce. También se consigue que el conocimiento fluya con naturalidad y las personas se sienten mucho más inclinadas a colaborar de forma espontánea (frente al hacerlo «obligado porque me lo ha dicho mi jefe»). Adicionalmente, la adherencia a procesos y estándares es mucho mayor ya que la gente se sienten parte de ello y no como algo impuesto desde «la torre de marfil». Nos bebemos nuestro propio vino porque pensamos que es el mejor.
Otra estrategia habitual consiste en la creación de equipos especializados con la función de relación con los desarrolladores (developer relations o developer advocates). Este rol, cuando se proyecta hacia dentro de la organización, busca trabajar con los equipos de desarrollo para entender sus necesidades y dificultades, y ayudar a que los productos y servicios internos se construyan para que la vida de los ingenieros de software sea tan fácil como sea posible. Estos equipos deben tener una interesante combinación de perfil desarrollador, calidad, datos, sistemas, formación y elaboración de documentación técnica, aunque no necesariamente contenidos todos ellos en el cuerpo de una sola persona.
Formación continua
Las estrategias que buscan impulsar la formación continua también tienen un impacto muy positivo en la experiencia del desarrollador.
Las personas se sienten valoradas cuando su organización se preocupa por que estén constantemente ampliando su conocimiento, generalmente hacia tecnologías nuevas y emergentes, pero también potenciando los soft skills.
Una estrategia de formación continua se complementa muy bien con el impacto que tienen las comunidades de práctica. Si la comunidad vela por identificar o desarrollar contenido formativo relevante para ellos mismos, la organización puede y debe aportar no solo una visión estratégica y de más largo plazo, sino aportar los recursos necesarios para que se lleve a cabo.
Puede parecer de Perogrullo, pero no lo es; un buen programa de formación continua requiere de inversión con visión. Por fortuna, existen muchas opciones de formación con precios ajustados y escalables. Desde portales de formación online que dan acceso a cientos de cursos de especialización (muy recomendables especialmente los que dan acceso a entornos de laboratorio a modo de playground), a acuerdos con proveedores de servicios para acceder con descuento a sus programas de certificación (p.ej. programas de colaboración para partners).
De un modo u otro, estos programas deben ser priorizados ya que la alternativa no es solo personal descontento sino una pérdida de valor intrínseco de las personas que no estarían tan preparadas para afrontar retos cercanos.
Quería hacer mención especial en este apartado al impacto positivo que la inteligencia artificial generativa va a tener en nuestro enfoque de aprendizaje. Podemos argumentar largo y tendido sobre su impacto en las tareas cotidianas de los ingenieros de software (eso da para otra serie de artículos) pero sí que vemos con mucha claridad su impacto positivo en las curvas de aprendizaje. Ya sea para aprender un nuevo lenguaje o tecnología, o tan solo la pizca de conocimiento que falte para una tarea específica.
Contando con que ya se cuenten con conocimientos sólidos de las bases de la ingeniería del software, cambia el enfoque de aprendizaje. No hace tanto tiempo que aprendíamos un nuevo lenguaje o framework con un libro, un manual, o un cursillo en CD. Los tutoriales online nos abrieron la puerta a más conocimiento y en muchas más áreas, pero no cambiaba la manera fundamental en que aprendíamos: leyendo (mucho) y practicando (lo que se podía).
La irrupción de la IA generativa sí que cambia y se reinventa la aproximación al aprendizaje. Podemos aligerar el proceso sin depender fuertemente de libros, tutoriales o cursos, y comenzar pidiendo ayuda y guía acerca de lo que queremos hacer. Yo mismo lo he experimentado directamente. Tenía que crear un automatismo con un lenguaje de programación con el que no había trabajado antes ni tampoco conocía la librería con la que debía automatizar el proceso. Con un asistente de codificación pude tener rápidamente una visión general de cómo se podía hacer la tarea, una guía paso a paso de lo que debía hacer para empezar, y una vez metido en faena, sugerencias sobre bloques de código o de configuración hasta completar mi tarea.
Pero ojo, no tienes por qué creerme; pruébalo. Cualquier tarea que tengas pendiente y que requiera aprender algo previamente, ya sea mucho o poco, intenta abordarla con la ayudad de un asistente de IA. Creo que te sorprenderá positivamente.
DevOps
Puesto que uno de los elementos que más influye significativamente en la experiencia del desarrollador es la fricción entre roles y la automatización de tareas (especialmente si son tediosas, repetitivas) no es de extrañar que DevOps sea una estrategia que se deje ver en el contexto de DevEx. Seguro que «lo esperabais» puesto que esta es una serie de artículos sobre nuestro entendimiento presente de los principios y prácticas DevOps. No voy a repetirme aquí, por tanto, sobre qué es DevOps, pero sí que voy a establecer los aspectos más importantes de esa conexión.
Fricción… roces, conflicto, falta de colaboración. De eso DevOps «sabe» bastante. Dejando las prácticas de automatización aparte, que ya introduje en el segundo artículo de la serie, DevOps es sobre todo una propuesta para trabajar de manera diferente, donde se potencia la colaboración y compartir objetivos entre equipos.
Por tanto, la conexión es directa: las organizaciones que adoptan DevOps como marco de trabajo sobre el que se apoyan las interacciones de los grupos de desarrollo y operaciones consiguen mejorar la experiencia del desarrollador. Al derribarse el imaginario «muro de la confusión» se tienen dinámicas fluidas entre todos los miembros de un equipo que funciona bajo principios DevOps. Recordad que DevOps es algo que lo hacemos todos, o no lo hacemos ninguno; no es un silo diferente sobre el que volcar todas las tareas que otros equipos no quieran o no sepan hacer.
Las ceremonias del día a día permiten repartir las tareas según la especialidad y conocimiento de cada miembro del equipo —ya sea desarrollador frontend, experto en datos, ingeniero de plataformas o infraestructura, etc. —, se anticipan dependencias y bloqueos, se discuten las opciones para resolver retos, o se acuerda cómo abordar cuestiones de cumplimiento de políticas. Sin sorpresas inesperadas. Sin broncas porque las cosas ya no se quedan en «tierra de nadie», ni se ignoran ni se despachan inmisericordemente a otros equipos.
En resumen: la empatía que se genera en un ambiente de alta colaboración reduce o elimina la fricción entre roles con un impacto directo en el bienestar de las personas y la productividad de los equipos.
Lo anterior se amplifica cuando se avanza en la automatización de las tareas tediosas y repetitivas. Cuando los miembros del equipo sienten que su tiempo, que es valioso, se emplea en tareas no triviales (de valor añadido) donde poner de manifiesto su especialización tecnológica y su capacidad en resolución de problemas, su autoestima aumenta y su impacto a los objetivos de la organización también.
En resumen: la automatización de tareas repetitivas tiene también un impacto directo en el bienestar de las personas y la productividad de los equipos.
Portal interno del desarrollador
Un elemento central sobre el que orbita una estrategia de DevEx es el portal interno del desarrollador. Sobre la base sólida que nos dan los elementos descritos anteriormente toca centrarse en la experiencia nuclear del desarrollador. De manera análoga a otros enfoques de experiencia, trazamos los recorridos del desarrollador (developer journeys) y los utilizamos para diseñar una experiencia única en su doble acepción: única porque es un reflejo de las necesidades y expectativas de los desarrolladores de manera diferenciada al resto de roles de la organización, y única como reflejo de su alta calidad e impacto en la satisfacción.
Imaginemos el primer día de un desarrollador en un nuevo equipo. Bastante sobrecogedor por la cantidad de información que se espera que conozcan y la dificultad para obtenerla. Muchas veces, por no decir casi todas, se recurre al conocimiento tribal. Trocitos de información que va circulando conforme hace falta, perseguir a compañeros de equipo o esperar a que alguien esté disponible un par de horas para que te haga una sesión rápida de bienvenida. Es lo normal: pasan días o incluso semanas hasta poder completar la primera tarea asignada, y mucho más hasta ser completamente productivos ya integrados en el nuevo equipo. Obviamente, no estamos aun en Matrix y no podemos aprender kungfú en un minuto, sin embargo, una buena implementación de los recorridos del desarrollador ayuda a mejorar la experiencia de aterrizaje a un nuevo equipo.
Un portal interno del desarrollador típico proporciona acceso rápido a muchas de estas necesidades:
- ¿Dónde está el código fuente de la aplicación en la que se supone que tengo que trabajar?
- ¿Qué entornos tengo disponibles para probar mis cambios?
- ¿Qué procedimientos de validación, como chequeos de código o pruebas, tengo a mi disposición?
- ¿Cómo puedo saber qué tareas tengo asignadas y cómo puedo informar del tiempo que necesito para terminarlas?
- ¿Cómo puedo avisar a mis compañeros o a otros equipos de una dependencia que podría bloquearme en una tarea?
- ¿Dónde está la documentación funcional o técnica que necesito para entender mis tareas y cómo realizarlas?
- ¿Hay componentes reutilizables, como arquetipos, librerías, APIs de negocio, que me puedan ayudar a completar mi tarea en menos tiempo y con más calidad?
Cada una de estas preguntas, y muchas otras, forman parte del developer journey, como si de historias de usuario en una solución de negocio se tratara.
Su implementación dentro del portal permite a los desarrolladores tener toda la información que necesitan para hacer su trabajo, cada tarea conectada con las recomendaciones de arquitectura, buenas prácticas o ejemplos que ayuden a completarla a tiempo y con calidad.
El uso de la palabra portal no es casual: es un enfoque visual, basado en roles y responsabilidades, cuadros de mando especializados para que cada rol dentro del equipo vea prioritariamente lo que más le puede interesar, y personalizables para dar cabida a usos variados, no previstos, o simplemente preferencias personales.
Ejemplo de una parte del cuadro de mando de bienvenida de un portal interno del desarrollador construido con Port (getport.io).
Un portal interno del desarrollador también puede ser una extensión de la estrategia de puesto de trabajo en las organizaciones. Siendo breves: no basta con proporcionar a los desarrolladores con un ordenador corporativo con el software base necesario según las políticas de la organización; ni siquiera una versión del puesto de trabajo específica para los desarrolladores es suficiente. «¿Desarrolladores de qué?» Según el rol o la tecnología, incluso en función del proyecto, las herramientas cambian. No hay una talla única que pueda acomodar a todos y tampoco es una opción tener un puesto de trabajo con todo el software relevante para algún miembro de la organización.
El enfoque cambia. La organización construye un catálogo de aplicaciones y servicios aceptables con la colaboración estrecha de las comunidades de práctica, de manera que los intereses de todos estén representados. Sobre ese catálogo se construye un mercado (marketplace) digital donde los miembros de los equipos puedan acceder y elegir qué necesitan y poder instalarlos a golpe de click en su ordenador.
Como un app store, pero para las necesidades de los desarrolladores.
Un portal interno del desarrollador no se queda en facilitar el acceso al conocimiento o a la instalación de aplicaciones. Un catálogo bien construido aportará también acceso fácil a servicios relacionados con los entornos donde se validan y ejecutan las soluciones. Ya sean entornos cloud, on-premise o software como servicio, desde un portal interno se debe facilitar el acceso a cada uno de ellos, simplificar la creación de nuevos entornos o el despliegue de nuevos componentes en un entorno existente, así como controlar todo el ciclo de vida de las soluciones de negocio. Desde una base de datos a un servicio de mensajería distribuida. Desde crear un nuevo repositorio de código a solicitar un espacio colaborativo para trabajar en equipo. Desde desplegar un MVP en un entorno de desarrollo a realizar un pase a producción de una solución compleja sin interrupción para el negocio.
Es un enfoque basado fuertemente en el autoservicio y la automatización para conseguir que los equipos sean lo más independientes posibles del resto de equipos. Cuanto más rico el catálogo a disposición de los equipos, menor será la dependencia y la fricción. La organización gana en agilidad por su capacidad para adaptarse a nuevas necesidades y gana en la observabilidad de los usos de recursos tecnológicos necesarios para sus soluciones.
Ingeniería de Plataformas
Si justo acabo de hablar de autoservicio y automatización como claves, y claramente un portal interno del desarrollador nos da la frontal con capacidades de autoservicio, ¿cuál es la mejor manera de enfocar la estrategia de automatización?
Opciones hay numerosas, cada una con sus pros y contras, pero la que en mi experiencia más beneficios aporta a medio y largo plazo por su capacidad para escalar es la ingeniería de plataformas.
Lo primero que debemos tener claro es que la ingeniería de plataformas es un espacio mucho más amplio de lo que es DevEx o DevOps.
El primer principio base de toda plataforma es abstraer la complejidad de los elementos necesarios para una solución o grupo de soluciones comunes. En lugar de reinventar la rueda con cada necesidad, se identifican los elementos comunes, se prescriben blueprints de referencia que luego se puedan implementar en múltiples ocasiones. Esos elementos de referencia, a modo de bloques de construcción de un juego de LEGO, se abstraen bajo una interfaz de servicios con APIs fáciles de usar, para que sea muy sencillo implementarlos de manera repetida por distintas soluciones, así como integrarlas con elementos externos a la plataforma.
El segundo principio base en la ingeniería de plataformas, que complementa al anterior, es el balance entre estandarización y autonomía. Cuando se limita la capacidad de innovar, cuando se ponen impedimentos a equipos y desarrolladores que necesiten piezas diferentes, se genera fricción y resentimiento entre equipos y la gente se «busca la vida» aprovechando las rendijas del sistema y ocasionando la aparición de plataformas en la sombra. La clave por tanto es diseñar componentes y servicios reutilizables que sean modulares, abiertos a la composición, que realmente los equipos puedan usarlos en una variedad de escenarios, sobre todo en escenarios que no estaban pensados de antemano. Se deben definir líneas rojas que actúen como guardarraíles para la organización en su conjunto, así como para los equipos, pero sin restringir demasiado hasta el punto de estrangular. Seguro que habéis oído en alguna ocasión que «el control mata a la innovación». Pues una buena estrategia de plataformas debe dar a la organización del control justo y necesario, pero ni una pizca más. Habilitar innovación con seguridad y tranquilidad mientras se promueven prácticas sostenibles en el tiempo. No aspirar a crear soluciones universales que no resuelvan ningún problema. Así dicho parece fácil, pero no lo es.
Plataformas hay muchas y variadas por su función o momento del ciclo de vida en que se utilizan.
Tenemos plataformas orientadas al tiempo de desarrollo, e.g.:
- Plataforma de ciclo de vida de las aplicaciones.
- Plataforma de gestión de la configuración.
- Plataforma de CI/CD.
- Portal interno del desarrollador.
También las plataformas para el tiempo de ejecución, e.g.:
- Plataforma de contenedores.
- Plataforma de observabilidad.
- Plataforma de datos.
- Plataforma de mensajería distribuida.
- Plataforma de integración.
La ingeniería de plataformas también aplica a las plataformas verticales por dominio de negocio, también llamadas a veces plataformas empresariales. Es decir, plataformas como las que ofrecen SAP, Salesforce, Oracle, Microsoft, ServiceNow y muchas otras compañías. Y, también, a las plataformas de negocio que nuestros clientes implementan a medida. Plataformas de comercio electrónico, plataformas de seguros, plataformas de banca online, plataformas de gestión de las cadenas de suministro, etc.
Todas ellas tienen impacto en la DevEx a lo largo del ciclo de vida de aplicaciones, servicios y productos. Unas nos van a facilitar crear y llevar el cambio hasta los usuarios, otras son la base sólida sobre las que ejecutar las cargas de trabajo con fiabilidad, disponibilidad y observabilidad, ya sean productivas o no productivas.
Tomemos como ejemplo una plataforma orientada al desarrollo. ¿Qué tipo de funcionalidades nos permite abstraer y podemos integrar con un portal interno del desarrollador? Por ejemplo:
- Solicitar la creación de un nuevo espacio de trabajo para un proyecto.
- Solicitar la creación de uno o varios repositorios de código.
- Crear un repositorio de código a partir de un arquetipo de componente disponible (p.ej. un microfrontend con Angular o un microservicio con Spring Boot).
- Gestionar los permisos para acceder al proyecto y al código con distintos roles: responsable, desarrollador, colaborador, etc.
- Solicitar la creación de un entorno cloud para usarlo como entorno de prueba.
- Solicitar la creación de entornos productivos con estrategias de resiliencia dentro de catálogo (redundancia, escalabilidad, región única o multirregión, etc.).
- Definir una estrategia de entrega que involucre distintos componentes, aprobaciones, paralelización de tareas, o puntos de control.
Y muchas, muchas más capacidades.
Combinando una estrategia de plataformas sólida, con automatización basada en APIs, y la integración de esas APIs con el portal interno del desarrollador, se consigue materializar el impacto positivo en la DevEx que tanto desean las organizaciones.
Conclusión: Los beneficios de DevEx
La adopción de una estrategia que redunda en la experiencia del desarrollador aporta a las organizaciones beneficios múltiples.
Para empezar, tiene un impacto positivo en la agilidad de negocio de la organización, permitiendo mejorar el tiempo a mercado de nuevas soluciones o evoluciones de soluciones existentes.
Ayuda a conseguir que el momento de arrancar una nueva solución o proyecto o el momento de dar la bienvenida a nuevas personas al equipo sean experiencias fabulosas, fáciles, sin traumas.
Cada tarea que se automatiza y cada flujo de trabajo que se optimiza conlleva ahorros a la organización por la mejora en productividad. Serán capaces de hacer más con los recursos disponibles, y cuando ya cumplan sus objetivos, optimizar el coste total de propiedad.
Contar con plataformas de ingeniería robustas, fiables y operables, impacta positivamente en la DevEx durante todo el ciclo de vida de las soluciones, ya sea en actividades de mantenimiento, correctivos, soporte a usuarios, parcheos, o actualizaciones de infraestructura y componentes de las plataformas. Además, consigue mejorar la experiencia de los usuarios: funciona bien, en cualquier momento y desde cualquier lugar.
Todo lo anterior se aplicará con flexibilidad para ajustarse a necesidades específicas de ciertas soluciones o equipos. Por muy completos que sean los catálogos de arquetipos o de servicios de plataforma siempre debe existir la opción de salirse del camino trazado. De lo contrario se limitan las opciones que nos brinda la tecnología y se podría perder una ventaja competitiva. Habrá líneas rojas en la organización, p.ej. relacionadas con el cumplimiento de las políticas de seguridad, pero fuera de esas líneas no debería haber nada prohibido.
Finalmente, se mejora la moral y la retención de los empleados que sentirán una mayor vinculación con su organización, una mayor implicación con los objetivos del negocio al entender las razones por las que su trabajo es necesario, así como el valor añadido que representa su participación en el equipo.
Los beneficios de DevEx
En definitiva, felicidad y fabulosidad en los equipos de desarrollo.
En el próximo artículo de la serie continuaré profundizando en conceptos claves de nuestro entendimiento de DevOps y conectando totalmente con lo recién visto hablaré en detalle de la ingeniería de plataformas (platform engineering) desde la perspectiva de su impacto tan positivo en la adopción de principios y prácticas DevOps.
Sobre el autor
Jorge Hidalgo es director de ingeniería de software en Accenture, responsable de DevOps en Accenture Iberia y de la unidad de Arquitectura y Plataformas Cloud y DevOps en Accenture EMEA South Advanced Technology Center, y es también responsable globalmente en Accenture de la comunidad de práctica Java. Jorge es un Java Champion desde 2023.
Jorge cuenta con más de 25 años de experiencia en la industria, principalmente con tecnologías Java, web, cloud, DevOps, agilidad y ciberseguridad. Además de desarrollar su actividad profesional con clientes, es una figura activa en las comunidades tecnológicas, tanto como ponente en numerosos eventos locales e internacionales, como liderando la actividad de comunidades como Málaga JUG, Málaga Scala Developers y BoquerónSec, así como colaborando en la organización de eventos como OpenSouthCode o Codemotion.
