Trzej Dot Netos w składzie Łukasz Pyrzyk, Konrad Kokosa i Szymon Kulec 16 marca odwiedzili Wrocław. Maestro wydajności i sztuki optymalizacji opowiadali o tematach im bliskim: How to make a tabasco sauce from a GPU using C# - Łukasz A Garbage Collector, his collections and what it implies for you - Konrad The Secret Serialization Sauce and its spicy mysteries - Szymon Wszystko podlane odpowiednią ilością ostrego sosu, by doprowadzić uczestników do wrzenia od ilości technologicznej wiedzy 😉

TD DR: Świetna konferencja - żałujcie że was nie było. Programistok na stałe wpisał się już w kalendarz konferencji programistycznych w Polsce. Połączenie 9 grup z Białegostoku pozwoliło stworzyć wydarzenie, którego ciężko szukać w innych miejscach polski. Poprzednia edycja miała swój motyw przewodni, więc i tym razem nie mogło go zabraknąć. Popatrzcie tylko: Na pierwszy rzut oka może to dziwić / szokować, ale osoby które przyjeżdżają na konferencję dobrze czują ten styl - tutaj nie ma miejsca na napuszenie, pompatyczność, czy olbrzymią powagę.

Przeprowadzałem niedawno kolejne szkolenie z tematu Wprowadzenie do Agile. I wciąż zaskakuje mnie jak techniki zwinne są płytko rozumiane wewnątrz zespołów rozwijających oprogramowanie. Większość osób rozumie jaki cel mają konkretne spotkania Scrumowe. Jednak jest to tylko zrozumienie frameworka – nie mówi nic o podstawach za tym stojącym. Chciałbym więc w tym artykule przekazać kilka porad, w jaki sposób pracować bardziej zwinnie. Dzięki temu osiągamy więcej, pracując mniej niż wcześniej. Minimalizacja Work-in-progress Pracując w swoim otoczeniu biznesowym mamy możliwość brania coraz to większej ilości zadań.

W listopadzie wygłosiłem prezentację o tajmeniczym tytule “Nic nie wiem”. Opowiedziałem w niej jak ważne w procesie tworzenia oprogramowania jest zrozumienie prawdziwych potrzeb naszych klientów / pracowników / kolegów. Prawdziwych - czyli ich, a nie naszych. Wszystko rozbija się o projekcję. Jest to termin zaczerpnięty z psychologii opisujący mechanizmy obronne, które sprawiają że przenosimy na innych nasze poglądy / zachowania / cechy. Przyczyną jest większa dostępność własnych poglądów niż cudzych, co powoduje łatwiejsze podciąganie infomacji pod swoją kategorię.

Zostałem zaproszony by porozmawiać o architekturze produktów cyfrowych w ramach cyklu spotkań How2Product. Wyszła z tego naprawdę przekrojowa rozmowa, którą możecie posłuchać na Spotify: Rozmawialiśmy, między innymi, tematy: definicje architektury drivery architektoniczne rola architekta w zespole ewolucyjna architektura i jak ja osiągnąć Na prośbę prowadzących odpowiedziałem również pytania, które się pojawiły na chacie - macie je dostępne poniżej 😊 Pytania Gdzie Twoim zdaniem przebiega granica między architektem a product ownerem?

W ramach Wrocławskiej Grupy .NET wystąpiłem z prezentacją “Zarządzanie infrastrukturą w chmurze za pomocą Terraform”. Prezentacja dostępna jest na OneDrive. Nagranie Materiały Dokumentacja Terraform - https://www.terraform.io/docs/index.html Skrypt wstępny - https://github.com/rmaziarka/terraform-azure Repozytorium strony radekmaziarka.pl na GitHub -https://github.com/rmaziarka/radekmaziarka.pl Provider Terraform dla Azure DevOps - https://github.com/microsoft/terraform-provider-azuredevops

Każdy z nas miał taką sytuację: tworzymy sobie nasze rozwiązanie i nagle natrafiamy na nietypowy problem. Zaczyna się debugging i próbujemy odkryć, co powoduje błąd. Powstają różne work-aroundy, podchodzi się do problemu z różnych stron i nic. Minuta za minutą, godzina za godziną dochodzimy do coraz większej furii, a nie posuwamy się ani o krok. Aż w końcu natrafiamy na takie wyjście z problemu, że nas ścina z nóg. To jest właśnie taka opowieść ;)

W listopadzie wygłosiłem prezentację o tajmeniczym tytule “Nic nie wiem”. Opowiedziałem w niej jak ważne w procesie tworzenia oprogramowania jest zrozumienie prawdziwych potrzeb naszych klientów / pracowników / kolegów. Prawdziwych - czyli ich, a nie naszych. Wszystko rozbija się o projekcję. Jest to termin zaczerpnięty z psychologii opisujący mechanizmy obronne, które sprawiają że przenosimy na innych nasze poglądy / zachowania / cechy. Przyczyną jest większa dostępność własnych poglądów niż cudzych, co powoduje łatwiejsze podciąganie infomacji pod swoją kategorię.

TD DR: Świetna konferencja - żałujcie że was nie było. Programistok na stałe wpisał się już w kalendarz konferencji programistycznych w Polsce. Połączenie 9 grup z Białegostoku pozwoliło stworzyć wydarzenie, którego ciężko szukać w innych miejscach polski. Poprzednia edycja miała swój motyw przewodni, więc i tym razem nie mogło go zabraknąć. Popatrzcie tylko: Na pierwszy rzut oka może to dziwić / szokować, ale osoby które przyjeżdżają na konferencję dobrze czują ten styl - tutaj nie ma miejsca na napuszenie, pompatyczność, czy olbrzymią powagę.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Business Model Canvas Narzędziem, które świetnie współgra z Impact Mappingiem jest Business Model Canvas. Jest to zebranie swojego modelu biznesowego w formę spójnego przekazu, który zawrzemy w jednej kartce A4. Na samym początku wydaje się to zbyt krótkie, ale pozwala nam zwięźle opowiedzieć o naszym modelu biznesowym. Jest to przydatne w kontekście zbyt szerokiej oferty biznesowej, jaką chcemy wydawać na świat.

W ramach szkoły Agile wystąpiłem z warsztatem “Błędy poznawcze”. Skrypt i prezentacja dostępna jest na OneDrive. Materiały: IBM – „Minimizing code defects to improve software quality and lower development costs.” ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf * NIoST - „The Economic Impacts of Inadequate Infrastructure for Software Testing.” https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf * List of cognitive biases - https://en.wikipedia.org/wiki/List_of_cognitive_biases * Simon Sinek - Start with why – how great leaders inspire action - https://www.youtube.com/watch?v=4VdO7LuoBzM * Dan north – „Introducing deliberate discovery” https://dannorth.

W ramach 3 spotkania grupy Wrocław Agile Development wystąpiłem z prezentacją “Jak błędy poznawcze niszczą twoją pracę”. Prezentacja dostępna jest na OneDrive. Nagranie: Opis prezentacji: “Jako programiści chętnie dzielimy się swoimi historiami o porażkach technicznych. Zapominamy jednak, że największym i najbardziej kosztownym, a jednocześnie względnie prostym do uniknięcia problemem w projekcie jest niedostosowanie systemu do wymagań klienta. Projekt zrealizowany - klient nie otrzymał tego, co potrzebował; stracił czas i pieniądze.

Zainspirowany odcinkiem podcastu Patoarchitektów o narzędziach dla architektów, postanowiłem się podzielić z wami kilkoma narzędziami i technikami pracy, których używam w swojej codziennej pracy. Służą one wizualizowaniu potrzeb, osiąganiu konsensusu, decydowaniu na czym się mamy skupić. Sięgając po nie, chcemy ominąć nadmiar niepotrzebnych informacji i wziąć pod uwagę tylko to, co jest dla nas istotne. Narzędzia, które opiszę skupiają się na różnych aspektach pracy – definicji celu, wizualizacji otoczenia biznesowego, opisie procesów w naszych organizacjach i inymi.

Zainspirowany odcinkiem podcastu Patoarchitektów o narzędziach dla architektów, postanowiłem się podzielić z wami kilkoma narzędziami i technikami pracy, których używam w swojej codziennej pracy. Służą one wizualizowaniu potrzeb, osiąganiu konsensusu, decydowaniu na czym się mamy skupić. Sięgając po nie, chcemy ominąć nadmiar niepotrzebnych informacji i wziąć pod uwagę tylko to, co jest dla nas istotne. Narzędzia, które opiszę skupiają się na różnych aspektach pracy – definicji celu, wizualizacji otoczenia biznesowego, opisie procesów w naszych organizacjach i inymi.

Przeprowadzając ostatnie warsztaty zdalne zauważyłem poraz kolejny, że makiety nie działają tak jak powinny. Proste scenariusze biznesowe są świetnie zwizualizowane kolejnymi ekranami do przeklikania. Przechodząc przez nie masz wrażenie, że wszystko działa jak powinno. Niestety makiety rzadko kiedy biorą pod uwagę czas i jego sposób oddziaływania na system: procesy mogą się dziać równolegle proces A może trwać tak długo, że wpłynie to na proces B proces A może trwać tak szybko, że proces B go nie zauważy proces A może wystąpić na różnych etapach procesu B inaczej na niego oddziaływując Najczęściej tego rodzaju sytuacje wyłapujemy dopiero na produkcji - gdy koszt ich obsługi jest olbrzymi i powoduje poważne problemy dla naszych klientów.

