¿Cómo se crea una arquitectura de software ágil?

Recientemente estuve en un curso de Raúl Herranz del que me gustó mucho como trató uno de los temas que más cuestan de transmitir, la arquitectura de software ágil. En su curso se basó entre otras en el artículo de Diego Fontdevila y Martín Salías "Software Architecture in the Agile Life Cycle".

En Agilidad desaparece la figura del arquitecto de sistemas que crea arquitectura, y esta se envía hacia abajo, es el propio equipo el que hace emerger la arquitectura de software y esta es recogida posteriormente por el área de arquitectura que crea estándares basados en experiencia real. Ocurre algo semejante la figura del jefe de proyecto, que es inexistente, y cuya gestión que es superada con creces por la autoorganización del equipo.

Recordemos el undécimo principio del Manifiesto Ágil:

Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados

Nos está diciendo que la responsabilidad compartida diluye el rol tradicional de arquitecto, que la arquitectura es creada por el equipo y este participa al completo en el diseño, comprendiendo las implicaciones de las decisiones de diseño, y evaluándolo de manera continua.

Mencionaré dos aproximaciones arquitectónicas: 

SASHIMI

APIs a modo de lonchas de sashimi

Trata de ir construyendo la arquitectura a base de ir agregando APIs a modo de finas lonchas de sashimi hasta llegar a la arquitectura deseada, a modo de símil la arquitectura emergerá como el salmón al agregar las lonchas.

Trata de de construir la cantidad mínima de código de infraestructura para conectar todas las piezas del sprint, Mínimo Producto Viable (MPV), o release, y empezar a construir para dar una rápida experiencia de los resultados tanto al equipo como los interesados de negocio. El foco está a nivel de API, estas se escriben con una implementación emergente. En algún momento cuando lleguen pruebas de carga, o de estrés quizá, se requiera de un tuning fino para aumentar la robustez de estas APIs, ese será el momento de adaptar y refactorizar.

CEBOLLA

La arquitectura en cebolla se basa en una aproximación en cinco pasos:

Visión técnica: es de alto nivel y proporciona una línea base conceptual que servirá como punto de referencia para enfocar el trabajo futuro y chequear la necesidad de realizar refactorizaciones. 

Arquitectura ágil en cebolla

Módulos: establece el conjunto de módulos de servicio que proporcionan valor real a los usuarios, se basan en una separación coherente de funcionalidades, por ejemplo módulos de facturación, contabilidad, seguros, créditos, seguridad...

Capas y niveles de solución: 
- Las capas son diferentes niveles de abstracción en términos de valor a nivel de usuario, por ejemplo: presentación, lógica de negocio y datos.
- Los niveles son la forma en que las capas lógicas se encuentran distribuidas de forma física, por ejemplo sistemas cliente/servidor son a dos niveles.

Componentes y servicios: define los componentes y servicios como piezas empaquetadas de software cuyas funcionalidades son muy específicas y están definidas por sus interfaces.

Clases y funciones: finalmente, en nivel más alto está este en que los miembros del equipo escriben el código en lenguajes de programación y ficheros de configuración.

Todos los niveles de la arquitectura en cebolla son refactorizados continuamente sin perder la sincronía. Los niveles inferiores se suelen estabilizar antes, la refactorización es como una ola de abajo a arriba que se va absorbiendo de manera que la visión técnica sea la más invariable.

Como hemos visto el equipo al completo participa en el diseño, en la práctica lo hace con:

• Discusiones sobre arquitectura en las reuniones de planificación de sprint y revisión de sprint.
• Reuniones de diseño donde el equipo expone sus ideas abiertamente frente a una pizarra o una hoja de rotafolio en blanco.
• Exponiendo permanentemente las guías de diseño, incluyendo diagramas, checklists y diagramas de referencia en las paredes de la war room.