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):
- 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.
- 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.
- 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.
- 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.