Come viene eseguita la progettazione architettonica in un ambiente agile?


59

Ho letto Principi per l'architetto Agile , dove hanno definito i seguenti principi:

Principio n. 1 I team che codificano il sistema progettano il sistema.
Principio n. 2 Costruisci l'architettura più semplice che possa funzionare.
Principio n. 3 In caso di dubbio, codificarlo.
Principio n. 4 Lo costruiscono, lo testano.
Principio n. 5 Più grande è il sistema, più lunga è la pista.
Principio n. 6 L'architettura del sistema è una collaborazione di ruolo.
Principio n. 7 Non vi è monopolio sull'innovazione.

Il documento afferma che la maggior parte della progettazione dell'architettura viene eseguita durante la fase di codifica e solo la progettazione del sistema prima. Questo va bene.

Quindi, come viene eseguita la progettazione del sistema? Usi UML? O un documento che definisce interfacce e blocchi principali? Forse qualcos'altro?


11
Non "fai il disegno" in UML. Fai il disegno e poi usi UML per scriverlo o comunicarlo.
tdammers,

4
@tdammers: per essere precisi, si tenta di utilizzare UML per annotarlo e notare che UML non è sufficiente.
Doc Brown,

Risposte:


77

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.


3
Questa è un'ottima risposta a quale dovrebbe essere il ruolo di un architetto in un team Agile, tuttavia in realtà non risponde alla domanda su cosa sia la progettazione del sistema prima che inizi lo sviluppo dello sprint e le migliori pratiche per farlo.
maple_shaft

@maple_shaft Ho ampliato la mia risposta per concentrarmi maggiormente sul design.
Akton,

3
Per quello che vale, come un altro architetto che ha lavorato in ambienti agili per diversi anni in importanti contesti multinazionali, questo è perfetto.
Rex M

12

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 credo che Agile definisca in modo abbastanza preciso il modo in cui si fa l'architettura: l'agile si concentra su metodologie e pratiche di sviluppo. UML d'altra parte è solo un linguaggio per comunicare la tua architettura che è oltre agile (lo usi se si adatta al tuo progetto e al tuo team).

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

La cosa principale che vorresti evitare è il marciume dell'architettura - in cui il codice non è realmente conforme a nessuna particolare architettura ed è solo un pasticcio aggrovigliato. La differenza principale rispetto all'evoluzione di un'architettura è che in quest'ultima prendi periodicamente decisioni consapevoli e le documenti con chiare ragioni, quindi segui le istruzioni per assicurarti che il tuo codice le segua.


0

Quando si esegue uno sviluppo guidato dai test, si crea un codice di test che verifica i moduli separatamente (= il più indipendente possibile dagli altri moduli)

Per facilitare la creazione di testingcode si introducono interfacce ad altri moduli che possono essere facilmente derisi.

In questo modo si ottiene automaticamente un'architettura in cui l'accoppiamento tra i moduli è il più piccolo possibile.

Secondo me tdd è anche un lavoro di architettura.


Sì, TDD è un'opera architettonica, ma su componenti software. La mia domanda è davvero come l'architettura di un progetto su larga scala viene creata usando principi agili.
BЈовић,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.