Temat wskaźników wyprzedzających i opóźnionych (leading and lagging indicators) jest wg mnie kluczowy by móc w swojej pracy i codziennym życiu planować działania. Jeśli chcemy wiedzieć jak nam idzie, obserwować progres to: Wskaźnik wyprzedzający może nam wskazać pewne zjawisko przed jego wystąpieniem. Możemy przewidywać, że coś się stanie. Wskaźnik opóźniony pokaże nam dane zjawisko już po jego wystąpieniu. Czyli analizujemy stan obecny, potwierdzamy pewne fakty. Najłatwiej to pokazać na przykładzie naszego starania się o zmniejszenie wagi ciała:

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Diagram zapasów i przepływów Diagramy zapasów i przepływów (stocks and flows diagrams) to ciekawe narzędzie do wizualizowania połączonych ze sobą mechanizmów i obszarów. Na ich podstawie możemy wyciągać szerokie wnioski: w jaki sposób pracują nasze systemy informatyczne, jak działają zespoły, organizacje czy całe ekosystemy. Dzięki nim, zaczynamy dostrzegać skomplikowaną rzeczywistość. Niestety, przeważnie myślimy w kategoriach liniowych - jeśli mamy akcję, to pojawi się również reakcja.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Wardley Map Mapy Wardley’a są dobrym pomysłem, gdy trzeba wybrać rozwiązanie pasujące do naszego problemu. Nazwa wywodzi się od Simona Wardley’a, angielskiego doradcy i konsultanta, który jako pierwszy zastosował tą technikę mapowania. Mapa odpowiada na pytanie „Jakie jest nasze otoczenie biznesowe?” i pozwala dobrać odpowiednie rozwiązanie. Niestety bardzo często firmy wybierają narzędzia na zasadzie „gut-feelingu” zamiast zrozumieć w jakiej sytuacji rynkowej się znajdują i jak wybrane rozwiązanie pasuje do obecnej sytuacji.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Example Mapping Metoda Example Mapping została mi polecona przez Kenny’ego Baasa, który używa jej razem z Event Stormingiem. Technika świetnie się sprawdza również osobno. Można ją zastosować do zbierania wymagań, znajdowania przypadków brzegowych oraz określenia pytań, na które nie mamy odpowiedzi. Bardzo przydatne, szczególnie w kontekście grup silnie nastawionych na realizację zadań. Takie osoby będą pomijać trudniejsze przypadki, bądź nawet się nad nimi nie zastanawiać.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Value-Stream Mapping Aby analizować pracę zespołów / organizacji przydatnym warsztatem jest Value-Stream Mapping. Jest to bardzo popularna technika w ruchu Lean, która skupia się na analizie aktualnego i definicji przyszłego stanu procesów dostarczania. Chcemy poznać przebieg pracy zespołów by zrozumieć, ile trwa praca i gdzie ma wąskie gardła. Niestety, wiele organizacji nie zdaje sobie sprawy, ile czasu zabiera faktyczne dostarczanie wartości (produktów / funkcjonalności) dla ich ostatecznych klientów.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Macierze W tym miejscu nastąpi połączenie różnych technik w jedną kategorię. Wartym rozważenia pomysłem, w przypadku podejmowania decyzji, jest zwizualizowanie ich rezultatów na 2-wymiarowej macierzy. Wybieramy różne parametry osi by wymóc na uczestnikach zastanowienie się nad różnymi aspektami swoich wyborów. Takie podejście może pomóc w sytuacjach typowego, jednokierunkowego myślenia, nastawionego na bezpośrednie rezultaty. W wielu sytuacjach grupa zamyka się na konkretne rozwiązania.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Event Storming Kiedy mamy już zdefiniowany cel, to kolejnym świetnym warsztatem jest Event Storming opisany przez Alberto Brandoliniego. Jest to technika pozwalająca zwizualizować jak będzie wyglądać nasze ostateczne rozwiązanie, biorąc pod uwagę różne scenariusze i sytuacje brzegowe. Niestety tego zwykle brakuje w przypadku planowania naszego rozwiązania, zarówno technicznego jak i biznesowego. Ludzie naturalnie myślą idąc przez „happy-path”, nie biorąc pod uwagę specyficznych przypadków.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Business Model Canvas Narzędziem, które świetnie współgra z Impact Mappingiem jest Business Model Canvas. Jest to zebranie swojego modelu biznesowego w formę spójnego przekazu, który zawrzemy w jednej kartce A4. Na samym początku wydaje się to zbyt krótkie, ale pozwala nam zwięźle opowiedzieć o naszym modelu biznesowym. Jest to przydatne w kontekście zbyt szerokiej oferty biznesowej, jaką chcemy wydawać na świat.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Impact Mapping Pierwszym narzędziem, które chcę polecić jest Impact Mapping opisany przez Gojko Adzica. Jest to technika pozwalająca wybrać problem, który chcemy rozwiązywać. To jest taki swoisty krok przed. Ma to szalenie ważne konsekwencje w kontekście pracy grupowej. Zwykle staramy się złapać zbyt wiele srok za ogon. Tracimy przez to strasznie dużo czasu na zmianę kontekstów, rośnie nam work-in-progress, wolniej walidujemy nasze rozwiązania.

W ramach konferencji Boiling Frogs wystąpiłem z prezentacją “Struktura organizacji a wytwarzane oprogramowanie – prawo Conway’a w praktyce”. Prezentacja, wraz ze wszystkimi materiałami, dostępna jest na Miro.

Po mojej prezentacji o CQRS na konferencji 4Developers odezwał się do mnie Michał Fila z portalu JustGeek.it. Zapytał czy nie chciałbym opisać w krótkim artykule tego tematu na portalu. Uznałem to za dobrą okazję do rozpowszechnienia wiedzy o CQRS jako o wzorcu, który nie wymaga olbrzymich nakładów pracy od developera. Stoi to w opozycji do dużej części artykułów w sieci, które twierdzą, że nie można mieć CQRS bez Event Sourcingu, kolejek czy więcej niż jednej bazy danych.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Punktem, który często pojawia się podczas pisania systemów rozproszonych jest kwestia zapanowania nad spójnością danych. Temat jest bardzo często interpretowany w sposób kompletnie nieprzystający do rzeczywistości, w ramach której pracujemy. Ostateczna spójność (Eventual Consistency) jest odrzucana jako coś niepożądanego. Chcemy osiągnąć natychmiastową spójność, co rodzi więcej problemów niż tworzy zysków. Rozproszony system zamówień Załóżmy, że posiadamy rozproszony system e-commerce. Każdy z mikroserwisów realizuje swoją funkcję:

// artykuł napisany razem z Piotrem Klimcem – programistą w firmie Software Mind. Event Storming staje się coraz popularniejszy i jest szeroko stosowany przy projektowaniu systemów informatycznych. Branża IT to nie jedyny obszar, gdzie można wykorzystać tą technikę – tak jak pisałem w Event Storming – Narzędzie usprawniające pracę organizacji, można ją również zastosować w domenach nieinformatycznych. W tym artykule chcielibyśmy przedstawić w jaki sposób Event Storming pomógł w analizie właśnie takiej nieinformatycznej domeny - procesu rekrutacji w firmie ~ 500 osób.

// artykuł gościnny, napisany przez Piotr Klimiec – programistę w firmie Software Mind. Eventy, Hot Spoty, Commands - to podstawowe ‘building blocking’ notacji Event Stormingu. Każdy nich ma swoje ściśle określone znaczenie oraz przypisany kolor karteczki. Standardowych elementów notacji jest kilkanaście. To z ich pomocą jesteśmy w stanie zamodelować dowolny proces. Alberto Brandolini, twórca techniki Event Stormingu. często podkreśla, że notacja którą zaproponował to tylko fundament - coś od czego mamy wyjść , ale coś co nie powinno nas ograniczać.

W ramach prezentacji wewnętrznej w PGS wystąpiłem z prezentacją “Jak tworzyć software by po roku twój system nie był Legacy”. Prezentacja dostępna jest na OneDrive. Materiały na których bazowałem: What is Domain Driven Design? https://www.youtube.com/watch?v=NNFJREcalc0&list=PLZBNtT95PIW3BPNYF5pYOi4MJjg_boXCG&index=2 DevTalk i DevTalk Trio o DDD https://www.youtube.com/watch?v=WYQ3v3-4M8Y https://www.youtube.com/watch?v=u6Vb5k5sTN4  Krzysztof Muchewicz - Domain Driven Design w praktyce - https://www.youtube.com/watch?v=sWvS8GC2AO4  Sławomir Sobótka - DDD: Q&A - czyli co gryzie świadomego programistę - https://www.youtube.com/watch?v=_5oXEJ4jdmc Eric Evans- DDD & Microservices: At Last, Some Boundaries!

// artykuł napisany razem z Piotrem Klimcem – programistą w firmie Software Mind. Z Event Stormingiem jest jak z jazdą na rowerze - wymaga praktyki. Można przeczytać mnóstwo fantastycznych artykułów w internecie, obejrzeć pełno prezentacji na YouTube na ten temat, jednak to dopiero praktyka ‘zlepia’ to wszystko w całość i pozwala tak naprawdę zrozumieć czym jest Event Storming. Ile zatem kosztuje przeprowadzenie sesji dla średniej wielkości zespołu? Co trzeba mieć a bez czego można się obejść?

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, warto przejść do praktyki. W kilku następnych postach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma tworząca platformę sklepów potrzebowała narzędzia do wykonywania analiz i tworzenia raportów. Chciała ona móc, na podstawie danych w platformie, uzyskiwać bardziej złożoną wiedzę odnośnie akcji klientów w sklepie: przeszukiwane produkty, raporty sprzedażowe tygodniowe / miesięczne / kwartalne, najbardziej popularne produkty / godziny zakupów itd.

