8. oct., 2019

Características de la Arquitectura Ágil

En este artículo queremos mencionar las principales caraterísticas de la arquitectura ágil resultado de la investigación de diversos artículos escritos por arquitectos y agilistas expertos en éste tema.

Así cómo los arquitectos tradicionales realizan procesos de modelado de construcciones a un alto nivel de abstracción, proveen posibles alternativas frente a la solución de un problema, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades de un  problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. El arquitecto de sofware hace los mismo en los proyectos de TI.  De esta manera se hace imposible pensar que un rascacielos de 300 metros pueda ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales y aplicaciones - Apps puedan ser implementados de manera estable sin una arquitectura bien concebida.

De acuerdo con lo que dicen los autores Bass, Clements y Kasman - “La arquitectura de software de un programa o sistema informático, es la estructura o estructuras del sistema, que incluyen elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos.” Esta definición nos lleva a concluir que la arquitectura de software brinda una garantía de calidad del desarrollo de software y permite tener un sistema que cumpla con los requerimientos funcionales y no funcionales que el cliente espera. Por otra parte, la arquitectura es clave en la reutilización de artefactos de software en sistemas de líneas de productos de software, es decir, que influye en la eficiencia de manera directa. 

El autor Charlie Alfred dice textualmente : “La arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum”.

Teniendo presente la importancia de la arquitectura en el mundo del desarrollo de software, mencionaremos las  principales caraterísticas que se debe tener la arquitectura en un entorno Ágil. Dado que en los entornos actuales (VUCA) como ya hemos mencionado en artículos previos las condiciones son un poco diferentes por la velocidad que el cambio trae al mercado.

"Características de la arquitectura Ágil":

1. Arquitectura Incremental: Para iniciar, hay muchas personas que consideran que al iniciar el proyecto se debe contar con todo el diseño de la arquitectura (claro y detallado) antes de iniciar el trabajo por parte de los desarrolladores o el Sprint 1 y tenemos que es por ello que en la metodología tradicional ésto tomaba mucho tiempo de análisis - generando la no producción de ningún entregable en una fase inicial. Al fenómeno de diseñar a la perfección le llaman algunos autores "Big Design Upfront". Este enfoque ha sido  ampliamente criticado en los últimos años por quienes adoptan marcos de trabajo ágiles. Bajo un enfoque ágile se habla de una arquitectura base que tiene evolución a lo largo del proyecto, es decir, una arquitectura incremental. Se desconfía de un gran modelo de diseño y lo que se busca es definir la arquitectura mínima con la cual se podría iniciar la operación del primer entregable o en mejores términos del Mínimo producto viable. De este modo Sprint tras Sprint se pueden ir incluyendo cambios en la arquitectura buscando su optimización. Es importante decir en este punto, que esto no implica que no iniciemos con algunos elementos mínimos de referencia como son : un lenguaje definido, un framework, una base de datos, etc. Es común, también que dentro de una organización tengamos algunos lineamientos, estándares y políticas ya previamente definidas que se deban utilizar y otras que definirá el equipo Scrum de manera colaborativa. Lo que nos deja  abierta la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene para nuestro proyecto.

2. Diseño emergente : Esta es una propuesta respaldada por muchos en los entornos ágiles para el diseño de software, pues considera que el proceso de analisis  y diseño de software emerge cuando sea necesario para entregar los incrementos de cada sprint. Uno de los fundamentos de este enfoque es "la idea del cambio continuo". Aún cuando los requerimientos de software no cambien, en los últimos años la tecnología y la gente sí lo hace, cada vez con más frecuencia. Al finalizar el proceso de desarrollo y entregar los resultados finales, quedará un diseño simple y conforme a lo que fue realmente es necesario, que puede evolucionar con el tiempo siguiendo el mismo método.

3. Definir el propósito del diseño : No debemos olvidar que el propósito del diseño de software es principalmente comunicar de forma técnica las diferentes estructuras y comportamientos de un software, para facilitar su estudio, construcción y mantenimiento, así como la orquestación de los esfuerzos de construcción.

