Come si svolge la progettazione architettonica in un ambiente agile?

Disclaimer: I am un architetto in un ambiente agile ma, come dice Helmuth von Moltke the Elder, "Nessun piano di battaglia sopravvive al contatto con il nemico". In altre parole, praticità significa che non è sempre possibile seguire la lettera esatta delle linee guida.

La maggior parte dei punti sopra riportati sono seguiti al meglio dalla squadra. Tuttavia, principio 1 (I team che codificano il sistema di progettazione del sistema) è davvero difficile da seguire quando il team è composto da decine (o centinaia) di sviluppatori suddivisi tra diversi continenti e fusi orari . Questo non ha nulla a che fare con le abilità o gli atteggiamenti degli sviluppatori, più il problema logistico di tutti loro è presente per raccogliere le richieste dei clienti e comprendere i sistemi complessi esistenti.

So, how is the system design done? Using UML? Or a document that defines interfaces and major blocks? Maybe something else?

Spesso l'architetto identifica i componenti principali, quindi definisce le interfacce tra di 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 una propria serie di standard per i progetti architettonici e questo a volte varia da progetto a progetto all'interno dell'organizzazione. Questo disegno è stato fatto prima che il team iniziasse la codifica o il prima possibile e di solito contiene (e non è un elenco completo):

1. Requisiti estesi e definizione dell'ambito. Questi includono casi d'uso o storie di utenti che soddisfano i requisiti aziendali di livello superiore. Personalmente mi piace usare RFC 2119 per i requisiti non funzionali. Il design è basato su e ricondotto a questi. Anche se potrebbe non adattarsi alla definizione comune di design, spesso sono altrettanto importanti.
2. Una panoramica costituita da un diagramma di rete o componente di alto livello e una pagina di testo. Questo è per un pubblico molto ampio, dalla gestione superiore fino allo sviluppo e al controllo qualità. Questo raramente utilizza UML o una notazione definita a causa dell'ampio pubblico.
3. Dettagli per singoli componenti, spesso incentrati sulle interfacce o API tra di loro come menzionato sopra. Le interfacce possono essere specificate come firme del metodo nella lingua di destinazione con i dettagli di precondizione e post-condizione. I componenti possono avere diagrammi di rete, come mostrare il layout delle VM in un cloud o in un data center e le loro disposizioni di networking. I database relazionali di solito hanno diagrammi Entità-Relazione.
4. Una lista di rischi architettonici e loro mitigazioni, se conosciuti. 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 una procedura tradizionale a cascata. Tuttavia, in ambienti agili, meno del design viene eseguito in anticipo e più di esso è delegato ai team dei componenti . La chiave sta determinando la profondità iniziale, quali decisioni rimandare e identificare quando devono essere prese le decisioni. Le decisioni che incidono su più team di sviluppo dovrebbero essere prese prima, in particolare scalabilità e sicurezza. Decisioni come l'aggiunta di lingue aggiuntive a un prodotto già internazionalizzato possono essere posticipate molto tardi.

Dopo aver creato la progettazione iniziale, l'architetto lavora con ciascuno dei team e rivede i loro progetti. Se sono necessarie modifiche progettuali o di progetto aggiuntive per un'unità di lavoro (come una scrum sprint), l'architetto intende renderlo disponibile al momento in cui inizia l'unità di lavoro. L'architetto è anche responsabile della comunicazione di eventuali modifiche ai team o agli stakeholder interessati.

Disclaimer: non sono un allenatore / architetto agile - questo è quello che ho visto in progetti agili su cui ho lavorato e penso che funzioni bene.

Non penso che sia abbastanza definito da Agile come si fa l'architettura: focus agile su metodologie e pratiche di sviluppo. UML d'altra parte è solo un linguaggio per comunicare la tua architettura che è al di là di agilità (lo usi se si adatta al tuo progetto e al tuo team).

Uno dei principi dell'architettura che si applica veramente è prendere la decisione all'ultimo momento possibile - il che significa che va bene se non hai preso tutte le decisioni all'inizio del progetto, soprattutto perché hai meno informazioni a questo stadio. Nel tempo, potresti prendere decisioni che "evolvono" l'architettura. Sì, questo potrebbe sembrare un po 'di rilavorazione, ma questo è anche dovuto al fatto che hai imparato cose nuove sull'ambiente, i requisiti, ciò che è possibile ciò che non lo è, ecc.

La cosa principale che vorresti evitare è l'architettura rot - in cui il codice non è realmente conforme all'architettura qualsiasi ed è solo un disordine aggrovigliato. La differenza principale rispetto all'evoluzione di un'architettura è che in quest'ultimo caso si prendono decisioni consapevoli periodicamente e si documentano con chiare motivazioni, quindi si esegue la verifica per assicurarsi che il codice lo segua.

Quando esegui lo sviluppo basato su test, crei un testcode che verifica i moduli in isolamento (= come indipendente dagli altri moduli possibile)

Per facilitare la creazione di testingcode, si introducono interfacce ad altri modul che possono essere facilmente sbeffeggiati.

In questo modo, come effetto di un lato, ottieni automaticamente un'architettura in cui l'accoppiamento tra i moduli è il più piccolo possibile.

Secondo me tdd è anche un lavoro architettonico.