¿Por qué teníamos la misma discusión arquitectónica una y otra vez en cada sprint? (Por Que Teniamos La Misma Discusion Arquitectonica Una Y Otra Vez EN Cada Sprint)

¿Por qué teníamos la misma discusión arquitectónica una y otra vez en cada sprint?

Estaba trabajando en una startup tecnológica de rápido crecimiento en Estambul. Durante la pausa del almuerzo, salí a caminar por el parque con el desarrollador senior del equipo. Me contó con entusiasmo sobre las características de la próxima aplicación móvil, los nuevos módulos que se agregarán y las presentaciones para inversionistas.

Escuché y formulé esta sencilla pregunta: "¿Dónde está entonces el diagrama arquitectónico? ¿Dónde documentamos estas decisiones?"

Me miró con una sonrisa. No había ningún plan. Revisé un "Manual de arquitectura de software" del sistema, no había ni siquiera un simple borrador. La forma en que el gerente recostaba la cabeza sobre la almohada por la noche y se despertaba con una nueva idea por la mañana determinó nuestra arquitectura ese día. Un error momentáneo del cliente arrojó todo el sprint a la basura. El proyecto no avanzaba, simplemente se lo llevaba el viento. (De hecho, no me sorprendió cuando más tarde escuché que integraron la IA en ese proyecto de la noche a la mañana porque era popular).

Mientras caminaba por el parque ese día, me di cuenta de que no es el "código incorrecto" el que hunde los proyectos de software. Lo que hunde los proyectos; Fue la vaporización del conocimiento arquitectónico. Tomaríamos una decisión, olvidaríamos por qué la tomamos y 3 meses después volveríamos a discutir la misma decisión. Éste fue el primer frente en el que declaré la guerra como líder técnico.

La terquedad del "conocimiento tribal" de las empresas tradicionales

Después de ver este caos, mi primera pregunta en cada entrevista que tuve fue: "¿Cuál es su proceso de gestión de proyectos y cómo toma decisiones técnicas?"

Unos años más tarde, conseguí una entrevista en el departamento de I+D de una empresa de fabricación tradicional. El gerente frente a mí comenzó cuestionando mi profesionalismo porque no llevaba traje. (Sin embargo, anteriormente había realizado un trabajo crítico para esa empresa desde afuera, él ni siquiera era consciente de ello).Le pregunté si utilizan Jira, procesos ágiles y documentación técnica. La respuesta que recibí fue la dura realidad de la industria: "Los hemos probado, pero no nos convienen. En la reunión anotamos quién hará qué en un cuaderno y procedemos en consecuencia".

Incluso si se aprobara la contratación, rechacé esa oferta en ese momento. Porque la arquitectura y el destino de un proyecto no se pueden confiar a las tenues tintas del libro de reuniones de alguien.

Teatro de decisiones y caos operativo

Posteriormente me involucré en un gran proyecto de transformación logística. Cuando entré al sistema, me llevó un mes completo entender quién estaba haciendo qué. La gestión de proyectos era cero, la memoria técnica era cero.

Inmediatamente me arremangué. Introduje el modelo de negocio Agile, establecí sprints de 2 semanas, integré Jira e introduje stand-ups diarios. Todo iba genial. Pero hay una realidad en el sector privado: cuando se aporta transparencia y memoria institucional al sistema, quienes obtienen poder a partir del "conocimiento tribal" (secretos que sólo ellos conocen) se sienten amenazados.

El acoso ha comenzado. Intentaron quitarme el control. En ese momento, las impresiones ADR (Registros de decisiones arquitectónicas) que creé ni siquiera fueron revisadas. Después de un sprint, el gerente vino y dijo: "¡No sé por qué cambiamos esta base de datos de esta manera!". dijo. Todo estaba escrito, pero no lo leyeron. Nuestra documentación se había convertido en un "Teatro de Documentación de Decisiones".

Fue entonces cuando me di cuenta: usar una sola herramienta (Jira, ADR) no es suficiente. Es necesario inyectar esa herramienta en las venas objetivo (OKR) de la empresa.

El sistema que acaba con el caos de proyectos: ADR (Registro de decisiones de arquitectura)Hoy en día, operamos este sistema a la perfección en la infraestructura de la plataforma global de comercio electrónico que administro como desarrollador principal (con un equipo de 6 a 7 personas). Cuando comencé el proyecto, todavía había confusión; Se estaban abriendo problemas en GitLab, pero "¿Por qué hacemos esto?" No hubo respuesta a la pregunta.

Inculqué el espíritu ágil en el equipo y, lo más importante, mapeé los principios ADR (Architectural Decision Record) de Michael Nygard directamente a los objetivos trimestrales anuales (Q1, Q2, Q3, Q4).

Entonces, ¿qué es ADR y por qué salva la vida de todos los ingenieros? Los ADR son registros inmutables que almacenan no sólo cuál fue una decisión arquitectónica, sino también por qué se tomó y qué compensaciones se aceptaron, justo al lado del código.

Cuando tomamos una decisión ahora mismo, la registramos con esta plantilla simple pero muy efectiva:

Contexto: ¿A qué problema nos enfrentamos? (Ejemplo: las consultas de cesta cansan la base de datos).

Decisión: ¿Qué estamos haciendo? (Ejemplo: usaremos Redis Cache).

Alternativas (Descuidar): ¿Qué eliminamos? (Por ejemplo: eliminamos la ampliación de la base de datos debido al costo).

Consecuencias/Consecuencias: ¿Qué arriesgamos? (Ejemplo: la latencia de datos disminuirá, pero se agregará complejidad de invalidación de caché).

Resultado: No más "¿Por qué?" No preguntamos

Hoy en día, en las reuniones de sprint o en las presentaciones de gestión, nadie pregunta: "¿Por qué lo hicimos de esta manera?". No lo dice. Porque debajo de cada objetivo se esconde un ADR como una puerta.

Si un nuevo desarrollador de software se une al equipo (Onboarding), no le explicamos la arquitectura durante días. Solo proporcionamos registros ADR. Decimos: "Lea nuestra historia, comprenda qué guerras libramos y por qué elegimos estas armas".El secreto para acabar con el caos; No se trata de escribir códigos sofisticados, se trata de "¿Por qué?" detrás de esos códigos. cuestión en un legado corporativo. Cada decisión arquitectónica no documentada es una deuda técnica con altos intereses que tendrás que pagar en el futuro. Realice el pago hoy guardando su justificación.

Estimados amigos arquitectos de software y líderes técnicos; En sus proyectos, ¿las decisiones se pierden en un desierto Wiki o viven en el corazón del código?

Serie de manuales de arquitectura

#1: ¿Por qué teníamos la misma discusión arquitectónica una y otra vez en cada sprint? (Este artículo estás leyendo)

#2: Principios de ingeniería que un arquitecto de software aprendió de la experiencia (próxima publicación)