jueves, 6 de marzo de 2014

Arquitectura en proyectos ágiles

Esta entrada pretende mostrar cómo se pueden implementar arquitecturas ágiles en los proyectos con el fin de disminuir riesgos que se transformen luego en deudas técnicas impagables. El punto de partida es la afirmación de que "las mejores arquitecturas emergen de equipos auto organizados".


Es claro que en el enfoque tradicional, el diseño de arquitecturas se enmarca en la producción de mega modelos que tienen como fin entrar al detalle en todos los elementos funcionales y técnicos requeridos para el desarrollo BDUF. Se busca encontrar la piedra filosofal que asegure el éxito de un proyecto determinando todas las vistas (pe, 4+1) posibles para el diseño de un proyecto de software.


Los arquitectos de software buscan cuadrar el rubik de tal forma que sea innegable, creando muchas veces arquitecturas de marfil. Estas son aquellas que en el papel lucen muy bien pero que en la práctica son difíciles de llevar a cabo, como lo argumenta Scott Ambler en el enfoque de Agile Modeling

En muchos casos dichas arquitecturas terminan siendo un número elevado de documentos que se almacenan en archivadores o se apilán en anaqueles.  Por eso la afirmación de que las mejores arquitecturas emergen de equipos auto organizados, que se enfoca en hacer actividades de diseño que realmente generen valor ha tomado fuerza.

Sin embargo, la práctica muestra que para que eso se dé, se requieren profesionales expertos que tengan la capacidad de visionar cómo evolucionarán los componentes de software y cómo se relacionarán. Esto no es fácil, a menos que tengas en tu equipo a Kent Beck o a Martin Fowler, entre otros, con cicatrices de guerra de años que saben que decisión tomar en las iteraciones de implementación. Es claro que en frameworks como SCRUM existen tareas técnicas (SPIKE) que se determinan en el SPRINT BACKLOG; sin embargo el enfoque es específico en las funcionalidades y muchas veces se pueden realizar re trabajos o exageradas y costosas refactorizaciones.


Lo anterior lo menciono porque garantizar la extensibilidad y la mantenibilidad es el gran éxito de un buen diseño: prepararse para el cambio. "Dime que tan buena es tu diseño de software/arquitectura si al hacer un cambio no hay una reacción en cadena que afecte todo el sistema", es lo que promueve Bob Martin en Design Principles and Design Patterns como el concepto de que tan bien huele el software.

Cuando se abarcan totalmente labores de diseño en los SPRINTS  se corre el riesgo de adquirir deudas técnicas. Esto ocurre porque el énfasis está en implementar entregas de software que generen valor constante al negocio y no la generación de componentes de software que promuevan la reutilización, el mantenimiento y la extensibilidad porque desarrollamos funcionalidades concretas; no tenemos tiempo de pensar cómo ésta encajaría si diseñásemos una aplicación más amplia y nos centrásemos en construir una solución escalable y robusta.

Al no promoverse actividades de definición de arquitectura en etapas tempranas, incluso antes de elaborar un PROCESS BACKLOG, no se tiene una visión de cómo se van a crear componentes de forma ordenada, que eviten la redundancia de funcionalidades y desde luego que soporten los aspectos más relevantes no funcionales. En general, un modelo arquitectónico capaz de escalarse, de soportar el manejo de recuperación ante fallos y de brindar un desempeño adecuado que pueda soportar las funcionalidades a entregar.


Con lo anterior, no quiero argumentar que con los enfoques en cascada no se tengan deudas técnicas, porque a pesar de que se dedica un gran esfuerzo al comienzo, nadie tiene una bola de cristal tan poderosa para predecir lo que irá pasando en un proyecto de construcción de software. Al comienzo, el equipo inicia respetando lo pactado pero al final, el enfoque de dirección de proyecto clásico obliga a que se mantengan fechas aunque se reduzcan tiempos sacrificando la calidad y por lo tanto se adquieren deudas técnicas.

Creo que es necesaria la definición temprana de una arquitectura que realmente ayude a reducir la incertidumbre de un proyecto de construcción de software. Esta, debe ser práctica definiendo una visión de alto nivel sin entrar en detalles irrelevantes que no aporten valor real en las iteraciones de construcción; no es  un simple SPRINT 0 (de hecho no me gusta esta afirmación porque no entiendo un SPRINT que no entrega algo funcionando y que le brinde valor al patrocinador de un proyecto), es más que eso, es el aseguramiento de los aspectos no funcionales.

