Un team progetta un servizio di prenotazione biglietti per un festival regionale. Il sistema gestisce agevolmente il carico previsto e la revisione del progetto si conclude con un esito positivo. Poi, però, il brief cambia: l'organizzatore ora promette che la vendita dei biglietti dovrà continuare a funzionare anche se un data center dovesse andare offline durante il periodo di vendita. Lo stesso progetto ora presenta un singolo punto di guasto e gli ingegneri che lo hanno ideato devono decidere cosa cambiare, a cosa rinunciare e come giustificare la scelta.
Questo è uno scenario illustrativo, non un incidente documentato. Rappresenta la situazione che un kata di progettazione di sistema è progettato per simulare: un progetto che funzionava correttamente in base a un determinato insieme di vincoli incontra un nuovo insieme di vincoli e gli ingegneri devono difenderlo o rivederlo motivando la decisione. Questa guida è destinata ai responsabili dell'abilitazione ingegneristica e ai manager di ingegneria. Illustra cos'è un kata di progettazione di sistema, come crearne uno, come eseguirlo e valutarlo e quando la formazione non è più sufficiente. Ogni caso e criterio deve essere convalidato da un ingegnere senior prima di essere utilizzato.
Che cos'è un kata di progettazione di sistema?
Un kata di progettazione di sistema è un esercizio di progettazione breve e a tempo limitato. Un piccolo team riceve un problema aziendale di un paragrafo, abbozza un'architettura, la presenta ai colleghi e risponde a domande difficili. I ricercatori lo chiamano anche kata di architettura o kata architettonico. Il formato è stato introdotto da Ted Neward come workshop ed è documentato, con le sue regole e il ruolo del moderatore, su Pagina dei kata architettonici di Neal FordLa domanda che ha spinto Neward a porsi l'argomento, citata in precedenza, è come le organizzazioni possano formare grandi architetti quando gli ingegneri hanno la possibilità di progettare meno di sei volte in tutta la loro carriera. Un kata offre loro ulteriori ripetizioni senza rischi per la produzione.
I fatti in breve
| La Domanda | Risposta breve |
|---|---|
| Qual è il compito? | Difendi un'architettura quando un vincolo cambia. |
| Quanto è grande un gruppo? | Il formato originale prevede piccoli gruppi da 3 a 5 persone, con un moderatore. |
| Che punteggio ottieni? | Il ragionamento basato sui compromessi e la risposta a un nuovo vincolo, non il diagramma più elegante. |
| È sufficiente un quiz sui modelli di progettazione? | No. Conferma i prerequisiti, ma non se un ingegnere è in grado di giustificare una scelta sotto pressione. |
| Chi convalida il caso? | Un responsabile dell'ingegneria o un architetto senior. |
| Cosa non può correggere un kata? | Mancanza di autorità decisionale in materia di progettazione, requisiti poco chiari e mancanza di tempo per progettare adeguatamente sul lavoro. |
| Come fai a sapere che ha funzionato? | Un nuovo caso inedito valutato in base a criteri concordati, oltre a un approfondimento sulle revisioni di progetti reali. |
1. Descrivi il problema di prestazioni
Partiamo dal compito, non dall'argomento. Il compito è difendere un'architettura in presenza di vincoli in continua evoluzione. Nella pratica, questo avviene durante le revisioni di progettazione, i follow-up degli incidenti e le riunioni di pianificazione, quando un requisito cambia: più traffico, una promessa di disponibilità più stringente, una nuova regola di residenza dei dati, un budget più limitato.
Molti ingegneri sanno disegnare un'architettura sensata. Meno sono quelli che sanno dire a cosa rinuncerebbero quando due obiettivi si scontrano e quali prove li farebbero cambiare idea. È proprio questa seconda abilità che il kata si esercita a praticare.
Scrivi una dichiarazione di prestazione in una sola frase e falla controllare a un responsabile dell'ingegneria: "Data un'architettura e un vincolo modificato, l'ingegnere indica cosa non funziona, propone una modifica, illustra il compromesso e dice cosa non sa ancora."
2. Diagnosticare le lacune di apprendimento e di contesto
Prima di iniziare a costruire qualsiasi cosa, confronta il compito con ciò che il tuo programma di studi pratica e valuta attualmente.
- La pratica si basa sul compito reale? Se la formazione insegna schemi isolati e la valutazione si basa su un test a risposta multipla, nessuno si è esercitato a difendere una scelta.
- Qual è il carico cognitivo richiesto? Nella tassonomia rivista di Bloom, il confronto tra opzioni e vincoli si colloca in "analizzare e valutare", mentre la proposta di un progetto rivisto raggiunge "creare". La nostra guida a abbinamento delle attività di apprendimento alla tassonomia di Bloom mostra come adattare l'attività a quel livello.
- C'è qualcos'altro, oltre all'abilità, che ostacola il cammino? Verificate se gli ingegneri hanno tempo per la progettazione, se qualcuno è responsabile delle decisioni architetturali e se i requisiti sono documentati per iscritto. Se una decisione viene presa da qualcuno esterno al team, nessun kata potrà cambiare ciò che il team è in grado di fare. Segnalate le cause a chi può risolverle.
3. Preparazione e pratica della progettazione
Assegna a ciascuna fase un compito ben preciso.
Preparazione. Verifica i prerequisiti con una breve diagnosi: il vocabolario utilizzato dal tuo team (disponibilità, coerenza, latenza, costo), gli elementi fondamentali che ci si aspetta conoscano e il tuo modello di revisione della progettazione. Lo studio autonomo è adatto a questa fase e una verifica mnemonica conferma solo i prerequisiti.
Pratica. Svolgi il kata vero e proprio. Nel formato descritto sul sito di Neal Ford, dopo la formazione del team, l'esercizio si articola in tre fasi: una fase di discussione in cui il team definisce cosa costruire, una fase di peer review in cui ogni team presenta il proprio progetto e risponde alle domande, e una fase di votazione in cui i partecipanti esprimono un giudizio positivo ("ottimo lavoro"), negativo ("qualche errore") o negativo ("un fallimento totale"). Alcune regole meritano di essere riprese direttamente: i team possono fare delle ipotesi su tecnologie sconosciute, ma devono dichiararle, e non possono presumere di poter assumere un team di fuoriclasse.
Aggiungi il vincolo variabile. Il kata standard propone un problema fisso. Per allenare l'abilità descritta in questa guida, aggiungete una seconda carta a metà percorso: un vincolo modificato che la squadra deve assimilare. Questa è una nostra scelta di design, non fa parte delle regole originali, quindi sperimentatela.
Feedback. Collega il feedback alle decisioni prese, non a un punteggio totale. "Hai effettuato il passaggio in due regioni, ma non hai specificato cosa succede a un ordine effettuato durante il passaggio" è più utile di "3 su 5".
Inserimento in tempo reale o revisione asincrona? La facilitazione in tempo reale è particolarmente utile quando una scelta è ambigua e gli ingegneri imparano da un collega senior che spiega perché manterrebbe la posizione. La revisione asincrona è sufficiente per confrontare una motivazione scritta con un esempio annotato.
4. Analizza un esempio realistico
A scopo illustrativo. Un ingegnere senior dovrebbe convalidare il caso e i criteri di risposta prima dell'utilizzo.
Il caso. Un festival regionale vende 20,000 biglietti in un fine settimana, con la maggior parte delle vendite concentrate nei primi dieci minuti. La prima versione del brief richiede un servizio di prenotazione in grado di gestire questo picco. Il design: un unico livello web, un unico database, una chiamata al fornitore di servizi di pagamento al momento del checkout.
Il vincolo modificato. A metà dell'evento, l'organizzatore aggiunge: le vendite devono continuare anche se un data center va offline e non è consentito vendere due volte lo stesso biglietto.
Un primo tentativo. "Aggiungete un secondo data center e replicate il database." Il team ha optato per un componente già noto, ma non ha specificato cosa accadrà alla regola contro le doppie vendite nel caso in cui i due siti non riescano a comunicare tra loro.
Invia feedback e riprova. Il facilitatore chiede al team di nominare i due obiettivi in conflitto e quale dei due proteggerebbero in caso di divisione della rete. Il secondo tentativo chiede loro di scegliere e di descrivere l'esperienza del cliente.
Un tentativo più deciso. "Proteggeremmo la regola contro la doppia vendita. In caso di divisione dei posti, solo il sito principale vende i biglietti e l'altro sito mostra una pagina di attesa. Accettiamo una minore disponibilità per un breve periodo per evitare di vendere lo stesso posto due volte. Abbiamo ipotizzato che la divisione dei posti sia rara e di breve durata e vorremmo che l'organizzatore confermasse che una pagina di attesa sia accettabile. Se fosse necessario che entrambi i siti vendessero, assegneremmo blocchi di posti separati a ciascun sito in anticipo, a costo di alcuni posti invenduti." Si noti che questa risposta identifica il conflitto, prende posizione, indica il costo e segnala ciò che non sa.
Perché ciascuna risposta è difendibile o incompleta. Valutate ciascuna proposta in base a criteri approvati, non in base all'architettura preferita dal revisore. Il primo tentativo nomina un componente ma non ne illustra i compromessi. Il tentativo migliore è specifico, dichiara i presupposti e offre un'alternativa con il relativo costo.
5. Valutare le capacità e pianificare il trasferimento
La prova della capacità consiste nella prestazione su un nuovo caso che l'ingegnere non ha mai affrontato prima. Valutare il ragionamento sui compromessi e la risposta a un nuovo vincolo. Una semplice griglia di valutazione utilizza una scala da 0 a 2 per ciascun criterio:
| Criterio | Prove osservabili |
|---|---|
| Esecuzione dell'attività | Difende l'architettura alla luce dei vincoli modificati e documenta le prove a supporto della decisione. |
| Ragionamento | Illustra i vincoli rilevanti, le alternative considerate e ciò che rimane incerto. |
| Confini | Segue le procedure di progettazione approvate e chiede aiuto quando mancano informazioni o l'autorità necessaria. |
Ancore: 0 è assente o non supportato, 1 è parziale con omissioni rilevanti e 2 è completo e giustificato in base ai criteri concordati. Definire separatamente gli errori critici, come l'ignorare un requisito di sicurezza o di protezione dei dati dichiarato, in modo che un punteggio complessivo non possa nasconderne uno. Questa rubrica è una proposta, non uno standard di prontezza convalidato: adattarla con un responsabile dell'ingegneria e testarla. La nostra guida a progettare attività interattive con feedback utili Spiega come scrivere feedback che siano collegati alle decisioni prese.
Pianifica il trasferimento deliberatamente. Dopo il kata, chiedi a ciascun ingegnere di portare una decisione di progettazione reale a una revisione e applica le stesse domande. Una revisione senza colpevolizzazioni di un incidente passato è un altro buon ponte verso il lavoro reale; vedi la nostra guida a conduzione di revisioni degli incidenti senza attribuzione di colpa.
Dove la consegna interattiva aiuta
I formati interattivi aiutano quando tutti devono impegnarsi prima di vedere il gruppo. In una sessione kata dal vivo, un facilitatore può mostrare il vincolo modificato, chiedere a ogni membro del team di digitare il compromesso che farebbe e perché, quindi rivelare la distribuzione prima che inizi la discussione. Il voto tra pari alla fine del formato originale è facile da gestire allo stesso modo. Lo stesso caso può essere eseguito a ritmo individuale per la preparazione o per gli ingegneri che perdono la sessione. AhaSlides supporta l'apprendimento interattivo e il passaggio tra la modalità dal vivo e quella a ritmo individuale. È uno strumento di presentazione e apprendimento, non un luogo per disegnare o eseguire architetture, quindi mantieni i diagrammi su una lavagna o nel tuo strumento di progettazione. Verifica qualsiasi funzione specifica di authoring, feedback o reporting su cui intendi fare affidamento rispetto al tuo flusso di lavoro. Per indicazioni sulla scelta dei formati, consulta il nostro articolo su quando utilizzare l'apprendimento adattivo, interattivo e in diretta.
Misurare ciò che è cambiato
Decidete in anticipo cosa dimostrerebbe che gli ingegneri sono in grado di difendere un'architettura in presenza di vincoli variabili. Confrontate il ragionamento sui compromessi in un caso non ancora analizzato con un valore di riferimento rilevato prima dell'avvio del programma. Definite chi è incluso, il denominatore e la tempistica. Se i risultati migliorano, valutate cos'altro è cambiato nello stesso periodo, come ad esempio un nuovo modello di revisione della progettazione, un cambio di personale o un incidente che ha attirato l'attenzione, prima di attribuire il merito alla formazione.
Vincoli che potrebbero rimanere
- Autorità progettuale. Se il team non prende la decisione, esercitarsi su di essa ha un effetto limitato.
- Tempo. Un kata richiede ore; i progetti reali richiedono settimane e implicano dati che un kata non può fornire.
- Copertura del caso. Un caso specifico richiede di valutare alcuni compromessi. Un punteggio non descrive il giudizio di un ingegnere in generale.
- Complessità. Una maggiore complessità non è necessariamente sinonimo di un'architettura migliore, quindi non bisogna premiare il maggior numero di componenti.
- Trasferimento. Fare bene in un workshop non è la stessa cosa che fare bene in una revisione sotto pressione, quindi verifica la tua prestazione dopo il kata, nel contesto reale.
Segnalate tempestivamente questi problemi agli sponsor e pianificate soluzioni separate. Un kata migliora ciò che gli ingegneri possono spiegare e difendere, ma non crea l'autorità né il tempo necessari.
Domande frequenti
Che cos'è un kata di progettazione di sistema?
Un esercizio di progettazione breve e a tempo limitato in cui un piccolo team abbozza un'architettura per un problema aziendale, la presenta ai colleghi e risponde a domande impegnative. È anche chiamato kata di architettura.
Da quante persone dovrebbe essere composta una squadra?
Il formato originale prevede piccoli gruppi da 3 a 5 persone, solitamente suddivisi in 4-10 gruppi all'interno di una stanza. È importante utilizzare gruppi sufficientemente piccoli da permettere a tutti di parlare.
Come si valuta un kata di progettazione di sistema?
Presenta un nuovo caso e valuta il ragionamento relativo al compromesso e la risposta a un vincolo modificato rispetto a criteri concordati. Il voto dei colleghi è un feedback utile, ma non costituisce di per sé un punteggio.
Dove iniziare
Scegliete una decisione progettuale ricorrente nella vostra organizzazione e scrivete un caso di studio di un paragrafo a supporto. Aggiungete un vincolo modificato, fate convalidare il caso e i criteri di risposta da un responsabile dell'ingegneria e redigete una griglia di valutazione a tre criteri con un elenco di errori critici. Testatela con un team prima di estenderla a tutti.
Per scoprire come un kata può essere eseguito dal vivo con il tuo team e riutilizzato in seguito in autonomia, esplora AhaSlides.