Event Storming zdobywa coraz większą popularność w świecie informatycznym i poza nim. Opisywane są przypadki coraz to nowych pomysłów na wykorzystanie tych warsztatów: jako spis procesów firmy, retrospektywa projektu czy organizacja ślubu i wesela. Powstaje więc pytanie – skąd taka popularność tego warsztatu? Co powoduje, że po zetknięciu się z tym warsztatem zaczynamy widzieć wartość z jego wykorzystywania w różnych dziedzinach swojej pracy lub życia? Dlatego ten warsztat jest taki efektywny?

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Wydawać by się mogło, że architektura zdarzeniowa nie będzie cierpiała na problemy braku kontekstów. Moduły aplikacji komunikują się zdarzeniami. W jednym miejscu informujemy o dokonaniu pewnej akcji, a reagujemy na nią w innym miejscu. Dzięki temu mamy większą separację modułów od siebie i lepszy rozkład odpowiedzialności. Prawda? O wy naiwni! Problem Załóżmy, że w module Sklepu, po zakupie produktu rzucasz zdarzenie ProductWasSold_. _ Zawiera ono następujące pola:

// artykuł napisany razem z Tomaszem Kurowskim, Scrum Masterem / Analitykiem Biznesowym w firmie Metrosoft Każdy z nas działa w organizacji, gdzie zmaga się z problemami zarówno ze swoją dzienną pracą jak i działaniem całej grupy projektowej. Niejednokrotnie trudności napotykamy także w kooperacji ze stronami zewnętrznymi jak inne firmy technologiczne czy też wybitnie wymagający interesariusze. Aby móc takie problemy rozwiązywać we wczesnych etapach egzystencji środowisko Agile stworzyło praktykę nazywaną Retrospektywą. Ma ona na celu zatrzymanie się na pewien czas i wspólne zastanowienie się jak usprawnić ich aktywności.

Ostatnio natrafiłem na tweeta Udiego Dahana o sagach - określił on Sagi / kompensacje jako nadmiarowe w większości przypadków. Część z nich wychodzi ze złego zamodelowania domeny i procesu biznesowego, część jako nieznajomość procesów zachodzących w danej domenie. Zastanowiło mnie to, czy czasem sam nie trafiam na podobny problem. Domena rezerwacji biletów Załóżmy że mamy proces sprzedaży biletów kinowych. Użytkownik wybiera godzinę seansu i salę, a następnie prezetujemy mu wygląd sali z krzesłami.

Co można zrobić dalej z rezultatem warsztatu Event Storming Big Picture? Wszystko zależy do waszych potrzeb 😉 Przygotowałem parę przykładów, które mogą być dla was wskazówką w kontynuacji warsztatów. Część z nich jest zorientowana bardziej na tworzenie rozwiązania, część skupia się na dalszym brainstormingu, a cześć ma za zadanie zakończyć warsztat estymacją i roadmapą. Kolejność dość przypadkowa. 1 - Zdjęcie / zrzut do pliku Przykład najbardziej trywialny. W niektórych biurach nie da zostawić się efektów warszatu na ściacie.

// opis jest częścią posta o warsztatach Event Storming w organizacji Event Storming Big Picture ma za zadanie rozpoznać w możliwie najkrótszym czasie jak najwięcej różnych procesów, co pozwoli następnie skupić się na najważniejszych z nich. Poniżej przykład z takiej sesji, przeprowadzonej w Rowerek.pl Przechodzimy przez wszystkie elementy standardowego warsztatu, wizualizując zdarzenia, problemy i możliwości, osoby i firmy zewnętrzne. Każda osoba ma możliwość dodania swojej kartki, nikt nie jest wyłączony.

// artykuł napisany razem z Pawłem Sroczyńskim, programistą i właścicielem firmy Rowerek.pl W poprzednim artykule opisałem warsztat Event Stormingu, wraz z jego wykorzystaniem w projektach informatycznych. Jednak, to czego brakuje w internecie, to informacji czy i w jaki sposób ten warsztat pozwalałby wyjść poza ramy systemów IT. Postanowiliśmy więc opisać jak wykorzystać Event Storming do poprawy procesów firmy lub organizacji. W opisie poniżej znajdziecie możliwe porady i nasze przemyślenia, wraz ze zdjęciami z warsztatów, które współprowadziliśmy.

// opis jest częścią posta o warsztatach Event Storming w organizacji Event Storming Single Process skupia się na bardzo dokładnym odwzorowaniu jednego procesu, w celu maksymalizacji jego zrozumienia i uporządkowania. Poniżej przykład z takiej sesji, przeprowadzonej w Objectivity W tym rodzaju warsztatu zastanawiamy się nad konkretnym procesem, odrzucając wszystko co wokół. Nie interesuje nas szerokie spektrum, skupiamy naszą uwagę tylko na tych elementach, które mogą mieć wpływ na nasz proces.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, nadszedł czas, by przejść do praktyki. W kilku następnych wpisach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma posiada w sprzedaży szeroki pakiet produktów. Każdy z produktów ma zdefiniowanych część parametrów: Waga – kg Wymiary – cm x cm x cm Zużycie energii - kWh I jeszcze kilka dodatkowych – w sumie 10.

Jak wytłumaczyć w prosty sposób czym są moduły w oprogramowaniu? Tworząc prezentację na Kariera IT wpadłem na ciekawe porównanie modułów do działów firmy. Załóżmy, że dostałeś podwyżkę. Podpisujesz aneks do umowy i następnie masz zanieść ten dokument do działu finansów. Z zewnątrz, jako pracownik (jako użytkownik modułu): nikt Ci nie pozwoli samemu zmienić sobie informacji o pensji (brak możliwości modyfikacji bazy danych spoza modułu) nie masz również zielonego pojęcia w jaki sposób składowane są dane o Tobie (brak wiedzy o strukturze wewnętrznej modułu) na straży działu stoi pani Krysia (określone API) do niej składa się podpisany aneks umowy z podwyżką (żądanie HTTP do modułu) pani Krysia mówi że przyjęła aneks (odpowiedź HTTP 200 OK) po miesiącu pracy dostajesz wyższe wynagrodzenie (wiadomość asynchroniczna otrzymana z modułu) Z wewnątrz, jako dział finansów (konkretny moduł):

W ramach konferecji Kariera IT wystąpiłem z prezentacją “Mikroserwisy - technologiczne piekło”. Prezentacja dostępna jest na OneDrive. “Główny wniosek z prezentacji @RadekMaziarka to nie pokazanie ryzyk związanych z mikroserwisami, ale uświadomienie sobie, że deweloperzy tak bardzo kochają rozwiązywanie problemów technicznych, iż często sami niepotrzebnie je tworzą - kosztem potrzeb biznesowych.” - Mariusz Bąk Nagranie z prezentacji: Opis prezentacji: “Mikroserwisy są przez wielu programistów postrzegane jako panaceum na wszystkie bolączki związane z skomplikowanym monolitem.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, nadszedł czas, by przejść do praktyki. W kilku następnych wpisach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma posiada dział administracji, który definiuje jakimi produktami obraca firma. Ustalają parametry, gabaryty, ilość. Następnie istnieje kilka rodzajów klientów, którzy mogą rezerwować te towary, dokonywać zakupów, odsprzedawać produkty dalej (w formie partnerstwa), organizować transport.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, warto przejść do praktyki. W kilku następnych postach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma posiada sieć magazynów i sklepów. W całym procesie możemy wyodrębnić następujące działy (pozostałe działy zostały pominięte dla spójności opisu):

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Mając już bazowe pojęcie, czym są konteksty i jak je zaimplementować warto pochylić się jeszcze nad jedną kwestią - języka używanego w danym kontekście. Na pierwszy rzut oka wydaje się to dziwnym pomysłem. Jednak, gdy zaczniemy implementować nasze konteksty, to nagle język może się stać dużą przeszkodą… W czym problem? Załóżmy, że nasz system przetrzymuje dane odnośnie klienta kupującego produkty. Są one używane przez dział zamówień i dla nich napisaliśmy osobny kontekst, który gromadzi te dane.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Bounded Context to koncepcja, na którą mocno stawia nacisk Eric Evans w swojej książce Domain Driven Design. Mówi ona, by aplikacje dzielić na konkteksty - części które są wewnętrznie spójne, a na zewnątrz komunikują się przez określony zbiór metod. Brzmi skomplikowanie, prawda? Wszystko się rozjaśni w dalszej częsci 😉 W czym problem? Im aplikacja jest większa tym trudniej zbudować jeden wspólny model – rozwiązanie problemu.

TD DR: Świetna konferencja - żałujcie że was nie było. Programistok na stałe wpisał się już w kalendarz konferencji programistycznych w Polsce. Połączenie 9 grup z Białegostoku pozwoliło stworzyć wydarzenie, którego ciężko szukać w innych miejscach polski. Poprzednia edycja miała swój motyw przewodni, więc i tym razem nie mogło go zabraknąć. Popatrzcie tylko: Na pierwszy rzut oka może to dziwić / szokować, ale osoby które przyjeżdżają na konferencję dobrze czują ten styl - tutaj nie ma miejsca na napuszenie, pompatyczność, czy olbrzymią powagę.

