¿Cómo se realiza el diseño arquitectónico en un entorno ágil?

He leído Principios para el arquitecto ágil , donde definieron los siguientes principios:

Principio # 1 Los equipos que codifican el sistema diseñan el sistema.
Principio # 2 Cree la arquitectura más simple que pueda funcionar.
Principio # 3 En caso de duda, codifíquelo.
Principio # 4 Lo construyen, lo prueban.
Principio # 5 Cuanto más grande es el sistema, más larga es la pista.
Principio # 6 La arquitectura del sistema es una colaboración de roles.
Principio # 7 No existe el monopolio de la innovación.

El documento dice que la mayor parte del diseño de la arquitectura se realiza durante la fase de codificación, y solo el diseño del sistema antes de eso. Eso está bien.

Entonces, ¿cómo se hace el diseño del sistema? Usando UML? ¿O un documento que define interfaces y bloques principales? Tal vez algo más?

Exención de responsabilidad: yo soy un arquitecto en un entorno ágil pero, como Helmuth von Moltke dice: "No hay un plan de batalla sobrevive al contacto con el enemigo". En otras palabras, los aspectos prácticos significan que no siempre se puede seguir la letra exacta de las pautas.

La mayoría de los puntos planteados anteriormente se siguen lo mejor que puede el equipo. Sin embargo, el principio 1 (Los equipos que codifican el sistema diseñan el sistema) es realmente difícil de seguir cuando el equipo consta de decenas (o cientos) de desarrolladores divididos en diferentes continentes y zonas horarias . Esto no tiene nada que ver con las habilidades o actitudes de los desarrolladores, más el problema logístico de todos ellos presentes para reunir los requisitos de los clientes y comprender los sistemas complejos existentes.

Entonces, ¿cómo se hace el diseño del sistema? Usando UML? ¿O un documento que define interfaces y bloques principales? Tal vez algo más?

A menudo, el arquitecto identifica los componentes principales y luego define las interfaces entre ellos (incluidos los requisitos no funcionales como seguridad, velocidad y confiabilidad) y delega el diseño interno de los componentes a equipos individuales . Este es un buen compromiso entre dejar que los equipos diseñen sus propios componentes sin requerir que todos sepan todo sobre el sistema.

Cada organización tiene su propio conjunto de estándares para diseños arquitectónicos y esto a veces varía de un proyecto a otro dentro de la organización. Este diseño se realiza antes de que el equipo comience a codificar o tan pronto como sea posible y generalmente contiene (y no es una lista completa):

1. Requisitos ampliados y definición del alcance. Estos incluyen casos de uso o historias de usuarios que completan los requisitos empresariales de nivel superior. Personalmente, me gusta usar RFC 2119 para requisitos no funcionales. El diseño se basa y se remonta a estos. Aunque puede que no se ajuste a la definición común de diseño, a menudo son igual de importantes.
2. Una descripción general que consiste en un diagrama de red o componente de alto nivel y una página de texto. Esto es para un público muy amplio, desde la alta gerencia hasta el desarrollo y el control de calidad. Esto rara vez usa UML o una notación definida debido a la gran audiencia.
3. Detalles para componentes individuales, a menudo centrados en las interfaces o API entre ellos como se mencionó anteriormente. Las interfaces pueden especificarse como firmas de métodos en el idioma de destino con detalles de precondición y poscondición. Los componentes pueden tener diagramas de red, como mostrar el diseño de máquinas virtuales en una nube o centro de datos y sus disposiciones de red. Las bases de datos relacionales generalmente tendrán diagramas de entidad-relación.
4. Una lista de riesgos arquitectónicos y sus mitigaciones, si se conocen. Al igual que los requisitos, estos demuestran decisiones de diseño y compensaciones.

En resumen, el diseño de un sistema en un proceso ágil es exactamente el mismo que en un proceso en cascada tradicional. Sin embargo, en entornos ágiles, menos del diseño se realiza por adelantado y más se delega a los equipos de componentes . La clave es determinar qué tan profundo ir inicialmente, qué decisiones diferir e identificar cuándo deben tomarse decisiones. Las decisiones que afectan a múltiples equipos de desarrollo deben tomarse antes, especialmente la escalabilidad y la seguridad. Las decisiones como agregar idiomas adicionales a un producto ya internacionalizado pueden diferirse hasta muy tarde.

Después de crear el diseño inicial, el arquitecto trabaja con cada uno de los equipos y revisa sus diseños. Si se requieren diseños adicionales o cambios de diseño para una unidad de trabajo (como un scrum sprint), el arquitecto pretende tenerlo disponible para cuando comience esa unidad de trabajo. El arquitecto también es responsable de comunicar cualquier cambio a los equipos afectados o partes interesadas.

Descargo de responsabilidad: no soy un entrenador / arquitecto ágil, esto es lo que he visto en proyectos ágiles en los que he trabajado y creo que funciona bien.

No creo que Agile defina cómo se hace la arquitectura: los enfoques ágiles en las metodologías y prácticas de desarrollo. UML, por otro lado, es solo un lenguaje para comunicar su arquitectura que es más que ágil (lo usa si se ajusta a su proyecto y a su equipo).

Uno de los principios de la arquitectura que realmente se aplica es tomar la decisión en el último momento responsable posible, lo que significa que está bien si no ha tomado todas las decisiones al comienzo del proyecto, especialmente porque tiene menos información en esta etapa. Con el tiempo, puede tomar decisiones que "evolucionen" la arquitectura. Sí, esto puede parecer un poco de reproceso, pero esto también se debe al hecho de que ha aprendido cosas nuevas sobre el medio ambiente, los requisitos, lo que es posible y lo que no, etc.

Lo principal que le gustaría evitar es la descomposición de la arquitectura, donde el código no se ajusta realmente a ninguna arquitectura en particular y es solo un desastre enredado. La principal diferencia en comparación con la evolución de una arquitectura, es que en este último, usted toma decisiones conscientes periódicamente y las documenta con razones claras, y luego las sigue para asegurarse de que su código las siga.

Al realizar un desarrollo impulsado por pruebas, crea un código de prueba que prueba sus módulos de forma aislada (= tan independiente de otros módulos como sea posible)

Para facilitar la creación del código de prueba, introduce interfaces a otros módulos que se pueden burlar fácilmente.

De esta forma, como efecto secundario, obtiene automáticamente una arquitectura en la que el acoplamiento entre los módulos es lo más pequeño posible.

En mi opinión, tdd también es obra arquitectónica.