Descargo de responsabilidad: Soy un arquitecto en un entorno ágil pero, como dice Helmuth von Moltke el Viejo, "Ningún plan de batalla sobrevive al contacto con el enemigo". En otras palabras, los aspectos prácticos significan que la letra exacta de las directrices no siempre se puede seguir.
La mayoría de los puntos mencionados anteriormente se siguen lo mejor que puede el equipo. Sin embargo, el principio 1 (los equipos que codifican el sistema para diseñar el sistema) es realmente difícil de seguir cuando el equipo está formado por 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 permitir 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 realizado 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 de 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 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 componentes o red de alto nivel y una página de texto. Esto es para una audiencia muy amplia, desde la gerencia superior hasta dev y control de calidad. Esto rara vez utiliza UML o una notación definida debido a la amplia audiencia.
- Detalles para componentes individuales, que a menudo se centran 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 los detalles de condición previa y posterior. Los componentes pueden tener diagramas de red, como mostrar el diseño de las máquinas virtuales en una nube o centro de datos y sus acuerdos 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 conoce. Como 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 de cascada tradicional. Sin embargo, en entornos ágiles, menos del diseño se realiza por adelantado y más del mismo se delega a los equipos de componentes . La clave es determinar qué tan profundo es ir inicialmente, qué decisiones aplazar e identificar cuándo se deben tomar decisiones. Las decisiones que afectan a varios equipos de desarrollo deben tomarse antes, especialmente la escalabilidad y la seguridad. Las decisiones como agregar idiomas adicionales a un producto ya internacionalizado pueden aplazarse hasta muy tarde.
Una vez creado el diseño inicial, el arquitecto trabaja con cada uno de los equipos y revisa sus diseños. Si se requieren cambios adicionales en el diseño o en el diseño para una unidad de trabajo (como un scrum sprint), el arquitecto aspira a tenerlo disponible para cuando comience la unidad de trabajo. El arquitecto también es responsable de comunicar cualquier cambio a los equipos afectados o partes interesadas.