Po mojej prezentacji o CQRS na konferencji 4Developers odezwał się do mnie Michał Fila z portalu JustGeek.it. Zapytał czy nie chciałbym opisać w krótkim artykule tego tematu na portalu. Uznałem to za dobrą okazję do rozpowszechnienia wiedzy o CQRS jako o wzorcu, który nie wymaga olbrzymich nakładów pracy od developera. Stoi to w opozycji do dużej części artykułów w sieci, które twierdzą, że nie można mieć CQRS bez Event Sourcingu, kolejek czy więcej niż jednej bazy danych.

Używałem Event Sourcingu - dlaczego nie użyjemy go teraz w naszym projekcie? Ten nowy framework Vue.js jest super. Kiedy zrobimy coś w nim na produkcji? Od niedawna na Azure jest dostępny Event Grid, może dodamy go do naszej aplikacji? Wszystkie powyższe pytania są typowe dla nas - programistów. Z chęcią staramy się dodać do projektu nowe biblioteki, a gdy nam się na to nie pozwala, narzekamy na otaczający świat i na nakładane obostrzenia.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Punktem, który często pojawia się podczas pisania systemów rozproszonych jest kwestia zapanowania nad spójnością danych. Temat jest bardzo często interpretowany w sposób kompletnie nieprzystający do rzeczywistości, w ramach której pracujemy. Ostateczna spójność (Eventual Consistency) jest odrzucana jako coś niepożądanego. Chcemy osiągnąć natychmiastową spójność, co rodzi więcej problemów niż tworzy zysków. Rozproszony system zamówień Załóżmy, że posiadamy rozproszony system e-commerce. Każdy z mikroserwisów realizuje swoją funkcję:

// artykuł napisany razem z Piotrem Klimcem – programistą w firmie Software Mind. Event Storming staje się coraz popularniejszy i jest szeroko stosowany przy projektowaniu systemów informatycznych. Branża IT to nie jedyny obszar, gdzie można wykorzystać tą technikę – tak jak pisałem w Event Storming – Narzędzie usprawniające pracę organizacji, można ją również zastosować w domenach nieinformatycznych. W tym artykule chcielibyśmy przedstawić w jaki sposób Event Storming pomógł w analizie właśnie takiej nieinformatycznej domeny - procesu rekrutacji w firmie ~ 500 osób.

// artykuł gościnny, napisany przez Piotr Klimiec – programistę w firmie Software Mind. Eventy, Hot Spoty, Commands - to podstawowe ‘building blocking’ notacji Event Stormingu. Każdy nich ma swoje ściśle określone znaczenie oraz przypisany kolor karteczki. Standardowych elementów notacji jest kilkanaście. To z ich pomocą jesteśmy w stanie zamodelować dowolny proces. Alberto Brandolini, twórca techniki Event Stormingu. często podkreśla, że notacja którą zaproponował to tylko fundament - coś od czego mamy wyjść , ale coś co nie powinno nas ograniczać.

W ramach prezentacji wewnętrznej w PGS wystąpiłem z prezentacją “Jak tworzyć software by po roku twój system nie był Legacy”. Prezentacja dostępna jest na OneDrive. Materiały na których bazowałem: What is Domain Driven Design? https://www.youtube.com/watch?v=NNFJREcalc0&list=PLZBNtT95PIW3BPNYF5pYOi4MJjg_boXCG&index=2 DevTalk i DevTalk Trio o DDD https://www.youtube.com/watch?v=WYQ3v3-4M8Y https://www.youtube.com/watch?v=u6Vb5k5sTN4  Krzysztof Muchewicz - Domain Driven Design w praktyce - https://www.youtube.com/watch?v=sWvS8GC2AO4  Sławomir Sobótka - DDD: Q&A - czyli co gryzie świadomego programistę - https://www.youtube.com/watch?v=_5oXEJ4jdmc Eric Evans- DDD & Microservices: At Last, Some Boundaries!

// artykuł napisany razem z Piotrem Klimcem – programistą w firmie Software Mind. Z Event Stormingiem jest jak z jazdą na rowerze - wymaga praktyki. Można przeczytać mnóstwo fantastycznych artykułów w internecie, obejrzeć pełno prezentacji na YouTube na ten temat, jednak to dopiero praktyka ‘zlepia’ to wszystko w całość i pozwala tak naprawdę zrozumieć czym jest Event Storming. Ile zatem kosztuje przeprowadzenie sesji dla średniej wielkości zespołu? Co trzeba mieć a bez czego można się obejść?

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, warto przejść do praktyki. W kilku następnych postach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma tworząca platformę sklepów potrzebowała narzędzia do wykonywania analiz i tworzenia raportów. Chciała ona móc, na podstawie danych w platformie, uzyskiwać bardziej złożoną wiedzę odnośnie akcji klientów w sklepie: przeszukiwane produkty, raporty sprzedażowe tygodniowe / miesięczne / kwartalne, najbardziej popularne produkty / godziny zakupów itd.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Wydawać by się mogło, że architektura zdarzeniowa nie będzie cierpiała na problemy braku kontekstów. Moduły aplikacji komunikują się zdarzeniami. W jednym miejscu informujemy o dokonaniu pewnej akcji, a reagujemy na nią w innym miejscu. Dzięki temu mamy większą separację modułów od siebie i lepszy rozkład odpowiedzialności. Prawda? O wy naiwni! Problem Załóżmy, że w module Sklepu, po zakupie produktu rzucasz zdarzenie ProductWasSold_. _ Zawiera ono następujące pola:

// artykuł napisany razem z Tomaszem Kurowskim, Scrum Masterem / Analitykiem Biznesowym w firmie Metrosoft Każdy z nas działa w organizacji, gdzie zmaga się z problemami zarówno ze swoją dzienną pracą jak i działaniem całej grupy projektowej. Niejednokrotnie trudności napotykamy także w kooperacji ze stronami zewnętrznymi jak inne firmy technologiczne czy też wybitnie wymagający interesariusze. Aby móc takie problemy rozwiązywać we wczesnych etapach egzystencji środowisko Agile stworzyło praktykę nazywaną Retrospektywą. Ma ona na celu zatrzymanie się na pewien czas i wspólne zastanowienie się jak usprawnić ich aktywności.

Ostatnio natrafiłem na tweeta Udiego Dahana o sagach - określił on Sagi / kompensacje jako nadmiarowe w większości przypadków. Część z nich wychodzi ze złego zamodelowania domeny i procesu biznesowego, część jako nieznajomość procesów zachodzących w danej domenie. Zastanowiło mnie to, czy czasem sam nie trafiam na podobny problem. Domena rezerwacji biletów Załóżmy że mamy proces sprzedaży biletów kinowych. Użytkownik wybiera godzinę seansu i salę, a następnie prezetujemy mu wygląd sali z krzesłami.

Co można zrobić dalej z rezultatem warsztatu Event Storming Big Picture? Wszystko zależy do waszych potrzeb 😉 Przygotowałem parę przykładów, które mogą być dla was wskazówką w kontynuacji warsztatów. Część z nich jest zorientowana bardziej na tworzenie rozwiązania, część skupia się na dalszym brainstormingu, a cześć ma za zadanie zakończyć warsztat estymacją i roadmapą. Kolejność dość przypadkowa. 1 - Zdjęcie / zrzut do pliku Przykład najbardziej trywialny. W niektórych biurach nie da zostawić się efektów warszatu na ściacie.

// opis jest częścią posta o warsztatach Event Storming w organizacji Event Storming Big Picture ma za zadanie rozpoznać w możliwie najkrótszym czasie jak najwięcej różnych procesów, co pozwoli następnie skupić się na najważniejszych z nich. Poniżej przykład z takiej sesji, przeprowadzonej w Rowerek.pl Przechodzimy przez wszystkie elementy standardowego warsztatu, wizualizując zdarzenia, problemy i możliwości, osoby i firmy zewnętrzne. Każda osoba ma możliwość dodania swojej kartki, nikt nie jest wyłączony.

// artykuł napisany razem z Pawłem Sroczyńskim, programistą i właścicielem firmy Rowerek.pl W poprzednim artykule opisałem warsztat Event Stormingu, wraz z jego wykorzystaniem w projektach informatycznych. Jednak, to czego brakuje w internecie, to informacji czy i w jaki sposób ten warsztat pozwalałby wyjść poza ramy systemów IT. Postanowiliśmy więc opisać jak wykorzystać Event Storming do poprawy procesów firmy lub organizacji. W opisie poniżej znajdziecie możliwe porady i nasze przemyślenia, wraz ze zdjęciami z warsztatów, które współprowadziliśmy.

// opis jest częścią posta o warsztatach Event Storming w organizacji Event Storming Single Process skupia się na bardzo dokładnym odwzorowaniu jednego procesu, w celu maksymalizacji jego zrozumienia i uporządkowania. Poniżej przykład z takiej sesji, przeprowadzonej w Objectivity W tym rodzaju warsztatu zastanawiamy się nad konkretnym procesem, odrzucając wszystko co wokół. Nie interesuje nas szerokie spektrum, skupiamy naszą uwagę tylko na tych elementach, które mogą mieć wpływ na nasz proces.