En la academia suele ser admirada y recomendada la notación UML,  que comprende diferentes diagramas y modelos aplicable a distintos niveles del diseño de un software. Esto no significa, que sea necesario diagramar absolutamente todo lo que esté allí definido. En  tanto los ingenieros logren comprender el diseño y construir el software de forma organizada, el propósito habrá sido cumplido. Por tanto, el diseño sólo debe cubrir aquello que sea necesario comunicar y bajo el medio más efectivo y óptimo para hacerlo. No debemos olvidar que a veces "Menos es Más", no quiero decir que no debemos documentar el diseño a lo que me refiero es que lo más importante es tener diseños simples.

4. Flexibilidad: Por la forma en que se construyen las aplicaciones hoy en día, es muy común la adopción de frameworks, el uso de APIs, librerías y de convenciones para facilitar los esfuerzos de construcción. El diseño de estos componentes está previamente definido.

Un desarrollador simplemente debe comprender la arquitectura de estos frameworks y apegarse a las convenciones recomendadas para que su diseño se mantenga consistente, y por tanto, sea fácil de asimilar por alguien más que domine el mismo framework.

Así, muchos aspectos del diseño se reducen a definir la arquitectura del software, sus componentes, aspectos de GUI y UI y UX, estructuras de datos, flujogramas, entre otros elementos estrictamente necesarios para comprender y avanzar.

5. Modelo C4: El autor Simón Brown quien es un consultor independiente en desarrollo especializado en arquitectura de software. Hace aproximadamente 2 años propuso un modelo para diseño de software simple, fácil de navegar y que comunica con más eficiencia.

Su modelo lo llamó Modelo C4, el dice que basta con definir los siguientes cuatro diagramas, relacionados entre sí y navegables en profundidad como si fuese un mapa:

  • Contexto: Visualiza el sistema en la organización, su relación con distintos actores que pueden ser usuarios y otros sistemas.
  • Contenedores: Visualiza la división del sistema en entornos de ejecución o almacenamiento, reflejando mejor la infraestructura.
  • Componentes: Visualiza internamente las piezas que componen un contenedor en particular, como aplicaciones o servicios.
  • Clases: Consiste en un diagrama de clases UML para aquellos casos donde sí sea necesario llegar a ese nivel.

6. Validación continua: Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayude a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de carga, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación. 

Esa validación permanente en el entorno de desarrollo y de QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico y poder tomar mejores decisiones en nuestro modelo de arquitectura.

7. La arquitectura no es solo una tarea del arquitecto: Como mencionabamos previamente, dado que no se diseña la arquitectura por completo desde el inicio y que no es un tema que atañe solo al que tiene el título del "Arquitecto" sino que es un tema discutido por todo el equipo e incluso con el Product Owner y los involucrados del negocio. Y dado que las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista. Nos encontramos también con que las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se va validando en la implementación. Ahora bien, no quiere decir esto que si tu compañía tiene un equipo de Arquitectura Corporativa o Empresarial esto está mal. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación apoyando al equipo y ayudando a tomar mejores decisiones.

Todas estas ideas tienen mucho más contexto y trasfondo. Quisimos en esta pequeña recopilación de información - mostrar un breve resumen de lo que investigamos de algunos artículos revisados y con base en nuestra experiencia en proyectos de TI llevados a cabo bajo  marcos de trabajo ágiles y utilizando Scrum como framework principal.

Si te gustó esta información compártela con familiares, colegas y amigos.

Visita nuestos otros blogs en el siguiente link : http://www.pmpmedellin.com/431433692.

Autor : Ing. Javier León Reyes

Fuentes consultadas:

Paper “Software Architecture in the Agile Life Cycle”  2013. Lo puedes revisar en este link:

https://www.dropbox.com/s/ho52huc71ewe6tz/Arquitectura%20en%20el%20Ciclo%20de%20Vida%20Agil.pdf?dl=0

https://martinalaimo.com/es/blog/arquitectos-agiles

https://jonathan.vargas.cr/es/temas/desarrollo/18287-arquitectura-y-diseno-de-software-en-el-mundo-agil

https://sg.com.mx/revista/30/el-papel-la-arquitectura-software-scrum

https://www.codeandbeyond.org/2018/09/3-elementos-para-una-arquitectura-mas.html