Disclaimer: Io sono un architetto in un ambiente agile, ma, come Helmuth von Moltke il Vecchio dice: "Nessun piano di battaglia sopravvive al contatto con il nemico". In altre parole, gli aspetti pratici significano che la lettera esatta delle linee guida non può sempre essere seguita.
La maggior parte dei punti sollevati sopra sono seguiti nel miglior modo possibile dalla squadra. Tuttavia, il principio 1 (I team che codificano il sistema progettano il sistema) è davvero difficile da seguire quando il team è composto da decine (o centinaia) di sviluppatori suddivisi in diversi continenti e fusi orari . Questo non ha nulla a che fare con le capacità o le attitudini degli sviluppatori, più il problema logistico di tutti loro presenti per raccogliere i requisiti dei clienti e comprendere i sistemi complessi esistenti.
Quindi, come viene eseguita la progettazione del sistema? Usi UML? O un documento che definisce interfacce e blocchi principali? Forse qualcos'altro?
Spesso l'architetto identifica i componenti principali, quindi definisce le interfacce tra loro (compresi i requisiti non funzionali come sicurezza, velocità e affidabilità) e delega la progettazione interna dei componenti ai singoli team . Questo è un buon compromesso tra consentire ai team di progettare i propri componenti senza richiedere a tutti di sapere tutto sul sistema.
Ogni organizzazione ha il proprio set di standard per i progetti architettonici e questo a volte varia da progetto a progetto all'interno dell'organizzazione. Questo disegno fatto prima che il team inizi a scrivere il codice o il prima possibile e di solito contiene (e non è un elenco completo):
- Requisiti estesi e definizione dell'ambito. Questi includono casi d'uso o storie di utenti che rafforzano i requisiti aziendali di livello superiore. Personalmente mi piace utilizzare RFC 2119 per requisiti non funzionali. Il design si basa e si ricollega a questi. Anche se potrebbe non corrispondere alla definizione comune di design, questi sono spesso altrettanto importanti.
- Una panoramica composta da una rete di alto livello o diagramma dei componenti e una pagina di testo. Questo è per un pubblico molto ampio, dalla direzione superiore agli sviluppatori e al QA. Questo raramente utilizza UML o una notazione definita a causa del vasto pubblico.
- Dettagli per i singoli componenti, spesso incentrati sulle interfacce o sulle API tra loro, come menzionato sopra. Le interfacce possono essere specificate come firme dei metodi nella lingua di destinazione con i dettagli di precondizione e postcondizione. I componenti possono avere diagrammi di rete, come mostrare il layout delle macchine virtuali in un cloud o data center e le relative disposizioni di rete. I database relazionali di solito avranno diagrammi Entità-Relazione.
- Un elenco di rischi architetturali e relative mitigazioni, se noto. Come i requisiti, questi dimostrano decisioni di progettazione e compromessi.
In breve, la progettazione di un sistema in un processo agile è esattamente la stessa di un processo a cascata tradizionale. Tuttavia, in ambienti agili, una parte inferiore della progettazione viene eseguita in anticipo e una parte maggiore viene delegata ai team di componenti . La chiave sta determinando quanto in profondità andare inizialmente, quali decisioni rinviare e identificare quando le decisioni devono essere prese. Le decisioni che incidono su più team di sviluppo dovrebbero essere prese prima, in particolare la scalabilità e la sicurezza. Decisioni come l'aggiunta di lingue aggiuntive a un prodotto già internazionalizzato possono essere rinviate fino a tardi.
Dopo aver creato il progetto iniziale, l'architetto lavora con ciascuno dei team e rivede i loro progetti. Se per un'unità di lavoro sono necessari ulteriori cambiamenti di progettazione o di progettazione (come uno sprum di scrum), l'architetto mira a renderla disponibile al momento dell'inizio dell'unità di lavoro. L'architetto è inoltre responsabile della comunicazione di eventuali modifiche ai team interessati o alle parti interessate.