Event Storming to dość młoda, ale ciesząca się coraz większą popularnością metoda do zespołowego odkrywania i modelowania procesów wewnątrz skomplikowanych domen biznesowych. Pokazuje ona jak za pomocą zdarzeń opisywać działanie naszego systemu. Technika została opisana pierwszy raz w 2013 roku przez Alberta Brandoliniego, bardzo szybko zdobyła serca osób związanych z Domain Driven Design. W najnowszym Technology Radarze ThoughtWorks Event Storming został wskazany jako polecana metoda do modelowania domeny biznesowej w systemach informatycznych.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, nadszedł czas, by przejść do praktyki. W kilku następnych wpisach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma posiada w sprzedaży szeroki pakiet produktów. Każdy z produktów ma zdefiniowanych część parametrów: Waga – kg Wymiary – cm x cm x cm Zużycie energii - kWh I jeszcze kilka dodatkowych – w sumie 10.

Jak wytłumaczyć w prosty sposób czym są moduły w oprogramowaniu? Tworząc prezentację na Kariera IT wpadłem na ciekawe porównanie modułów do działów firmy. Załóżmy, że dostałeś podwyżkę. Podpisujesz aneks do umowy i następnie masz zanieść ten dokument do działu finansów. Z zewnątrz, jako pracownik (jako użytkownik modułu): nikt Ci nie pozwoli samemu zmienić sobie informacji o pensji (brak możliwości modyfikacji bazy danych spoza modułu) nie masz również zielonego pojęcia w jaki sposób składowane są dane o Tobie (brak wiedzy o strukturze wewnętrznej modułu) na straży działu stoi pani Krysia (określone API) do niej składa się podpisany aneks umowy z podwyżką (żądanie HTTP do modułu) pani Krysia mówi że przyjęła aneks (odpowiedź HTTP 200 OK) po miesiącu pracy dostajesz wyższe wynagrodzenie (wiadomość asynchroniczna otrzymana z modułu) Z wewnątrz, jako dział finansów (konkretny moduł):

W ramach konferecji Kariera IT wystąpiłem z prezentacją “Mikroserwisy - technologiczne piekło”. Prezentacja dostępna jest na OneDrive. “Główny wniosek z prezentacji @RadekMaziarka to nie pokazanie ryzyk związanych z mikroserwisami, ale uświadomienie sobie, że deweloperzy tak bardzo kochają rozwiązywanie problemów technicznych, iż często sami niepotrzebnie je tworzą - kosztem potrzeb biznesowych.” - Mariusz Bąk Nagranie z prezentacji: Opis prezentacji: “Mikroserwisy są przez wielu programistów postrzegane jako panaceum na wszystkie bolączki związane z skomplikowanym monolitem.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, nadszedł czas, by przejść do praktyki. W kilku następnych wpisach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma posiada dział administracji, który definiuje jakimi produktami obraca firma. Ustalają parametry, gabaryty, ilość. Następnie istnieje kilka rodzajów klientów, którzy mogą rezerwować te towary, dokonywać zakupów, odsprzedawać produkty dalej (w formie partnerstwa), organizować transport.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Po poprzednich, bardziej teoretycznych postach, warto przejść do praktyki. W kilku następnych postach pokażę problemy, jakie powstały przez brak wydzielonych kontekstów w aplikacji. Wszystkie przytoczone przeze mnie przypadki braku kontekstów są realnymi przypadkami. Jedynie domena biznesowa została zmieniona na systemy zakupowe. Sytuacja biznesowa Firma posiada sieć magazynów i sklepów. W całym procesie możemy wyodrębnić następujące działy (pozostałe działy zostały pominięte dla spójności opisu):

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Mając już bazowe pojęcie, czym są konteksty i jak je zaimplementować warto pochylić się jeszcze nad jedną kwestią - języka używanego w danym kontekście. Na pierwszy rzut oka wydaje się to dziwnym pomysłem. Jednak, gdy zaczniemy implementować nasze konteksty, to nagle język może się stać dużą przeszkodą… W czym problem? Załóżmy, że nasz system przetrzymuje dane odnośnie klienta kupującego produkty. Są one używane przez dział zamówień i dla nich napisaliśmy osobny kontekst, który gromadzi te dane.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. W poprzednim poście opowiedziałem ogólnie czym są Bounded Contexty. Jednak sama idea jest niczym bez możliwości wdrożenia jej w życie. Poniżej przygotowałem krótki opis jak można konteksty wdrożyć do naszych systemów. Opiera się on na schemacie aplikacji webowej z bazą danych SQL, ale łatwo jest go przenieść również na inne rodzaje architektur. W czym problem? Aplikacja bez kontekstów używa tych samych klas / serwisów / struktur bazodanowych do rozwiązywania różnych problemów.

// wszystkie materiały zostały zebrane w podsumowaniu cyklu. Bounded Context to koncepcja, na którą mocno stawia nacisk Eric Evans w swojej książce Domain Driven Design. Mówi ona, by aplikacje dzielić na konkteksty - części które są wewnętrznie spójne, a na zewnątrz komunikują się przez określony zbiór metod. Brzmi skomplikowanie, prawda? Wszystko się rozjaśni w dalszej częsci 😉 W czym problem? Im aplikacja jest większa tym trudniej zbudować jeden wspólny model – rozwiązanie problemu.

Zostałem zaproszony by porozmawiać o architekturze produktów cyfrowych w ramach cyklu spotkań How2Product. Wyszła z tego naprawdę przekrojowa rozmowa, którą możecie posłuchać na Spotify: Rozmawialiśmy, między innymi, tematy: definicje architektury drivery architektoniczne rola architekta w zespole ewolucyjna architektura i jak ja osiągnąć Na prośbę prowadzących odpowiedziałem również pytania, które się pojawiły na chacie - macie je dostępne poniżej 😊 Pytania Gdzie Twoim zdaniem przebiega granica między architektem a product ownerem?

Używałem Event Sourcingu - dlaczego nie użyjemy go teraz w naszym projekcie? Ten nowy framework Vue.js jest super. Kiedy zrobimy coś w nim na produkcji? Od niedawna na Azure jest dostępny Event Grid, może dodamy go do naszej aplikacji? Wszystkie powyższe pytania są typowe dla nas - programistów. Z chęcią staramy się dodać do projektu nowe biblioteki, a gdy nam się na to nie pozwala, narzekamy na otaczający świat i na nakładane obostrzenia.

Przeprowadzając ostatnie warsztaty zdalne zauważyłem poraz kolejny, że makiety nie działają tak jak powinny. Proste scenariusze biznesowe są świetnie zwizualizowane kolejnymi ekranami do przeklikania. Przechodząc przez nie masz wrażenie, że wszystko działa jak powinno. Niestety makiety rzadko kiedy biorą pod uwagę czas i jego sposób oddziaływania na system: procesy mogą się dziać równolegle proces A może trwać tak długo, że wpłynie to na proces B proces A może trwać tak szybko, że proces B go nie zauważy proces A może wystąpić na różnych etapach procesu B inaczej na niego oddziaływując Najczęściej tego rodzaju sytuacje wyłapujemy dopiero na produkcji - gdy koszt ich obsługi jest olbrzymi i powoduje poważne problemy dla naszych klientów.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Event Storming Kiedy mamy już zdefiniowany cel, to kolejnym świetnym warsztatem jest Event Storming opisany przez Alberto Brandoliniego. Jest to technika pozwalająca zwizualizować jak będzie wyglądać nasze ostateczne rozwiązanie, biorąc pod uwagę różne scenariusze i sytuacje brzegowe. Niestety tego zwykle brakuje w przypadku planowania naszego rozwiązania, zarówno technicznego jak i biznesowego. Ludzie naturalnie myślą idąc przez „happy-path”, nie biorąc pod uwagę specyficznych przypadków.

Z Event Stormingiem jest jak z wojskową bitwą – przygotowany jesteś w stanie osiągnąć określony cel, nawet jeśli warunki nie są sprzyjające. Zaś będąc nieprzygotowanym - nawet najprostsza potyczka stanie się ostatecznie porażką. Nie inaczej jest z warsztatami. Planując jakikolwiek z nich (nie tylko Event Storming) warto zwrócić uwagę na możliwe problemy, które mogą się przytrafić podczas przygotowania i samego jego przeprowadzania. Mogą one spowodować, że oczekiwane rezultaty będą niższe niż oczekiwane.

Zainspirowany odcinkiem podcastu Patoarchitektów o narzędziach dla architektów, postanowiłem się podzielić z wami kilkoma narzędziami i technikami pracy, których używam w swojej codziennej pracy. Służą one wizualizowaniu potrzeb, osiąganiu konsensusu, decydowaniu na czym się mamy skupić. Sięgając po nie, chcemy ominąć nadmiar niepotrzebnych informacji i wziąć pod uwagę tylko to, co jest dla nas istotne. Narzędzia, które opiszę skupiają się na różnych aspektach pracy – definicji celu, wizualizacji otoczenia biznesowego, opisie procesów w naszych organizacjach i inymi.

Zainspirowany odcinkiem podcastu Patoarchitektów o narzędziach dla architektów, postanowiłem się podzielić z wami kilkoma narzędziami i technikami pracy, których używam w swojej codziennej pracy. Służą one wizualizowaniu potrzeb, osiąganiu konsensusu, decydowaniu na czym się mamy skupić. Sięgając po nie, chcemy ominąć nadmiar niepotrzebnych informacji i wziąć pod uwagę tylko to, co jest dla nas istotne. Narzędzia, które opiszę skupiają się na różnych aspektach pracy – definicji celu, wizualizacji otoczenia biznesowego, opisie procesów w naszych organizacjach i inymi.