En esa fase previa de arquitectura que recibe los insumos funcionales que componen un PROCESS BACKLOG, se elaboran talleres de atributos de calidad ágiles QAW, que están orientados a la captura de aspectos no funcionales que se asocian a las funcionalidades definidas. Estos atributos incluyen: desempeño, escalabilidad, fiabilidad, extensibilidad, seguridad, autonomía, etc. Estos se pueden capturar en el momento en que se elaboran los criterios de aceptación, quizás luego de terminar un Visual-story-mapping y luego podrán verificarse a través de pruebas automatizadas.

Hablo de un taller ágil en el cual se haga énfasis en la captura de restricciones y atributos de calidad que permitan definir escenarios de calidad. El objetivo es la captura de datos relevantes con postits de parte de los participantes en el taller en vez del llenado de formatos engorrosos que distraen a los invitados.


Es importante aclarar que no estoy proponiendo que se sigan los pasos completos propuestos por QAW, solo los que aporten algo. Sin embargo, creo que el enfoque debe invitar a la participación de los diferentes roles que interviene en el taller: negocio, infraestructura, seguridad, arquitectura, etc.

Con la definición de los drivers de arquitectura se podrá elaborar un diseño de alto nivel HLD que incluya vistas del tipo Views&Beyond o algún modelo o dibujo que sea entendido por el equipo de desarollo que le sirva de horizonte. El objetivo es crear un modelo lógico que cumpla con los drivers y que ayude a identificar los componentes a implementar en la solución, definiendo sus responsabilidades, estilos de comunicación, protocolos, formatos de mensajería, decisiones de realización básicos, entre otros aspectos.

También se contempla la definición de un modelo físico que garantice que se soportará la carga transaccional de accesos concurrentes y de almacenamiento para las primeras iteraciones. Eliminé esto: Por último, es fundamental crear una vista dinámica que muestre como se enlazan los componentes de alto nivel definidos, sin entrar en muchos detalles innecesarios.

En cuanto al modelamiento, comparto plenamente el enfoque de dibujos en tableros y en papel que puedan ser capturados en fotografías POW, en vez de la gestión de sofisticados modelos UML engorrosos; un simple dibujo basta si el equipo así lo entiende. En general, me gusta mucho el enfoque de Agile Modeling que promueve el diseño de arquitecturas prácticas que evitan entrar en detalles poco pertinentes, como un diseño detallado DLD que pueden ser superados con la aplicación de TDD.

Es fundamental definir las principales decisiones de arquitectura básicas requeridas para las primeras iteraciones que tendrá un producto de software, contemplando alternativas con los respectivos puntos a favor y en contra hasta llegar a pruebas de concepto que validen que dichas decisiones son válidas.

En general, es indispensable en proyectos ágiles contemplar etapas previas de arquitectura de alto nivel que proporcionen valor al equipo de trabajo y al cliente que ayuden a dimensionar la infraestructura, la identificación de componentes a implementar en un proyecto y la disminución de la incertidumbre técnica. Con esto, creo que las deudas técnicas deben disminuir.

Sin embargo, no es una camisa de fuerza "no hay verdades absolutas", porque estoy seguro que todos los proyectos no tienen las mismas complejidades o quizás ya hemos ejecutado proyectos similares y en esos casos no considero relevante hacer actividades de arquitectura antes de arrancar el primer SPRINT.

3 comentarios:

  1. Este post tiene un hilo en foro-agiles: https://groups.yahoo.com/neo/groups/foro-agiles/conversations/topics/5906

    ResponderEliminar
  2. Agrego algo: me gusta el modelo de implementar pruebas automatizadas de atributos de calidad claves: desempeño, robustez, fiabilidad, seguridad ...... etc..
    Las tareas previas de arquitectura se pueden hacer cuando se implemente un visual story mapping ... cuando se detallen los criterios de aceptación, etc .. previo a definir el backlog, sin tanto ruido .. con la intensión de tener una visión general .. aunque el cambio es bienvenido.

    ResponderEliminar
  3. Gracias por este post muy interesante excelente las referencias ... aun que ya había leído este post al inicio del año pasado hoy vuelvo a revisarlo y me surge alguna inquietud ya puesto en practica. Para efectos de la mantenibilidad de los componentes de software es importante conocer las decisiones de arquitectura tomadas para plantear cambios o mejoras a dichos componentes .... Donde se alojan o deben permanecer estas decisiones o existe alguna herramienta donde esto también pueda ser compartida ?

    ResponderEliminar