O echipă proiectează un serviciu de rezervare bilete pentru un festival regional. Acesta gestionează fără probleme volumul așteptat, iar analiza designului se încheie cu aprobări din cap. Apoi, micile modificări: organizatorul promite acum că vânzările de bilete trebuie să continue să funcționeze chiar dacă un centru de date se deconectează în timpul perioadei de vânzare. Același design are acum un singur punct de defecțiune, iar inginerii care l-au desenat trebuie să decidă ce să schimbe, la ce să renunțe și cum să explice alegerea.
Acesta este un scenariu ilustrativ, nu un incident documentat. Este situația pentru care este construit un kata de proiectare a sistemelor: un design care era bun sub un set de constrângeri întâlnește unul nou, iar inginerii trebuie să îl apere sau să îl revizuiască cu argumente. Acest ghid este destinat liderilor în domeniul activării inginerești și managerilor de inginerie. Acesta acoperă ce este un kata de proiectare a sistemelor, cum se construiește unul, cum se execută și se evaluează și unde instruirea încetează să mai fie răspunsul. Fiecare caz și criteriu trebuie validat de un inginer senior înainte de a fi utilizat.
Ce este un kata de proiectare a sistemelor?
O kata de proiectare a sistemelor este un exercițiu de proiectare scurt, limitat în timp. O echipă mică primește o problemă de afaceri de un paragraf, schițează o arhitectură, o prezintă colegilor și răspunde la întrebări dificile. Cei care caută o numesc și kata de arhitectură sau kata arhitecturală. Formatul a fost inițiat de Ted Neward ca atelier și este documentat, cu regulile sale și rolul de moderator, pe Pagina de katas arhitecturale a lui Neal FordÎntrebarea motivatoare a lui Neward, citată acolo, este cum ar trebui organizațiile să formeze arhitecți excelenți atunci când inginerii au șansa de a fi arhitecti mai puțin de șase ori într-o carieră. O kata le oferă repetiții suplimentare fără riscuri de producție.
Scurte
| Întrebare | Răspuns scurt |
|---|---|
| Care este sarcina? | Apărați o arhitectură atunci când o constrângere se modifică. |
| Cât de mare este un grup? | Formatul original folosește grupuri mici de 3 până la 5 persoane, cu un moderator. |
| Ce punctaj obții? | Raționamentul bazat pe compromisuri și răspunsul la o nouă constrângere, nu cea mai frumoasă diagramă. |
| Este suficient un test despre modele de design? | Nu. Confirmă condițiile prealabile, dar nu dacă un inginer poate justifica o alegere sub presiune. |
| Cine validează cazul? | Un manager de inginerie sau un arhitect senior. |
| Ce nu poate rezolva o kata? | Lipsa autorității de proiectare, cerințe neclare și lipsa timpului necesar pentru a proiecta corect la locul de muncă. |
| De unde știi că a funcționat? | Un caz nou, nevăzut, a fost evaluat conform unor criterii convenite, plus urmărirea revizuirilor reale de proiectare. |
1. Descrieți problema de performanță
Începeți cu sarcina, nu cu subiectul. Sarcina este de a apăra o arhitectură în condiții de constrângeri în schimbare. În munca reală, acest lucru se întâmplă în revizuirile de proiectare, urmărirea incidentelor și întâlnirile de planificare în care o cerință se modifică: mai mult trafic, o promisiune de disponibilitate mai strictă, o nouă regulă de rezidență a datelor, un buget mai restrâns.
Mulți ingineri pot desena o arhitectură rezonabilă. Mai puțini pot spune ce ar renunța atunci când două obiective se ciocnesc și ce dovezi le-ar schimba părerea. Această a doua abilitate este ceea ce exersează kata.
Scrieți o declarație de performanță de o singură propoziție și rugați un manager de inginerie să o verifice: „Având în vedere o arhitectură și o constrângere modificată, inginerul numește ce anume nu funcționează, propune o modificare, enunță compromisul și spune ce nu știe încă.”
2. Diagnosticați lacunele de învățare și context
Înainte de a construi orice, comparați sarcina cu ceea ce programul dumneavoastră practică și evaluează astăzi.
- Folosește practica sarcina reală? Dacă instruirea predă modele izolat, iar evaluarea este un test cu variante multiple de răspuns, nimeni nu a exersat apărarea unei alegeri.
- Care este cererea cognitivă? În taxonomia revizuită a lui Bloom, compararea opțiunilor în raport cu constrângerile se află la analiza și evaluare, iar propunerea unui design revizuit ajunge la creare. Ghidul nostru pentru potrivirea activităților de învățare cu taxonomia lui Bloom arată cum să potrivești activitatea cu acel nivel.
- Este ceva în afară de pricepere în cale? Verificați dacă inginerii au timp să proiecteze, dacă cineva deține deciziile de arhitectură și dacă cerințele sunt scrise. Dacă o decizie este luată de cineva din afara echipei, nicio regulă nu va schimba ceea ce poate face echipa. Transmiteți aceste cauze persoanelor care le pot remedia.
3. Pregătirea și practica designului
Acordă fiecărei etape o sarcină distinctă.
Pregătirea. Verificați cerințele preliminare cu o scurtă diagnosticare: vocabularul folosit de echipa dvs. (disponibilitate, consecvență, latență, cost), elementele constitutive pe care se așteaptă să le cunoască și propriul șablon de revizuire a designului. Studiul în ritm propriu se potrivește acestei etape, iar o verificare a reamintirii confirmă doar cerințele preliminare.
Practică. Executați kata-ul propriu-zis. În formatul descris pe site-ul lui Neal Ford, după ce se formează echipa, exercițiul se desfășoară în trei faze: o fază de discuții în care echipa stabilește ce construiește, o fază de evaluare inter pares în care fiecare echipă prezintă și răspunde la întrebări și o fază de votare în care colegii dau un deget mare în sus („am reușit”), un deget mare „meh” („am ratat câteva lucruri”) sau un deget mare în jos („am ratat, lamentabil”). Unele reguli merită preluate direct: echipele pot face presupuneri despre tehnologii necunoscute, dar trebuie să le enunțe și nu pot presupune că pot angaja o echipă de vedete.
Adăugați constrângerea de modificare. Kata standard oferă o problemă rezolvată. Pentru a antrena abilitatea din acest ghid, adăugați o a doua carte la jumătatea jocului: o constrângere modificată pe care echipa trebuie să o absoarbă. Aceasta este o alegere de design a noastră, nu face parte din regulile originale, așa că pilotați-o.
Parere. Legați feedback-ul de decizii, nu de un scor total. „Te-ai mutat în două regiuni, dar nu ai spus ce se întâmplă cu o comandă plasată în timpul schimbării” este mai util decât „3 din 5”.
Intrare în timp real sau revizuire asincronă? Facilitarea live aduce un plus de valoare atunci când o alegere este ambiguă, iar inginerii învață de la un coleg senior care le explică de ce ar rezista. Revizuirea asincronă este suficientă pentru a compara o justificare scrisă cu un exemplu adnotat.
4. Lucrează printr-un exemplu realist
Ilustrativ. Un inginer senior ar trebui să valideze cazul și criteriile de răspuns înainte de utilizare.
Cazul. Un festival regional vinde 20,000 de bilete într-un weekend, majoritatea vânzărilor fiind în primele zece minute. Prima versiune a brief-ului solicită un serviciu de rezervări care să facă față acestui vârf de vânzări. Designul: un singur nivel web, o singură bază de date, un apel al furnizorului de servicii de plată la finalizarea comenzii.
Constrângerea modificată. La jumătatea evenimentului, organizatorul adaugă: vânzările trebuie să continue dacă un centru de date se deconectează și niciun bilet nu poate fi vândut de două ori.
O primă încercare. „Adăugați un al doilea centru de date și replicați baza de date.” Echipa a ajuns la o componentă familiară, dar nu a spus ce se întâmplă cu regula de interzicere a vânzărilor duble atunci când cele două site-uri nu pot comunica între ele.
Feedback și reîncercare. Facilitatorul le cere echipei să numească cele două obiective aflate în tensiune și pe care l-ar proteja într-o divizare a rețelei. Reîncercarea le cere să aleagă și să spună ce experimentează clientul.
O încercare mai puternică. „Am proteja regula fără vânzare dublă. În timpul unei vânzări parțiale, doar locația principală vinde bilete, iar cealaltă locație afișează o pagină de așteptare. Acceptăm o disponibilitate mai mică pentru o perioadă scurtă de timp, pentru a evita vânzarea aceluiași loc de două ori. Am presupus că vânzarea parțială este rară și scurtă și am dori ca organizatorul să confirme că o pagină de așteptare este acceptabilă. Dacă au nevoie ca ambele locații să vândă, am aloca blocuri separate de locuri fiecărei locații în avans, cu prețul unor locuri nevândute.” Observați că acest răspuns numește conflictul, alege o parte, menționează costul și semnalează ceea ce nu cunoaște.
De ce fiecare răspuns este justificabil sau incomplet. Evaluați fiecare în funcție de criteriile aprobate, nu de arhitectura preferată de un evaluator. Prima încercare numește o componentă, dar nu face niciun compromis. Încercarea mai puternică este specifică, își enunță presupunerile și oferă o alternativă cu prețul său.
5. Evaluarea capacității și planificarea transferului
Dovada capacității este performanța într-un caz nou pe care inginerul nu l-a mai văzut. Raționamentul privind compromisul de punctaj și răspunsul la o nouă constrângere. O rubrică simplă folosește o scală de la 0 la 2 pentru fiecare criteriu:
| Criteriu | Dovezi observabile |
|---|---|
| Executarea sarcinilor | Apără arhitectura sub constrângerea modificată și înregistrează dovezile din spatele deciziei. |
| Raţionament | Explică constrângerile relevante, alternativele luate în considerare și ce rămâne incert. |
| Limite | Respectă procedurile de proiectare aprobate și solicită ajutor atunci când lipsesc informații sau autoritate. |
Ancore: 0 este absent sau nejustificat, 1 este parțial cu omisiuni relevante, iar 2 este complet și justificat în funcție de criteriile convenite. Definiți separat erorile critice, cum ar fi ignorarea unei cerințe de siguranță sau de protecție a datelor declarate, astfel încât un scor general să nu poată ascunde una. Această rubrică este o propunere, nu un standard de pregătire validat: adaptați-o cu un manager de inginerie și testați-o. Ghidul nostru pentru proiectarea unei practici interactive cu feedback util acoperă modul de redactare a feedback-ului care se leagă de decizii.
Planificați transferul în mod deliberat. După kata, rugați fiecare inginer să prezinte o decizie de proiectare reală la o revizuire și să aplice aceleași întrebări. O revizuire ireproșabilă a unui incident trecut este o altă punte bună către munca reală; consultați ghidul nostru pentru efectuarea de evaluări ale incidentelor fără vină.
Unde ajută livrarea interactivă
Formatele interactive ajută acolo unde toată lumea ar trebui să se angajeze înainte de a vedea grupul. Într-o sesiune de kata live, un facilitator poate arăta constrângerea modificată, poate ruga fiecare membru al echipei să scrie compromisul pe care l-ar face și de ce, apoi poate dezvălui distribuția înainte de începerea discuției. Votul colegial de la sfârșitul formatului original este ușor de rulat în același mod. Același caz poate rula în ritm propriu pentru pregătire sau pentru inginerii care lipsesc de la sesiune. AhaSlides susține învățarea interactivă și trecerea de la livrarea live la cea în ritm propriu. Este un instrument de prezentare și învățare, nu un loc pentru a desena sau a rula arhitectură, așa că păstrați diagramele pe o tablă albă sau în instrumentul dvs. de proiectare. Verificați orice funcție specifică de creare, feedback sau raportare pe care intenționați să vă bazați în raport cu propriul flux de lucru. Pentru îndrumări privind alegerea formatelor, consultați articolul nostru despre... când să folosim învățarea adaptivă, interactivă și live.
Măsoară ce s-a schimbat
Decideți în avans ce ar demonstra că inginerii pot apăra o arhitectură în condiții de constrângeri în schimbare. Comparați raționamentul bazat pe compromisuri pe un caz nevăzut cu o bază luată înainte de program. Definiți cine este inclus, numitorul și momentul. Dacă rezultatele se îmbunătățesc, analizați ce s-a mai schimbat în aceeași perioadă, cum ar fi un nou șablon de revizuire a designului, o schimbare de personal sau un incident care a atras atenția, înainte de a acorda credit instruirii.
Constrângeri care pot rămâne
- Autoritatea în proiectare. Dacă echipa nu ia decizia, exersarea acesteia are un efect limitat.
- Timp. O kata durează ore; proiectele reale durează săptămâni și implică date pe care o kata nu le poate furniza.
- Acoperirea cazului. Un caz pune în practică câteva compromisuri. Un scor nu descrie judecata unui inginer în general.
- Complexitate. O complexitate mai mare nu înseamnă neapărat o arhitectură mai bună, așa că nu recompensați cele mai multe componente.
- Transfer. A te descurca bine într-un atelier nu este același lucru cu a te descurca bine într-o analiză tensionată, așa că verifică performanța după kata, în contextul real.
Numiți-le sponsorilor din timp și planificați remedieri separate. Un kata îmbunătățește ceea ce inginerii pot explica și apăra. Nu creează autoritatea sau timpul necesar.
Întrebări frecvente
Ce este un kata de proiectare a sistemelor?
Un exercițiu de design scurt, limitat în timp, în care o echipă mică schițează o arhitectură pentru o problemă de afaceri, o prezintă colegilor și răspunde la întrebări dificile. Se numește și kata de arhitectură.
Câți oameni ar trebui să fie într-o echipă?
Formatul original folosește grupuri mici de 3 până la 5 persoane, de obicei câte 4 până la 10 persoane într-o cameră. Folosiți grupuri suficient de mici pentru ca toată lumea să vorbească.
Cum evaluezi un kata de proiectare a sistemului?
Prezentați un caz nou și raționamentul privind compromisul pentru scor, precum și răspunsul la o constrângere modificată în funcție de criteriile convenite. Un vot între colegi este un feedback util, dar nu un scor în sine.
Unde să încep
Alegeți o decizie de design recurentă în organizația dumneavoastră și scrieți un studiu de caz de un paragraf în jurul acesteia. Adăugați o constrângere modificată, rugați un manager de inginerie să valideze studiul de caz și criteriile de răspuns și redactați o rubrică cu trei criterii, cu o listă de erori critice. Testați-o cu o echipă înainte de a o implementa.
Pentru a vedea cum un kata ar putea fi desfășurat live cu propria echipă și reutilizat ulterior în ritmul propriu, explorează AhaSlides.