W ramach Wrocławskiego JUGa wystąpiłem z prezentacją “Event Storming - zmapuj dowolny proces”. Prezentacja dostępna jest na OneDrive. Jeśli chciałbyś / chciałabyś nauczyć się przeprowadzać Event Storming na kanwie własnych projektów to polecam moje** warsztaty z Event Stormingu.** Nagranie: Materiały: Alberto Brandolini - Introducing EventStorming - https://www.eventstorming.com/book/ Radek Maziarka - Event Storming - Jak szybko odkrywać nieznane ?- /2018/12/06/event-storming-jak-szybko-odkrywac-nieznane/ Radek Maziarka - Event Storming - Narzędzie usprawniające pracę organizacji - /2018/12/10/event-storming-narzedzie-usprawniajace-prace-organizacji/ Radek Maziarka - Event Storming - Mapowanie ograniczeń - /2019/02/22/event-storming-mapowanie-ograniczen/ Radek Maziarka - Event Storming w analizie procesu rekrutacji - /2019/09/08/event-storming-w-analizie-procesu-rekrutacji-case-study/ Radek Maziarka - Event Storming - Co dalej?

// artykuł napisany razem z Piotrem Klimcem – programistą w firmie Software Mind. Event Storming staje się coraz popularniejszy i jest szeroko stosowany przy projektowaniu systemów informatycznych. Branża IT to nie jedyny obszar, gdzie można wykorzystać tą technikę – tak jak pisałem w Event Storming – Narzędzie usprawniające pracę organizacji, można ją również zastosować w domenach nieinformatycznych. W tym artykule chcielibyśmy przedstawić w jaki sposób Event Storming pomógł w analizie właśnie takiej nieinformatycznej domeny - procesu rekrutacji w firmie ~ 500 osób.

// artykuł gościnny, napisany przez Piotr Klimiec – programistę w firmie Software Mind. Eventy, Hot Spoty, Commands - to podstawowe ‘building blocking’ notacji Event Stormingu. Każdy nich ma swoje ściśle określone znaczenie oraz przypisany kolor karteczki. Standardowych elementów notacji jest kilkanaście. To z ich pomocą jesteśmy w stanie zamodelować dowolny proces. Alberto Brandolini, twórca techniki Event Stormingu. często podkreśla, że notacja którą zaproponował to tylko fundament - coś od czego mamy wyjść , ale coś co nie powinno nas ograniczać.

// artykuł napisany razem z Piotrem Klimcem – programistą w firmie Software Mind. Z Event Stormingiem jest jak z jazdą na rowerze - wymaga praktyki. Można przeczytać mnóstwo fantastycznych artykułów w internecie, obejrzeć pełno prezentacji na YouTube na ten temat, jednak to dopiero praktyka ‘zlepia’ to wszystko w całość i pozwala tak naprawdę zrozumieć czym jest Event Storming. Ile zatem kosztuje przeprowadzenie sesji dla średniej wielkości zespołu? Co trzeba mieć a bez czego można się obejść?

Event Storming zdobywa coraz większą popularność w świecie informatycznym i poza nim. Opisywane są przypadki coraz to nowych pomysłów na wykorzystanie tych warsztatów: jako spis procesów firmy, retrospektywa projektu czy organizacja ślubu i wesela. Powstaje więc pytanie – skąd taka popularność tego warsztatu? Co powoduje, że po zetknięciu się z tym warsztatem zaczynamy widzieć wartość z jego wykorzystywania w różnych dziedzinach swojej pracy lub życia? Dlatego ten warsztat jest taki efektywny?

// artykuł napisany razem z Tomaszem Kurowskim, Scrum Masterem / Analitykiem Biznesowym w firmie Metrosoft Każdy z nas działa w organizacji, gdzie zmaga się z problemami zarówno ze swoją dzienną pracą jak i działaniem całej grupy projektowej. Niejednokrotnie trudności napotykamy także w kooperacji ze stronami zewnętrznymi jak inne firmy technologiczne czy też wybitnie wymagający interesariusze. Aby móc takie problemy rozwiązywać we wczesnych etapach egzystencji środowisko Agile stworzyło praktykę nazywaną Retrospektywą. Ma ona na celu zatrzymanie się na pewien czas i wspólne zastanowienie się jak usprawnić ich aktywności.

Co można zrobić dalej z rezultatem warsztatu Event Storming Big Picture? Wszystko zależy do waszych potrzeb 😉 Przygotowałem parę przykładów, które mogą być dla was wskazówką w kontynuacji warsztatów. Część z nich jest zorientowana bardziej na tworzenie rozwiązania, część skupia się na dalszym brainstormingu, a cześć ma za zadanie zakończyć warsztat estymacją i roadmapą. Kolejność dość przypadkowa. 1 - Zdjęcie / zrzut do pliku Przykład najbardziej trywialny. W niektórych biurach nie da zostawić się efektów warszatu na ściacie.

// opis jest częścią posta o warsztatach Event Storming w organizacji Event Storming Big Picture ma za zadanie rozpoznać w możliwie najkrótszym czasie jak najwięcej różnych procesów, co pozwoli następnie skupić się na najważniejszych z nich. Poniżej przykład z takiej sesji, przeprowadzonej w Rowerek.pl Przechodzimy przez wszystkie elementy standardowego warsztatu, wizualizując zdarzenia, problemy i możliwości, osoby i firmy zewnętrzne. Każda osoba ma możliwość dodania swojej kartki, nikt nie jest wyłączony.

// artykuł napisany razem z Pawłem Sroczyńskim, programistą i właścicielem firmy Rowerek.pl W poprzednim artykule opisałem warsztat Event Stormingu, wraz z jego wykorzystaniem w projektach informatycznych. Jednak, to czego brakuje w internecie, to informacji czy i w jaki sposób ten warsztat pozwalałby wyjść poza ramy systemów IT. Postanowiliśmy więc opisać jak wykorzystać Event Storming do poprawy procesów firmy lub organizacji. W opisie poniżej znajdziecie możliwe porady i nasze przemyślenia, wraz ze zdjęciami z warsztatów, które współprowadziliśmy.

// opis jest częścią posta o warsztatach Event Storming w organizacji Event Storming Single Process skupia się na bardzo dokładnym odwzorowaniu jednego procesu, w celu maksymalizacji jego zrozumienia i uporządkowania. Poniżej przykład z takiej sesji, przeprowadzonej w Objectivity W tym rodzaju warsztatu zastanawiamy się nad konkretnym procesem, odrzucając wszystko co wokół. Nie interesuje nas szerokie spektrum, skupiamy naszą uwagę tylko na tych elementach, które mogą mieć wpływ na nasz proces.

Event Storming to dość młoda, ale ciesząca się coraz większą popularnością metoda do zespołowego odkrywania i modelowania procesów wewnątrz skomplikowanych domen biznesowych. Pokazuje ona jak za pomocą zdarzeń opisywać działanie naszego systemu. Technika została opisana pierwszy raz w 2013 roku przez Alberta Brandoliniego, bardzo szybko zdobyła serca osób związanych z Domain Driven Design. W najnowszym Technology Radarze ThoughtWorks Event Storming został wskazany jako polecana metoda do modelowania domeny biznesowej w systemach informatycznych.

Zostałem zaproszony by porozmawiać o architekturze produktów cyfrowych w ramach cyklu spotkań How2Product. Wyszła z tego naprawdę przekrojowa rozmowa, którą możecie posłuchać na Spotify: Rozmawialiśmy, między innymi, tematy: definicje architektury drivery architektoniczne rola architekta w zespole ewolucyjna architektura i jak ja osiągnąć Na prośbę prowadzących odpowiedziałem również pytania, które się pojawiły na chacie - macie je dostępne poniżej 😊 Pytania Gdzie Twoim zdaniem przebiega granica między architektem a product ownerem?

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Example Mapping Metoda Example Mapping została mi polecona przez Kenny’ego Baasa, który używa jej razem z Event Stormingiem. Technika świetnie się sprawdza również osobno. Można ją zastosować do zbierania wymagań, znajdowania przypadków brzegowych oraz określenia pytań, na które nie mamy odpowiedzi. Bardzo przydatne, szczególnie w kontekście grup silnie nastawionych na realizację zadań. Takie osoby będą pomijać trudniejsze przypadki, bądź nawet się nad nimi nie zastanawiać.

Ten wpis jest krótki spostrzeżeniem po świetnej książce Dawida Myśliwca “Przepis na człowieka”. Opisuje on w przystępny sposób jak geny wpływają na nasze życie, i jak to wszystko pod spodem działa. Jest tam ciekawy fragment o procesie kopiowania DNA, który może wydać Ci się interesujący kontekście niezawodności systemów informatycznych. By Madprime(wikipedia) (DNA replication split horizontal) CC BY-SA 2.0 Otóż podczas kopiowania nici DNA zachodzą błędy na pojedynczych elementach (nukleotydach) i uzyskana kopia nie jest idealnie identyczna.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Impact Mapping Pierwszym narzędziem, które chcę polecić jest Impact Mapping opisany przez Gojko Adzica. Jest to technika pozwalająca wybrać problem, który chcemy rozwiązywać. To jest taki swoisty krok przed. Ma to szalenie ważne konsekwencje w kontekście pracy grupowej. Zwykle staramy się złapać zbyt wiele srok za ogon. Tracimy przez to strasznie dużo czasu na zmianę kontekstów, rośnie nam work-in-progress, wolniej walidujemy nasze rozwiązania.

