Table of Contents
Los días 3 y 4 de octubre de 2022, Apiumhub organizó el Global Software Architecture Summit (GSAS) en Barcelona. Un evento que reunió a más de 460 expertos del sector para aprender sobre métricas de arquitectura de software. Además de contar con charlas de expertos del sector, GSAS también contó con talleres prácticos en los que los ponentes introdujeron algunos temas de debate. Los talleres de GSAS fueron estupendos para debatir, aportar ideas y desarrollar soluciones.
Tuve la oportunidad de asistir al taller de GSAS «Conviértete en una empresa de diseño de software», que presentaron Michael Keeling, ingeniero de software de Kiavi, y George Fairbanks, ingeniero de software de Google. Este último tuvo que presentar a distancia, ya que no pudo asistir a la conferencia. Querían demostrarnos cómo podían aplicar eficazmente cambios significativos en sus empresas, de modo que pudiéramos utilizar las lecciones aprendidas para mejorar nuestras propias experiencias.
Había una vez…
En el taller de GSAS, Keeling y Fairbanks explicaron que habían prestado un servicio completamente nuevo a sus clientes con éxito en un periodo de tiempo relativamente corto. Fueron capaces de gestionar ese cambio porque previamente habían aprendido que el diseño de software era una parte central de cómo desarrollaban software. Todos los miembros del equipo estaban alineados con ese mantra.
Pero para llegar a ese punto, tuvieron que superar algunos retos, porque la idea de tener un equipo que sepa de todo es ideal, pero dista mucho de la realidad. Siempre hay muchas cosas que superar:
- Habilidades que faltan
- Lagunas de conocimiento
- Centrarse en las características
- Pensamiento a corto plazo
- Deuda tecnológica
- Miedos, incertidumbres, dudas
Sin duda, se trata de problemas bien conocidos con los que puede encontrarse cualquier organización, y debemos saber cómo manejarlos. Lo consiguieron aprendiendo a utilizar diversas herramientas, pensando en distintas formas de avanzar, y poco a poco teniendo un equipo mejor haciendo algunos ejercicios como, por ejemplo:
- Atascos en la pizarra
- Arquitectura de jardines
- Ejemplos de asignación
- Documentos de diseño concisos y completos
- Debates sobre el diseño durante la revisión del código
- Registros de decisiones de arquitectura (ADR)
- Guías arquitectónicas
- APIs como contratos
- Prueba de las normas de diseño
En pocas palabras, las empresas de diseño de software sitúan el diseño en el centro de su práctica del software.
¿Qué ocurre cuando no se piensa en el diseño?
Al escribir cualquier software, si no se piensa en el diseño (que al final es otro «tipo» de diseño), tarde o temprano nos encontraremos con problemas. Escribir software debería ser algo más que tirar líneas en nuestro IDE porque, a corto plazo, te encontrarás con muchos problemas como:
- Las «feature treadmills» rara vez (o nunca) se detienen a diseñar
- Producción rápida de un montón de funciones
- Nuevas funciones «atornilladas»
- La arquitectura puede o no ser un buen fit
- Aumenta la deuda técnica
- Con el tiempo se ralentiza el desarrollo
- Algunas funciones nuevas son inviables
- Reescribir es la única opción
Premisa
Para convertirse en una empresa de diseño de software, los desarrolladores deben desarrollar sus habilidades de diseño de software.
Marco IMEO
Con esa premisa en mente, presentaron cómo llegar a ese punto y cómo conseguir que todo el mundo esté suficientemente informado: utilizando el Marco IMEO. Se trata de una herramienta de planificación para ayudar a averiguar cómo difundir las ideas de diseño de software en toda una organización. Se divide en 4 partes, que pueden seguirse en cualquier orden:
Idea
Conocimientos o habilidades invisibles. ¿Cuáles son las habilidades que queremos compartir? Por ejemplo, conocimientos sobre patrones, paradigmas orientados a objetos o funcionales y modelado de dominios.
Medio
Una actividad o artefacto visible que difunde una idea. ¿Cómo compartiremos la idea? Ejemplos: revisiones de diseño, revisiones de código, documentos de arquitectura, ADR, formación, tormenta de riesgos, clubes de lectura, blogs internos, programación en parejas y sonnarQ.
Punto de entrada
El público objetivo inicial dentro de la organización para una idea de diseño. ¿Quién va a ser el primero en probarla? Ejemplos: jefes técnicos, equipos que sufren, nuevos empleados, particulares…
Obstáculos
Lo que puede impedir que una idea se difunda en un medio determinado. ¿Cuáles son las posibles dificultades que encontraremos al compartir la idea? Ejemplos: egos, tropezones organizativos, falta de mentores…
En resumen, para cualquier nueva idea de diseño, selecciona un medio, identifica un punto de entrada y elimina los obstáculos que impiden o ralentizan la adopción. Persistencia. Repetir tantas veces como ideas se quieran difundir.
Un ejemplo
Un equipo decide empezar a escribir ADR (registros de decisiones de arquitectura) que ayudan a llevar un registro de las decisiones arquitectónicas junto al código, para estar al tanto de todos los cambios a lo largo del tiempo.
Pero, por supuesto, van a enfrentarse a obstáculos innombrables como :
- Obstáculo 1: El diseño infravalorado – «¡Sólo quiero escribir código!».
- Enfoque: Tocar un «primer compañero» Establecer la política del equipo.
- Obstacle 2: Missing skills – architecture decisions, how to write an ADR
- Enfoque: Coaching a través de Pull Requests
- Obstáculo 3: Presión del calendario: «No tenemos tiempo para escribir documentos».
- Enfoque: Jefe técnico: «Los ADR son cortos. Hagamos un experimento».
Así, al principio, el punto de entrada es el líder técnico de un equipo piloto, y es el único que escribe ADRs. Una vez definido el formato, el jefe de enseñanza elige a un miembro del equipo que empieza a escribir las ADR con su ayuda, que puede ser por emparejamiento o mediante revisiones en un pull request. A partir de aquí, el conocimiento se difunde a todos los miembros de la empresa, que empiezan a escribir los registros de documentación. Por supuesto, necesitan persistencia para mantener la práctica. A largo plazo, todos han incorporado el hábito, y ahora cualquiera puede escribir un ADR para documentar cada cambio arquitectónico en el proyecto.
Nuestro taller de GSAS
En pequeños grupos, estuvimos hablando durante el taller sobre cuestiones generales que teníamos en nuestros propios proyectos, y sobre cómo podíamos aplicar el marco IMEO y tener al menos un plan procesable para introducir ideas de diseño importantes en tu organización. En nuestro grupo, se nos ocurrió:
- Idea: Queríamos aplicar buenas prácticas entre todos los miembros del equipo.
- Medio: El uso de actividades para difundir este conocimiento podría hacerse con pair/mob programming frecuente explicando cómo escribir código con pruebas, aplicando patrones….
- Punto de entrada: los miembros menos experimentados de la plantilla.
- Obstáculos: Los egos pueden ser un problema al que hay que enfrentarse cuando se enseña a la gente a hacer las cosas de una manera distinta a la que están acostumbrados. El tiempo siempre es una limitación, pero es una inversión importante para todo el proyecto.
Conclusiones del taller de GSAS
El marco IMEO define puntos concretos para la difusión de una idea en el equipo. Pide tiempo para reflexionar sobre un problema y buscar soluciones reales, las que se pueden aplicar desde el principio.
El marco se compone de unos pocos puntos sencillos que no te ayudarán por sí solos a menos que pongas en práctica los resultados, pero da pautas particulares que pueden ayudar al crecimiento del equipo. ¡Pruébalo!
La edición de este año de GSAS tendrá lugar los días 9, 10 y 11 de octubre en el Auditorio Axa de Barcelona. Consigue aquí tu entrada para disfrutar de dos días completos de charlas de expertos del sector y una jornada extra de talleres prácticos.
