Idealny dla zespołów, które…
Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.
Techniki modelowania procesów biznesowych: Uczestnicy nauczą się jak efektywnie modelować złożone procesy biznesowe za pomocą technik Event Stormingu, co pozwoli im lepiej zrozumieć dynamikę działania organizacji
Kreatywnego rozwiązywania problemów: Event Storming wymaga aktywnego udziału i współpracy zespołu, co sprzyja kreatywnemu myśleniu i wspólnemu rozwiązywaniu problemów
Zrozumienia potrzeb klienta: Poprzez głębsze zanurzenie się w procesach biznesowych, uczestnicy zrozumieją lepiej potrzeby i oczekiwania klientów, co przyczyni się do lepszego dostosowania produktów i usług do ich potrzeb
Projektowania elastycznej architektury systemu: Event Storming może pomóc uczestnikom w projektowaniu bardziej elastycznych i skalowalnych architektur systemowych, które łatwiej można dostosować do zmieniających się wymagań biznesowych
Pracowania na trzech poziomach Event Storming: Big Picture, Process Level i Design Level
Identyfikowania subdomeny oraz bounded contexty w podejściu Domain-Driven Design
Przekładania wyników warsztatów na backlog oraz decyzje architektoniczne
Co konkretnie robimy
- · Zdarzenie jako podstawowy element poznawania domeny
- · Cel i zastosowanie Event Storming
- · Czym Event Storming nie jest
- · Rodzaje warsztatów Event Storming
- · Definicja celu jako kryterium dostarczenia wartości
- · Dobór odpowiedniego typu warsztatu
- · Różnice pomiędzy sesją offline a online
- · Rola i odpowiedzialności facylitatora
- · Kontekst biznesowy przykładowej domeny
- · Kluczowe pojęcia i aktorzy
- · Big Picture vs Process Level vs Design Level
- · Cel każdego poziomu
- · Zakres szczegółowości i perspektywa (strategiczna vs operacyjna vs techniczna)
- · Kiedy używać danego poziomu
- · Typowe błędy przy mieszaniu poziomów
- · Identyfikacja zdarzeń domenowych
- · Eksploracja domeny i odkrywanie wiedzy
- · Określanie zależności i osi czasu
- · Typowe problemy i pułapki
- · Problem Space vs Solution Space
- · Subdomain vs Bounded Context
- · Identyfikacja granic odpowiedzialności
- · Definiowanie kompletnych procesów biznesowych
- · Uzupełnianie i walidacja wiedzy
- · Testowanie odporności procesu na zmiany
- · Weryfikacja wcześniej zdefiniowanych granic
- · Definiowanie reguł biznesowych i danych
- · Identyfikacja agregatów
- · Przekładanie wyników na rozwiązania techniczne
- · Jak zadbać o dynamikę sesji
- · Jak prowadzić wartościową dyskusję
- · Najczęstsze problemy i wyzwania
- · Techniki radzenia sobie z trudnymi sytuacjami
- · Definiowanie zadań na podstawie warsztatów
- · Identyfikacja i wizualizacja ryzyk
- · Praca z Hot Spots
- · Przekładanie wyników na backlog i architekturę
- · Wsparcie eksploracji domeny
- · Wsparcie definiowania granic i modeli
- · Wsparcie analizy procesów i jakości modeli
- · Ograniczenia i ryzyka wykorzystania AI
- · Rola AI jako narzędzia wspierającego, a nie zastępującego warsztat
- · Najważniejsze wnioski
- · Dobre praktyki
- · Najczęstsze błędy
Od briefu do retro w 30 dniach.
Brief i diagnoza
Rozmowa z liderem zespołu + krótka ankieta dla uczestników. Określamy cele, gap, kontekst.
Modyfikacja programu
Dostosowujemy moduły, case studies i przykłady kodu pod Twój stack. Akceptacja w 5 dni.
Warsztat
Sesje z trenerem, hands-on, code review. Mentor dostępny też pomiędzy sesjami.
Retro + raport
Raport z efektami dla zespołu i lidera. 30 dni konsultacji w cenie.
Wyślij brief. Odezwiemy się w 1 dzień.
Po krótkim briefie przygotujemy program i wycenę. Bez zobowiązań — to tylko punkt wyjścia do rozmowy.
Dziękujemy!
Odezwiemy się w ciągu 1 dnia roboczego.
Inne programy dla zespołów
Zobacz wszystkie →Architektura systemów przez pryzmat czynnika ludzkiego
Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.
Czysta Architektura
Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.
Mikro, makro i wszystko pomiędzy: jak podejmować decyzje o wielkości serwisu
Solidny backend i architektura — wzorce sprawdzone w środowisku produkcyjnym.