Używałem Event Sourcingu - dlaczego nie użyjemy go teraz w naszym projekcie? Ten nowy framework Vue.js jest super. Kiedy zrobimy coś w nim na produkcji? Od niedawna na Azure jest dostępny Event Grid, może dodamy go do naszej aplikacji? Wszystkie powyższe pytania są typowe dla nas - programistów. Z chęcią staramy się dodać do projektu nowe biblioteki, a gdy nam się na to nie pozwala, narzekamy na otaczający świat i na nakładane obostrzenia.

TD DR: Świetna konferencja - żałujcie że was nie było. Programistok na stałe wpisał się już w kalendarz konferencji programistycznych w Polsce. Połączenie 9 grup z Białegostoku pozwoliło stworzyć wydarzenie, którego ciężko szukać w innych miejscach polski. Poprzednia edycja miała swój motyw przewodni, więc i tym razem nie mogło go zabraknąć. Popatrzcie tylko: Na pierwszy rzut oka może to dziwić / szokować, ale osoby które przyjeżdżają na konferencję dobrze czują ten styl - tutaj nie ma miejsca na napuszenie, pompatyczność, czy olbrzymią powagę.

//Jesteśmy świeżo po WROC#, w tym roku z nowym składem organizatorskim, ze mną włącznie. Było bardzo ciekawie, może nieco mniej techniczne niz zwykle - za rok nadrobimy. Ale ja nie o tym… W książce “Wywieranie wpływu na ludzi. Teoria i praktyka” w rozdziale o regule niedostępności, Robert Clandini pisze jak rywalizacja powoduje, że tracimy zdrowy rozsądek i przestajemy się zastanawiać nad naszymi czynami. Potwierdzenia tego faktu można znaleźć w wielu miejscach, szczególnie w materiałach naukowych (1, 2) W piątek mogłem się o tym przekonać na własne oczy.

// wszystkie porady zostały zebrane w podsumowaniu cyklu. Zarządzaj składem zespołu Lider nie musi trwać w tym co zastanie lub w tym co zostało mu dane. Warto tutaj być proaktywnym i samemu sprawdzić jakich kompetencji w zespole brakuje. Lepiej jest szybko zareagować na brak osoby o danej kompetencji niż trwać w tym stanie powodując opóźnienia w dostarczaniu aplikacji. Możemy np. mieć zespół profesjonalistów od tworzenia aplikacji po stronie serwera, ale całkowicie nieposiadających kompetencji w pisaniu front-endu.

// wszystkie porady zostały zebrane w podsumowaniu cyklu. Deleguj zadania To jedno z najtrudniejszych zadań jakie lider ma przed sobą – nauka delegowania zadań. Oddawanie części swojej odpowiedzialności nigdy nie przychodzi łatwo. Na początku chcemy zajmować się wszystkim sami, co powoduje masę nerwów i prowadzi do całkowitego pochłonięcia naszego czasu. Brak przekazania odpowiedzialności będzie skutkować zespołem kompletnie biernym, bez własnej inicjatywy, który będzie tylko czekał, aż my podejmiemy decyzję. Łatwo jest również wpaść w pętlę mikro-kontroli, czyli drobiazgowego rozliczania zespołu z każdego pojedynczego zadania.

// wszystkie porady zostały zebrane w podsumowaniu cyklu. Zdaj sobie sprawę z bycia liderem Część osób będzie Cię słuchała bez żadnych głosów zwątpienia – będzie tutaj wchodziła w grę reguła autorytetu, opisywana przez Roberta Ciandiniego w książce “Wywieranie wpływu na ludzi. Teoria i praktyka”. Już z samej racji posiadania tytułu lidera twoi koledzy mogą być mniej chętni wchodzić z tobą w dyskusje i wyrażać swoje odmienne poglądy. Nie dlatego, że nie da się Ciebie przekonać, ale dlatego, że będą uważać, że jako lider najprawdopodobniej masz rację.

// wszystkie porady zostały zebrane w podsumowaniu cyklu. Stwórz atmosferę bezpieczeństwa Wg Google jedną z głównych cech dobrego zespołu jest bezpieczeństwo – poczucie, że nie zostanie się bezpodstawnie oskarżonym, skrytykowanym, poniżonym. Ludzie naturalnie chronią się przed negatywnymi reakcjami nie wychylając się. Bojąc się krytyki nie dzielą się swoimi, często bardzo wartościowymi przemyśleniami. Zespoły, które czują się bezpiecznie, są bardziej chętne, by próbować nowych rozwiązań, brać na siebie odpowiedzialność i podejmować nowe role w zespole.

W tym poście zebrałem materiały opublikowane w cyklu “Porady dla Team Leadera”: Poznaj mocne i słabe strony zespołu Pozwól ludziom popełniać błędy Stwórz atmosferę bezpieczeństwa Rozwijaj swoich ludzi Zdaj sobie sprawę z bycia liderem Bądź blisko wiedzy Deleguj zadania Opracujcie wspólne standardy Zarządzaj składem zespołu Myśl o celach i kosztach Podsumowując - dobry lider dba o swoich pracowników i pomaga im się rozwijać. Inspiruje do działania oraz sprawia, że zespół osiąga coraz wyższe cele.

Roy Osherove, podczas swojej prezentacji na WROC#, mówił, że genialny zespół rozwija się – nie da się go od zera stworzyć. Trzeba wykonać ciężką pracę, by zespół się ze sobą zgrał, poznał swoje słabe i mocne strony oraz sprawdził się w boju. Mając za sobą praktykę Team Leadera, chciałbym opisać kilka kwestii na jakie warto zwrócić uwagę podczas prowadzenia zespołu programistycznego. Pewnie część będzie wam znana, ale przynajmniej część powinna być dla was interesująca i wartościowa.

//Jesteśmy świeżo po WROC#, w tym roku z nowym składem organizatorskim, ze mną włącznie. Było bardzo ciekawie, może nieco mniej techniczne niz zwykle - za rok nadrobimy. Ale ja nie o tym… W książce “Wywieranie wpływu na ludzi. Teoria i praktyka” w rozdziale o regule niedostępności, Robert Clandini pisze jak rywalizacja powoduje, że tracimy zdrowy rozsądek i przestajemy się zastanawiać nad naszymi czynami. Potwierdzenia tego faktu można znaleźć w wielu miejscach, szczególnie w materiałach naukowych (1, 2) W piątek mogłem się o tym przekonać na własne oczy.

W ramach szkoły Agile wystąpiłem z warsztatem “Błędy poznawcze”. Skrypt i prezentacja dostępna jest na OneDrive. Materiały: IBM – „Minimizing code defects to improve software quality and lower development costs.” ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf * NIoST - „The Economic Impacts of Inadequate Infrastructure for Software Testing.” https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf * List of cognitive biases - https://en.wikipedia.org/wiki/List_of_cognitive_biases * Simon Sinek - Start with why – how great leaders inspire action - https://www.youtube.com/watch?v=4VdO7LuoBzM * Dan north – „Introducing deliberate discovery” https://dannorth.

W ramach 3 spotkania grupy Wrocław Agile Development wystąpiłem z prezentacją “Jak błędy poznawcze niszczą twoją pracę”. Prezentacja dostępna jest na OneDrive. Nagranie: Opis prezentacji: “Jako programiści chętnie dzielimy się swoimi historiami o porażkach technicznych. Zapominamy jednak, że największym i najbardziej kosztownym, a jednocześnie względnie prostym do uniknięcia problemem w projekcie jest niedostosowanie systemu do wymagań klienta. Projekt zrealizowany - klient nie otrzymał tego, co potrzebował; stracił czas i pieniądze.

Tytuł tego artykułu jest przynętą (zarzutką), ale celową. Przy konsultacjach z kolejnym klientem, który ma problemy z mikroserwisami, zacząłem się zastanawiać nad naszą branżą. Jak to możliwe, że brniemy ślepo w rozwiązania, które kompletnie nie są odpowiednie do problemów przed nami postawionych. Klienci chcą optymalizować swoje systemy oparte o mikroserwisy. Narzekają, że wdrożenie tej architektury nie wniosło do ich systemów żadnych benefitów. W teorii zespoły miały pracować bardziej niezależnie, serwisy miały bez trudności skalować się do olbrzymiego ruchu, a nowe funkcjonalności miały pojawiać się dzień po dniu.

W ramach konferecji Kariera IT wystąpiłem z prezentacją “Mikroserwisy - technologiczne piekło”. Prezentacja dostępna jest na OneDrive. “Główny wniosek z prezentacji @RadekMaziarka to nie pokazanie ryzyk związanych z mikroserwisami, ale uświadomienie sobie, że deweloperzy tak bardzo kochają rozwiązywanie problemów technicznych, iż często sami niepotrzebnie je tworzą - kosztem potrzeb biznesowych.” - Mariusz Bąk Nagranie z prezentacji: Opis prezentacji: “Mikroserwisy są przez wielu programistów postrzegane jako panaceum na wszystkie bolączki związane z skomplikowanym monolitem.

W ramach cyklu szkoleń Poradnia Lidera fundacji Gra o Sens przeprowadziliśmy szkolenie “Miro - wprowadzenie do tablicy wirtualnej”. Nagranie dostępne jest poniżej. Nagranie

