¿Cuando y cómo el trabajo de arquitectura cobra protagonismo en el contexto ágil?

Existen variadas definiciones o perspectivas del concepto "arquitectura". En este post el concepto arquitectura se refiere a la organización externa e interna del producto software. Organización externa en cuanto a los requisitos del producto e interna en cuanto a los elementos/capas/componentes de código del producto.

Una buena arquitectura facilita no sólo el desarrollo del producto sino que especialmente su mantenimiento, facilitando las modificaciones, pruebas y reutilización.

Una de las diferencias técnicas más destacables del enfoque ágil con respecto al tradicional es que en el primero la arquitectura del producto se va definiendo y mejorando con refactorización a lo largo del proceso de desarrollo. En cambio, en el enfoque tradicional la arquitectura en gran parte se establece tempranamente, antes de entrar en las iteraciones de construcción del producto. Ambas estrategias son válidas de cara a conseguir al final una buena arquitectura. En el caso del enfoque ágil su estrategia le permite casi de inmediato comenzar a programar el producto, mientras que en el enfoque tradicional se dedica un tiempo considerable al establecimiento de dicha arquitectura (en base a modelado y especificación del producto que se va a construir) antes volcarse en la programación. La inversión temprana en arquitectura pretende evitar en lo posible que cambios durante el desarrollo tengan alto impacto en lo ya implementado. En el enfoque ágil se asume este riesgo asociado al impacto de los cambios y se paga con continua refactorización.

Las situaciones en las cuales es muy útil realizar un trabajo previo de arquitectura y el cómo hacerlo es un tema escasamente tratado en el ámbito ágil. Gran parte de la literatura ágil está centrada en la gestión de cambios (llamados Ítems, Historias de Usuario, Unidades de Trabajo, o similar) que son de mucha granuralidad, muy pequeños, lo cual ocurre normalmente cuando el producto ya ha alcanzado una cierta estabilidad en su arquitectura, es decir, en  cuando cada cambio individualmente no requiere gran trabajo de arquitectura, especialmente pues se trata de pequeñas mejoras o correcciones de fallos. Sin embargo, cuando se trata de un cambio de gran envergadura (reconocido como "Historia de Usuario Épica"), o en particular cuando se debe establecer y llevar a cabo la primera entrega del producto (primera puesta en producción), es altamente recomendable definir los Ítems con una perspectiva más global e integradora, junto con establecer una arquitectura global que sea adecuada para soportar en conjunto a dichos Ítems.

Si para desarrollar un producto sólo necesitamos definir y concentrarnos en un sprint se simplifica significativamente la planificación y seguimiento (y su explicación). Esta es la situación típica de mantenimiento en la cual cada versión (resultado de un sprint) suele coincidir con una entrega (versión pasada a producción). Todos los cambios enfrentados durante el desarrollo bien se incluyen en el sprint actual (sólo en caso que sean imprevistos urgentes) o bien se incluyen y ordenan dentro del Product Backlog. Sin embargo, cuando enfrentamos el desarrollo de la primera entrega de un producto, o cuando se realiza un cambio de gran envergadura en un producto (posterior a su primera entrega), probablemente se tendrá que trabajar durante varios sprints. En este caso es muy recomendable realizar un trabajo previo de arquitectura tanto desde el punto de vista externo (requisitos y su organización) como interno (componentes de la estructura interna). Este trabajo no tiene porqué igualarse al realizado por un enfoque tradicional, al menos en cuanto a detalle y duración. Para mantener el espíritu ágil, dicho trabajo en arquitectura debería ser más general, corto e intenso en comunicación dentro del equipo.

Con lo anterior hemos establecido el "Cuándo" la arquitectura coge protagonismo, que es precisamente cundo se trabaja cambios asociados a nuevos requisitos o importantes modificaciones de funcionalidad, y particularmente cuando éstos son de gran envergadura, es decir, pueden tener un alto impacto en el producto. Veamos ahora el  "Cómo".

Frente a un nuevo desarrollo o un cambio de envergadura, antes de comenzar a definir Ítems que descomponen dicho trabajo (Historias de Usuario), el equipo se debe concentrar en establecer la Visíón del Producto (o del cambio). Esto conlleva identificar la motivación para realizarlo, problemas que resuelve, necesidades que satisface, características principales, tipos de usuarios que se verán afectados. Desde el punto de vista interno debe definirse a modo general qué capas, frameworks, componentes u otros elementos tendrán que desarrollarse y/o integrarse.

Para este trabajo previo podemos definir un ítem del tipo Épica o realizar este trabajo de visión y arquitectura en paralelo a los sprints que estén en curso (en el caso de un nuevo requisito o mejora de cierta envergadura). Incluso, si se trata de un producto nuevo, este trabajo puede plantearse como una breve fase previa a la planificación de la entrega y al comienzo del desarrollo iterativo.

Dos comentarios finales:

• En muchos contextos de desarrollo ya tiene un reconocimiento explícito el rol "Arquitecto". ¿que hacemos con él? :-). La respuesta sencilla y coherente con el planteamiento de Scrum sería no reconocer ese rol como un título fijo para una persona. El arquitecto estaría dentro del equipo de desarrollo (en rol genérico Development Team) pero sería reconocido como especialista en arquitectura. Así, cualquier miembro del equipo podría realizar trabajo de arquitectura pero teniendo como apoyo al especialista en arquitectura cuando se requiera por las características del cambio involucrado.
• El trabajo de mejora y supervisión contínua de la arquitectura es importante en todos los cambios del producto, sin embargo, se hace más patente en los grandes cambios. Este trabajo puede hacerse de forma ágil, en el sentido que su intensidad y profundidad sea acorde al riesgo del posible impacto del cambio, y acorde también con el consecuente "castigo" que conllevaría la correspondiente refactorización. No hay recetas específicas, pero claramente conocemos los extremos: invertir mucho en arquitectura para rentabilizarlo (o no rentabilizarlo) en el futuro, o invertir poco en arquitectura y pagar mucho (o poco) por el refactoring en el futuro (debido a la llamada Deuda Técnica o Technical Debt). Lo sensato sería evaluarlo para cada situación y tomar la decisión asumiendo el correspondiente riesgo.

Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com