El Bruno

Hola!

Feliz Navidad y si algún malpensado no entendió el título, es “Forget the architects !!!”. Durante los últimos años, en grandes organizaciones siempre me he encontrado al “equipo de arquitectura”. Este equipo, puede estar formado por una o más personas y usualmente son los encargdos de tomar grandes decisiones de arquitectura para los equipos que desarrollan productos o aplicaciones.

Este proceso suele ser muy burocrático, y esto significa que los equipos de desarrollo tienen que esperar un tiempo X (digamos 3 meses) antes de poder a comenzar a construir software. Además de todos los problemas que tiene un enfoque waterfall como el que describo, la situación mas general es que cuando se comienza la construcción de software, surgen cambios y modificaciones que tienen que ser implementadas por el equipo de arquitectura, luego compartidas con el equipo de desarrollo y … de vuelta a empezar.

Los 2 párrafos anteriores rompen con todos los principios que proponen prácticas como SCRUM. Un equipo que practica SCRUM deja que la arquitectura emerja a medida que se construye el software. Si bien estamos acostumbrados a planificar los aspectos de la arquitectura, debemos comprender que este enfoque no deja de lado la arquitectura de software sino que deja que la misma vaya aportando valor al software que se construye a medida que el mismo avanza.

Esto no es una tarea fácil y requiere de equipos altamente suficientes (equipos profesionales no aficionados); personalmente yo todavía no me siento cómodo sin un diseño inicial. Seguramente los primeros pasos serán en falso, y tendremos que volver sobre los mismos varias veces antes de dar con el enfoque correcto. Sin embargo, esta es la base de un proceso emergente (en inglés queda mejor incremental planning o incremental design). Tenemos que aceptar la realidad de no conocer todas las variables que nos afectan como equipo al principio del proyecto y una vez asumida esta realidad comenzar a trabajar (y a hacer rework en muchos casos). Finalmente tenemos que comprender que los beneficios del rework se ven cuando el producto comienza a tomar forma.

Por supuesto que todo este trabajo / rework se debe realizar sin perjudicar la calidad con buenas prácticas como integración continua, BDD, etc. Aquí me remito al gran Rodrigo Corral cuando escribió sobre “la calidad en el software no es opcional” (y mira que tiene años el post). Una frase o principio que es bueno tener en cuenta si quieres comenzar a trabajar con este enfoque es

Think Big, Act small, Fail fast and Learn Rapidly

(traducción by el Bruno: Piensa en grande, actúa en pequeño, equivócate a menudo y aprende rápidamente)

Esta frase del libro “Lean Software Development” de Mary y Tom Poppendieck representa en 4 sentencias los principios básicos con los que un equipo debe trabajar. Si lo trasladas al día a día de un desarrollador, lo comprenderás enseguida; y si lo piensas desde el punto de vista de un “arquitecto de software”, verás que el principio es el mismo.

Otro punto importante a tener en cuenta es que todas las decisiones de arquitecturas tienen que estar soportadas por código. Se acabó el rol de los expertos en Visio, las arquitecturas emergentes son aquellas que son parte de un producto, comprobadas con su set de tests y finalmente probadas por el producto que se construye. No digo que es necesario olvidarse de diagramas y de dibujos, sino que estos diagramas representan código existente, que es donde realmente vive un producto.

Nota: En este aspecto Visual Studio ALM hace un trabajo excelente !!!

Recursos:

• Mi visión sobre el cono de incertidumbre (link)
• La calidad en el software no es opcional (link)
• The Land that scrum Forgot by Uncle Bob (link)

Saludos @ La Rancherita

El Bruno

Google