Przeprowadzając ostatnie warsztaty zdalne zauważyłem poraz kolejny, że makiety nie działają tak jak powinny. Proste scenariusze biznesowe są świetnie zwizualizowane kolejnymi ekranami do przeklikania. Przechodząc przez nie masz wrażenie, że wszystko działa jak powinno. Niestety makiety rzadko kiedy biorą pod uwagę czas i jego sposób oddziaływania na system: procesy mogą się dziać równolegle proces A może trwać tak długo, że wpłynie to na proces B proces A może trwać tak szybko, że proces B go nie zauważy proces A może wystąpić na różnych etapach procesu B inaczej na niego oddziaływując Najczęściej tego rodzaju sytuacje wyłapujemy dopiero na produkcji - gdy koszt ich obsługi jest olbrzymi i powoduje poważne problemy dla naszych klientów.

Tytuł tego artykułu jest przynętą (zarzutką), ale celową. Przy konsultacjach z kolejnym klientem, który ma problemy z mikroserwisami, zacząłem się zastanawiać nad naszą branżą. Jak to możliwe, że brniemy ślepo w rozwiązania, które kompletnie nie są odpowiednie do problemów przed nami postawionych. Klienci chcą optymalizować swoje systemy oparte o mikroserwisy. Narzekają, że wdrożenie tej architektury nie wniosło do ich systemów żadnych benefitów. W teorii zespoły miały pracować bardziej niezależnie, serwisy miały bez trudności skalować się do olbrzymiego ruchu, a nowe funkcjonalności miały pojawiać się dzień po dniu.

Tytuł tego artykułu jest przynętą (zarzutką), ale celową. Przy konsultacjach z kolejnym klientem, który ma problemy z mikroserwisami, zacząłem się zastanawiać nad naszą branżą. Jak to możliwe, że brniemy ślepo w rozwiązania, które kompletnie nie są odpowiednie do problemów przed nami postawionych. Klienci chcą optymalizować swoje systemy oparte o mikroserwisy. Narzekają, że wdrożenie tej architektury nie wniosło do ich systemów żadnych benefitów. W teorii zespoły miały pracować bardziej niezależnie, serwisy miały bez trudności skalować się do olbrzymiego ruchu, a nowe funkcjonalności miały pojawiać się dzień po dniu.

Trzej Dot Netos w składzie Łukasz Pyrzyk, Konrad Kokosa i Szymon Kulec 16 marca odwiedzili Wrocław. Maestro wydajności i sztuki optymalizacji opowiadali o tematach im bliskim: How to make a tabasco sauce from a GPU using C# - Łukasz A Garbage Collector, his collections and what it implies for you - Konrad The Secret Serialization Sauce and its spicy mysteries - Szymon Wszystko podlane odpowiednią ilością ostrego sosu, by doprowadzić uczestników do wrzenia od ilości technologicznej wiedzy 😉

Każdy z nas miał taką sytuację: tworzymy sobie nasze rozwiązanie i nagle natrafiamy na nietypowy problem. Zaczyna się debugging i próbujemy odkryć, co powoduje błąd. Powstają różne work-aroundy, podchodzi się do problemu z różnych stron i nic. Minuta za minutą, godzina za godziną dochodzimy do coraz większej furii, a nie posuwamy się ani o krok. Aż w końcu natrafiamy na takie wyjście z problemu, że nas ścina z nóg. To jest właśnie taka opowieść ;)

TD DR: Świetna konferencja - żałujcie że was nie było. Programistok na stałe wpisał się już w kalendarz konferencji programistycznych w Polsce. Połączenie 9 grup z Białegostoku pozwoliło stworzyć wydarzenie, którego ciężko szukać w innych miejscach polski. Poprzednia edycja miała swój motyw przewodni, więc i tym razem nie mogło go zabraknąć. Popatrzcie tylko: Na pierwszy rzut oka może to dziwić / szokować, ale osoby które przyjeżdżają na konferencję dobrze czują ten styl - tutaj nie ma miejsca na napuszenie, pompatyczność, czy olbrzymią powagę.

//Jesteśmy świeżo po WROC#, w tym roku z nowym składem organizatorskim, ze mną włącznie. Było bardzo ciekawie, może nieco mniej techniczne niz zwykle - za rok nadrobimy. Ale ja nie o tym… W książce “Wywieranie wpływu na ludzi. Teoria i praktyka” w rozdziale o regule niedostępności, Robert Clandini pisze jak rywalizacja powoduje, że tracimy zdrowy rozsądek i przestajemy się zastanawiać nad naszymi czynami. Potwierdzenia tego faktu można znaleźć w wielu miejscach, szczególnie w materiałach naukowych (1, 2) W piątek mogłem się o tym przekonać na własne oczy.

Przeprowadzałem niedawno kolejne szkolenie z tematu Wprowadzenie do Agile. I wciąż zaskakuje mnie jak techniki zwinne są płytko rozumiane wewnątrz zespołów rozwijających oprogramowanie. Większość osób rozumie jaki cel mają konkretne spotkania Scrumowe. Jednak jest to tylko zrozumienie frameworka – nie mówi nic o podstawach za tym stojącym. Chciałbym więc w tym artykule przekazać kilka porad, w jaki sposób pracować bardziej zwinnie. Dzięki temu osiągamy więcej, pracując mniej niż wcześniej. Minimalizacja Work-in-progress Pracując w swoim otoczeniu biznesowym mamy możliwość brania coraz to większej ilości zadań.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Diagram zapasów i przepływów Diagramy zapasów i przepływów (stocks and flows diagrams) to ciekawe narzędzie do wizualizowania połączonych ze sobą mechanizmów i obszarów. Na ich podstawie możemy wyciągać szerokie wnioski: w jaki sposób pracują nasze systemy informatyczne, jak działają zespoły, organizacje czy całe ekosystemy. Dzięki nim, zaczynamy dostrzegać skomplikowaną rzeczywistość. Niestety, przeważnie myślimy w kategoriach liniowych - jeśli mamy akcję, to pojawi się również reakcja.

Swojego czasu bardzo mocno zainspirował mnie artykuł Michała Bartyzela o bułgarskim hotelu. Opisywał on jak niewłaściwie zaprojektowana restauracja hotelowa potrafi utrudnić zjedzenie obiadu swoim gościom. W teorii właściciele restauracji powinni tak zaplanować obsługę klientów by była ona odpowiednio szybka i bezproblemowa. Praktyka opisana przez Michała temu mocno przeczyła. Zacząłem więc w różnych miejscach sprawdzać w jaki sposób jest zaprojektowana praca restauracji. A jeśli miałem chwilę to od razu analizować jak można by ją usprawnić.

W ramach Wrocławskiej Grupy .NET wystąpiłem z prezentacją “Zarządzanie infrastrukturą w chmurze za pomocą Terraform”. Prezentacja dostępna jest na OneDrive. Nagranie Materiały Dokumentacja Terraform - https://www.terraform.io/docs/index.html Skrypt wstępny - https://github.com/rmaziarka/terraform-azure Repozytorium strony radekmaziarka.pl na GitHub -https://github.com/rmaziarka/radekmaziarka.pl Provider Terraform dla Azure DevOps - https://github.com/microsoft/terraform-provider-azuredevops

Trzej Dot Netos w składzie Łukasz Pyrzyk, Konrad Kokosa i Szymon Kulec 16 marca odwiedzili Wrocław. Maestro wydajności i sztuki optymalizacji opowiadali o tematach im bliskim: How to make a tabasco sauce from a GPU using C# - Łukasz A Garbage Collector, his collections and what it implies for you - Konrad The Secret Serialization Sauce and its spicy mysteries - Szymon Wszystko podlane odpowiednią ilością ostrego sosu, by doprowadzić uczestników do wrzenia od ilości technologicznej wiedzy 😉

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Value-Stream Mapping Aby analizować pracę zespołów / organizacji przydatnym warsztatem jest Value-Stream Mapping. Jest to bardzo popularna technika w ruchu Lean, która skupia się na analizie aktualnego i definicji przyszłego stanu procesów dostarczania. Chcemy poznać przebieg pracy zespołów by zrozumieć, ile trwa praca i gdzie ma wąskie gardła. Niestety, wiele organizacji nie zdaje sobie sprawy, ile czasu zabiera faktyczne dostarczanie wartości (produktów / funkcjonalności) dla ich ostatecznych klientów.

Używałem Event Sourcingu - dlaczego nie użyjemy go teraz w naszym projekcie? Ten nowy framework Vue.js jest super. Kiedy zrobimy coś w nim na produkcji? Od niedawna na Azure jest dostępny Event Grid, może dodamy go do naszej aplikacji? Wszystkie powyższe pytania są typowe dla nas - programistów. Z chęcią staramy się dodać do projektu nowe biblioteki, a gdy nam się na to nie pozwala, narzekamy na otaczający świat i na nakładane obostrzenia.

Wszystkie narzędzia zostały zebrane w Narzędzia pracy konsultanta - podsumowanie Wardley Map Mapy Wardley’a są dobrym pomysłem, gdy trzeba wybrać rozwiązanie pasujące do naszego problemu. Nazwa wywodzi się od Simona Wardley’a, angielskiego doradcy i konsultanta, który jako pierwszy zastosował tą technikę mapowania. Mapa odpowiada na pytanie „Jakie jest nasze otoczenie biznesowe?” i pozwala dobrać odpowiednie rozwiązanie. Niestety bardzo często firmy wybierają narzędzia na zasadzie „gut-feelingu” zamiast zrozumieć w jakiej sytuacji rynkowej się znajdują i jak wybrane rozwiązanie pasuje do obecnej sytuacji.