Case study - Warsztat Architectural KATA
Warsztat Architectural KATA w MAK IT.
Co się stanie, jeśli podczas Warsztatu Architectural KATA dasz programistom i architektom ten sam problem biznesowy, te same informacje i kilka godzin na zaprojektowanie rozwiązania? Nie powstanie jedna architektura. I właśnie o to chodziło podczas KATY, którą przeprowadziliśmy dla zespołu MAK IT.
Czym jest Warsztat Architectural KATA?
To całodzienny, praktyczny warsztat, podczas którego zespoły projektują architekturę dla realistycznego problemu biznesowego, a potem prezentują i bronią swoich decyzji.
Dla kogoprogramiściarchitekcitech leadziosoby, które podejmują decyzje techniczne w prawdziwych projektach
Punkt wyjścia
Ten sam problem biznesowy trafił do kilku zespołów
W warsztacie uczestniczyli programiści i architekci MAK IT. Architektów celowo zebraliśmy w osobnym zespole, żeby nie narzucali pozostałym grupom swojego sposobu myślenia i rozwiązania. Nie zaczęliśmy od prezentacji ani omawiania wzorców.
Uczestnicy dostali realistyczny problem biznesowy i musieli przejść przez proces podobny do tego, z którym mierzą się w prawdziwych projektach:
- zrozumieć domenę,
- znaleźć wymagania, które mają największy wpływ na architekturę,
- określić priorytety,
- zaprojektować rozwiązanie,
- świadomie zaakceptować kompromisy,
- uzasadnić swoje decyzje.
Różnica była jedna: tym razem można było eksperymentować bez konsekwencji dla klienta, budżetu czy działającego systemu.
Od problemu biznesowego do decyzji architektonicznych
Jak wyglądał Warsztat Architectural KATA dla zespołu programistów i architektów z MAK IT?
Uczestnicy pracowali w kilku zespołach. Najpierw analizowali domenę i szukali tego, co naprawdę powinno wpływać na projekt systemu. Później pojawiały się decyzje:
- Jak podzielić system?
- Które wymagania powinny sterować architekturą?
- Co zoptymalizować, a co świadomie potraktować jako mniej istotne?
- Jakie ryzyko zaakceptować?
- Z czego zrezygnować?
Każdy kolejny krok prowadził do najważniejszego pytania:
Dlaczego właśnie tak?
Pytanie, na które każdy zespół musiał odpowiedzieć
Nie wystarczyło zaproponować rozwiązania. Trzeba było umieć pokazać, z jakich założeń wynika, jakie problemy rozwiązuje i jakie kompromisy za sobą niesie.
Zespoły projektowały architekturę, analizowały warianty, zapisywały decyzje i przygotowywały się do ich obrony.
Kluczowy moment
Porównanie decyzji zespołów.
Na koniec każdy zespół prezentował swoje rozwiązanie. I właśnie wtedy najlepiej było widać, po co robimy KATA. Ten sam problem prowadził do różnych, sensownych architektur.
Jedna grupa uznawała konkretne ryzyko za kluczowe, inna za akceptowalne.
Te same wymagania prowadziły do innych priorytetów.
Zespoły inaczej dzieliły odpowiedzialności, inaczej podchodziły do skalowania i były gotowe zaakceptować inne kompromisy.
Nie chodziło o znalezienie jednej odpowiedzi z klucza.
Chodziło o zobaczenie, jak inni programiści i architekci dochodzą do swoich decyzji - i sprawdzenie własnego sposobu myślenia w konfrontacji z ich argumentami.
Bezpieczne miejsce
Co zespół mógł przećwiczyć podczas KATA
- 01
Zakwestionować założenie
Sprawdzić, czy to, co „wszyscy wiedzą”, naprawdę powinno sterować architekturą.
- 02
Wybrać inną drogę
Pójść w wariant, na który w prawdziwym projekcie nie byłoby czasu ani budżetu.
- 03
Sprawdzić konsekwencje decyzji
Zobaczyć, dokąd prowadzi wybór, zanim ktoś zapłaci za niego w produkcji.
- 04
Posłuchać argumentów innych osób
Skonfrontować własny sposób myślenia z tym, jak inne zespoły doszły do swoich decyzji.
- 05
Dostać feedback
Zanim podobna decyzja pojawi się w prawdziwym projekcie.
Następny krok
Chcesz przeprowadzić Warsztat Architectural KATA w swoim zespole?
Zamknięty warsztat dla programistów, architektów i tech leadów z Twojej firmy - w Waszej siedzibie lub w wybranej lokalizacji. Program i case dopasowujemy do doświadczenia zespołu.
Zobacz ofertę dla firm →Wolisz wysłać kilka osób na edycję otwartą? Zobacz terminy Warsztatu Architectural KATA.