Odcinek poświęcony robieniu architektura w czasach Agile. Czy można w ogóle robić dobrą architekturę, kiedy wszystko jest niby zwinne?
Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Jaki będzie temat naszej rozmowy?
Łukasz Kałużny [ŁK]: Dzisiaj… W Agile nie da się robić dobrej architektury.
SW: No oczywiście, że się nie da. Chyba taki tekst, że się nie da często słyszeliśmy tak naprawdę w niejednym projekcie. Prawda?
ŁK: Tak. Spotykamy się, w sumie ja się spotykam z tym dość często albo widzę tego efekty, że się nie da, bo ktoś nie dowiózł tej architektury.
SW: Tak, czyli nie da się przez jeden przykład, że komuś się nie udało i wyciąganie wniosków, że się nie da. Też to widzę. Nawet częściowo braliśmy udział w dużym projekcie, gdzie właśnie przeszliśmy przecież z Waterfall ogromnego i jakoś dało się tę architekturę robić. Bo ja będę twierdził i się chyba w tym trochę zgodzimy, że architekturę da się zrobić, tylko trzeba robić inaczej.
ŁK: Tak, trzeba robić inaczej i w większości podejść często nie wypala.
SW: Tak, nie wypala. Moja diagnoza jest taka, że nie wypala z racji tego, że stosujemy podejścia bardzo archaiczne, podejścia sprzed 10 lat architektury. Stosujemy je do sytuacji zwinnych, czy to będzie Agile. Nazwijmy to szeroko zwinną architekturą. A te wzorce się nie aplikują kompletne tak naprawdę i tu często leży problem, czemu właśnie nie działa.
ŁK: Czyli dzisiaj zrobimy sobie troszeczkę, zabrakło mi słowa, jak się mówi… sekcję zwłok zrobimy tudzież wiwisekcję.
SW: Wiwisekscję. Można retrospektywę.
ŁK: Retrospektywę. Tak ładniej. Czyli patrząc się na nasze doświadczenia. Ja widzę, na co dzień pewnie, w roku widzę, pomagam od 10 do 20 projektów, gdzie pojawiam się, jako osoba z zewnątrz, która konsultuje, robi review, albo przychodzi już zgasić pożar.
SW: Tak moje doświadczenia są inne. Ja przez 5-6 lat prowadziłem wielki projekt, gdzie było 45 deweloperów, który właśnie ewoluował od procesu takiego typowego Waterfallu do zwinnego. Obecnie trochę mniejsze zespoły, ale za to mam przyjemność patrzenia na szkoleniach i na audytach firm, jak się zachowują, więc też często obserwuje to w krótszym okresie czasowym, ale dokładnie ten sam problem właśnie, że często słyszymy, że się nie da. A da się. Tylko trzeba inaczej.
ŁK: Czyli możemy sobie założyć, że nie da się, bo ludzie stosują troszeczkę inne podejście i wywinęli do góry nogami podejście.
SW: Tak podejście do góry nogami, takie trochę leniwe, że jak to kiedyś tak działało to teraz też tak róbmy. Jest takich parę przypadków, które ja widzę. To jest to jest przede wszystkim tworzenie rzeczy up front. Skupianie się na rzeczy technicznej tylko, a nie na rzeczach miękkich. Tematy za chwilę sobie rozwiniemy. Przede wszystkim to koncentrowanie się na projektowaniu up front, które często jest tak naprawdę. Jeżeli mieliśmy fixy to z reguły robi architekturę i teraz cały system, a w Agile to jest inaczej taka naprawdę, w zwinnej.
ŁK: Tak w zwinnych, bo w fixach było to faktycznie może koncentrowanie się, tylko tam był czas na to i nikt z nim nie dyskutował.
SW: Tak. Problem, jaki często był, to ten czas był tylko na starcie, a potem było róbcie, jak już zrobiliście i nie było czasu na zmianę zdania, ewoluowanie tego pomysłu.
ŁK: Tak.
SW: Zgadza się przy fixach nie widzieliśmy tego kosztu, ale też często przez te fixy częściej były zamykane, bo pół roku robią, jeszcze nic nie ma.
ŁK: Tak, jest w tym prawda.
SW: Tak, ale także pozostaje pytanie, jak robić to inaczej, jak podejść do architektury w takim razie. Jest takie fajne podejście, które ja widzę, które nazywa się architekturą ewolucyjną, czyli nie nastawianie się na budowanie rzeczy tylko nastawianie się na budowanie czegoś, co będzie łatwe do zmiany, co będzie łatwe w ewoluowaniu naszej architektury. To działa fajnie, ale jest bardzo bardzo trudne.
ŁK: To tak jak sobie porównam fixa trochę do Agile, że niektórym ta zmienność pewnych rzeczy przeszkadza.
SW: Oczywiście. I ta zmienność też jest bardzo kosztowna. Ona kosztuje.
ŁK: Czyli jeżeli byśmy sobie popatrzyli od czego byś zaczął, patrząc tylko z Twojej perspektywy, jak tworzysz nowy software. Załóżmy postawiły sobie do tego zwinnie. Od czego byś zaczął z perspektywy Twojej dewelopera, architekta? Jakbyś zaczął to klepać i myśleć o tym.
SW: Teraz będzie wielkie bum. Od monolitu. Tak to jest ten moment, kiedy nagle połowa z naszych słuchaczy powie: nie no w ogóle tutaj nie warto. Ja pamiętam parę lat temu usłyszałem właśnie zdanie od Fowlera, który jest dość polaryzacyjną figurą, mogę się z nim nie zgadzać, ale to zdanie mi utkwiło bardzo mocno, który powiedział, że widział wiele zespołów, które zaczynały monolitu, a potem migrowały się do mikro serwisów i im się udawało. Nie widział żadnego zespołu, który zaczynał od mikro serwisu i im się udawało. Czemu? Nie znamy na starcie domeny.
ŁK: Tak jest to prawda. Z mikro serwisami mamy tak. Monolity potrafimy budować, nie do końca poprawnie, ale są one chyba jakoś w miarę stabilne. Rzucając się na mikro serwisy to tak dużo osób jak myśli Agile, myśli zwinnie, od razu się pojawiają mikro serwisy, a potem pojawia się cały duży stos technologiczny i się okazuje, że deweloper go nie ogarnia, trzeba DevOps inżyniera albo dwóch, jeszcze Opsa, architekta i inne rzeczy.
SW: I nagle palimy 30% czasu na stawienie infrastruktury, co jest kłopotliwe. Albo jeszcze druga opcja, którą ja też widuję –olejmy tę inwestyturę całą, po prostu zróbmy mikro serwisy bez logowania, trejsowania, monitorowania, bez niczego, prostu będziemy mieli mikro serwisy. Widziałeś chyba jak to się kończy.
ŁK: Gasiłem w jednej instytucji finansowej, w której miałem dość szybkie wdrożenie i bardzo fajne, zrobiony z open source, który zachowywał się jak cloudowy. Jaka była potrzeba biznesowa, że ja tam się pojawiłem wtedy i się pojawiliśmy, jako firma. U klienta poszli w mikro serwisy właśnie bez tego, o czym mówisz. Mieli chyba już 14 mikro serwisów, przemnóż przez instancję, release raz w tygodniu ręcznie robiony zgłoszeniem, wysyłamy nową wersję, skrypty i lecą z releasami w piątek wieczorem.
SW: Jak powiedziałeś tygodniowy release managment, to moja pierwsza myśl była: to im się udało przynajmniej, ale miałem nadzieję, że nie będziesz kontynuował dalszej części opowieści. Tak. to jest przerażające generalnie, że jedna droga ominięcia i druga droga stawiania tego wszystkiego jest przerażająco kosztowna, jedna krótko druga długofalowa. Przerażające. A ja powiem tak, że raz widziałem fenomenalne zachowanie, najbardziej zwinne podejście do wytwarzania, jakie widziałem, to była to faktycznie fenomenalna relacja z biznesem. To było to, że deweloperzy hakowali coś inicjalnie, dosłownie hakowali, to rzucało wyjątki, nie było idealne. Wdrażali to na produkcję, dbali, żeby nie psuło danych. Wtedy biznes oceniał, czy to w ogóle działa, jak działa to dostawali od biznesu czas, tę gwarancję na ustabilizowanie tego, a jak nie, to oni byli szczęśliwi, że to mogli usunąć. Ten kod był crappy. Nie oszukujmy się. Widziałem takie zachowanie raz. Bardzo unikalne, fenomenalne prowadzenie ze strony biznesu, niesamowita wartość.
ŁK: Wiesz, co, tak, tylko, że ludzie, teraz patrząc się z zewnątrz na projekty, przy, których miałem okazję konsultować i gdzieś widząc jakieś problemy inne, ludzie chyba też nie rozumieją pojęcia NVP, które przy tej architekturze ewolucyjnej ma dużą rację bytu. Czyli wpierw coś pokaż od strony funkcjonalności, a potem to dopracuj albo wyrzuć. Nie ma tego poczucia i też chyba nie wszyscy przekazują to biznesowi, że robimy crappy, żeby pokazać wam, jak działa, a potem doszlifujemy.
SW: Wydaje mi się, że ludzie często robią tak, że oni pokazują to biznesowi na przykład na jakiejś prezentacji. Nie oszukujmy się, ludzie są tacy, że póki to nie wejdzie na produkcję, nikt na to realnie rzuci okiem, nikt nie weźmie do siebie generalnie. Dopiero, kiedy w końcu mamy z tego korzystać, wtedy dopiero jest rewaluacja czy to działa prawidłowo, czy jest tam wartość, co z tym zrobić. Póki nie ma na produkcji to tego nie ma w ogóle z mojej perspektywy.
ŁK: I trafiamy tak na mój problem, który widzę Agile’owy. Widziałem kupę projektów, w których pierwszy release był na przykład po 8-10 sprintach. Dlaczego mówię release, bo wszystkie wcześniejsze kończyły się tylko na środowisku.
SW: Dobrze jakby były w ogóle gdziekolwiek diplejowane poza laptopem dewelopera. No tak to ma nawet swoją nazwę wspaniałą generalnie u nas - release zerowe. Ja widziałem raz realase ujemne, że było odliczanie od minusów do zera i dopiero wtedy był start.
ŁK: Release ujemny?
SW: Tak, ujemny, że zaczęliśmy od -2 to było przygotowanie, -1 i 0 potem. Takie pomysły, bo to jest rozwiązanie problemu. Powinniśmy od pierwszego release zacząć wydawać. No to jak rozwiązujemy? Zaczynamy wcześniej.
ŁK: Okej.
SW: Czy problem został rozwiązany?
ŁK: Został. Rozumiem. Jak są historyjki zawsze mnie to fascynowało, że zrobiliśmy kawałek, ale brakuje jeszcze innych rzeczy do tej historyjki i ona nie ma całej historii bądź epika zawsze. Nienawidzę tego akurat grupowań. Dostarczyliśmy, ale nie możemy włączyć tej funkcjonalności po tym sprincie, bo brakuje x y z.
SW: Tak, albo nie możemy, bo ona popsuje inne rzeczy. Ludzie w tym momencie zapominają kompletnie o tym, że wszystko wiąże się ze zwinnym generalnie. To ma wylądować finalnie i w krótkim czasie na produkcji, ma działać, ma być używane. Możliwe, że będzie tylko działało na zasadzie tylko, że część ruchu puszczamy w tę gałąź i weryfikujemy czy faktycznie wyniki są takie jak oczekiwaliśmy. To też jest używanie, ale póki przez ten kod nie będzie przychodził jakikolwiek ruch, to nie będziemy mieli klucza liczb, jak jest używane, co jest używane, kiedy jest używane, jaki jest procent wartości i tak dalej.
ŁK: No jak popatrzymy na liczby, to ja widzę ze swojej perspektywy jeden wielki problem, ponieważ zaczynając bardzo często nie znamy liczb. To jest taki najczęstszy problem, kiedy przechodzę i zadaje pytanie, rzadko, kiedy dostaje odpowiedź o liczby patrząc od strony biznesowej.
SW: A jak dostajesz odpowiedź to wierzysz tym liczbom?
ŁK: To zależy. To zależy, ale patrząc się tak z mojej perspektywy jest tak, że często nie ma liczb i zaczynamy stosować skalę, deweloperzy, architekci, zespół czasami PM manager, u nas to jest product owner. Bardzo różne są strony nacisku.
SW: Tych ludzi jest dużo.
ŁK: Tak w szczególności, że u nas te zespoły chyba nie są samowystarczalne. Ostatnio rozmawiając, ten nasz polski Agile tak samo wygląda jak irlandzki, brytyjski, niemiecki. Wszędzie on jest podobny. Wszędzie jest ten Waterfall w sercu, ale Agile jest na sztandarach.
SW: Oczywiście, że tak. Jakbyś nie miał Agile na sztandarach albo mikro serwisów też na sztandarach, to ludzi nie zatrudnisz tak naprawdę.
ŁK: Tak i przez ten brak liczb, środki nacisku często zaczyna się w budowanie Google Scale.
SW: Zawsze budujemy Google Scale. To jest niesamowite, jak chcemy budując Google Scale de facto sami wrzucamy się w problemy skali Google, czyli zarządzania tym wszystkim i tak dalej. To jest przerażające jak ludzie chcą dużo na swoje barki wziąć.
ŁK: Tak. Jest robienie takie over inżynieringu po to, żeby to było skalowalne, zapominając o takich bardzo podstawowych wzorcach. Chyba dla mnie takie dwa najcięższe, które są to jest skalowanie horyzontalne, ale zrobione też na warstwie danych, czyli nie tylko load balancing aplikacji, ale też danych. Ludzie, że tak powiem spuszczają się, żeby zrobić to nie wiadomo, co, a nie biorą podstawowych rzeczy. Monolit jak wspomniałeś, jak weźmiemy właśnie distributed casche, sharding danych i horyzontem skanowanie samych instancji, on w większości przypadków będzie działał.
SW: Będzie działał fenomenalnie. Jest bardzo dużo firm, skali kalifornijskiej, gdzie mają monolit i się czują z tym bardzo dobrze. Tak zgadza się jak najbardziej. A ja powiem tak sharding pokazuje, że ludzie nie myślą o tym, jak modelować wpierw. Jak dane dobrze zamodelujesz, to dodanie shardingu jest dodaniem po prostu kolejnego connection stringa i przełączania się między nimi. Trywialne. ŁK:Tak, ja zawsze mówię, że sharding może być zrobiony brutalnie i konfiguracyjnie i ludzie się patrzą jak na wariata. Ale jak zamodelujesz dobrze…
SW: …nie ma problemu żadnego.
ŁK: Ale to jest to i miałem też troszeczkę jak powiedziałeś monolicie takie doświadczenie właśnie tam skalowania. Miałem warsztaty z pewnym klientem i dość fajnie wyszło, że z modelowania nam wyszedł monolit.
SW: Jak często wyjdzie.
ŁK: Tak, zrobiliśmy. No kurde panowie no to macie monolit i takie z trzy moduły na zewnątrz, które faktycznie nie pasują i mogą być ona akurat zupełnie oddzielnie rozwijane. I było, ale jak to nie mikro serwisy, nie Kubernetes? Ale, po co?
SW: Słyszałem taką sytuację parę razy. Coś robimy źle. Tu miały wyjść mikro serwisy. Przerażające jest, kiedy firma mówi okej, to zróbmy może jeszcze raz, z kierunkiem, że mają wyjść mikro serwisy. Ja nie raz robiłem szkolenie z mikro serwisów, gdzie po 3 dniach szkolenia grupa mówiła: to my musimy się w ogóle zastanowić, czy my w ogóle chcemy te mikro serwisy. A wychodziło tylko od tego, że tylko uporządkowanie wiedzy. Ja wtedy czuję, że okej to szkolenie poszło dobrze, bo zobaczyli ile ryzyka, ile problemów ich czeka tak naprawdę. Dotknąłeś elementu tego, że tak naprawdę problemem z mikro serwisami jest to, że najpierw ta infrastruktura musi. A IT się z skupia na tym, że to zróbmy procedurę, nie myśli o tym, że biznes się patrzy im cały czas na ręce. Musimy jakąś wartość dostarczać, żebyśmy byli widoczni.
ŁK: Tak to jest. Jest to fajne. Czasami tak jak mówisz, warto poświęcić ten początek na bardzo dobre setapowanie infry, info, kiedy znasz na przykład skalę, kiedy przepisujesz system, bo często jest robione takie przepisanie. Bo spotykamy się z taką techniką, że są problemy. Często jak znasz liczby wiesz, że to się nie zmieni albo jest już usługa, która jest na rynku, jest używana, więc znasz liczby, znasz wzrost, więc można poświęcić ten początek na infre.
SW: Jest jeden element infrastruktury, na który ja zawsze poświęcam czas. To jest automatyczny deployment, bo to się zwraca najszybciej ze wszystkich inwestycji tak naprawdę. To, że od pierwszego wdrożenia mogę robić to automatycznie, może być kulawe, może być niepełne, może być wgranie plików bezczelne, ale to się zwraca w ciągu pierwszych trzech sprintów w tygodniu.
ŁK: Tak uważam, że warto na to poświęcić czas. Ale broń Boże nie robić z tego sztuki dla sztuki.
SW: Nie ma sensu.
ŁK: Widziałem stawianie po kilku sprintach fajnie jak na przykład zrobisz sobie emferyczne środowiska i inne zabawki.
SW: Oczywiście.
ŁK: Robiąc w trakcie, rozbudowując to, tylko pytanie ile będzie trwał projekt, bo czasami na trzymiesięczny projekt, ktoś robi to tyle ile można byłoby z tego postawić kilka produkcji.
SW: Tak i problem jest taki, że jest problem z liczbami, bo często ja widzę, nawet jak pytamy się o liczby i otrzymujemy te liczby, to są te liczby od biznesu, to są liczby, które biznes ma nadzieję, że się wydarzą, jeżeli projekt się uda za 5 lat. A czemu tak biznes mówi? Bo wie, że z doświadczenia wynika, że my tak długo budujemy rzeczy, że oni muszą powiedzieć rzeczy, które się będą działy za pięć lat, żebyśmy je dogonili. A jak zbudujemy to zaufanie z ludźmi, że my dostarczamy szybko, to nagle jest to coraz bardziej realne. Problem jest taki, że my nie jesteśmy w stanie oszukiwać tak naprawdę, że ten projekt po prostu nie wypali. Nagle zamiast dwóch użytkowników będzie 200 000 albo 20 000. To dalej jest okej, żeby projekt żył, ale to już nie jest skala Googla, to nie te problemy tak naprawdę. Więc ten over head nawet kosztowy na utrzymaniu tego wszystkiego, tych wszystkich maszyn, ten projekt zabija. My, jako IT zabijamy projekt.
ŁK: Widziałem takie toczące się projekty. Ostatnio widziałem tak, gdzie chyba na development jest 100 serwerów czy coś takiego w sumie, to dość spory projekt a produkcja działa na 20-30.
SW: On się za chwilę skończy z tego powodu, że ktoś spojrzy na Excela, na jakimś spotkaniu rady nadzorczej czy czegokolwiek i powie ta pozycja za dużo kosztuje i po prostu zrobi przekreślenie. Tak to wygląda. Na tak wysokim poziomie zarządczym nikt nie patrzy, co to za projekt. Po prostu za duże liczby są i koniec.
ŁK: Ale wiesz to, co mówisz, to, co mówimy w sumie, to gdzieś też prowadzi do tendencji budowy tych opus magnum.
SW: Tak, mamy tendencje, jako wszyscy, że generalnie chcemy się pochwalić, co umiemy zbudować i nagle to jest takie, a to ja tu dowalę wszystko, najnowsze frameworki, w ogóle to, co ja tu potrafię pojąć, tylko ja to ogarnę, jak to będzie działało i to jest taka wielka katedra, która po prostu jest potem pusta i tam nic nie ma. To jest taka katedra, która czeka tylko na jakiś moduły biznesowe, a są dwa.
ŁK: Tak, a z drugiej strony masz ownera biznesowego też często widzę, to będzie bardzo ważne aplikacja.
SW: Oczywiście przecież nikt nie chce tworzyć mało ważnej aplikacji.
ŁK: Tak, a czasami jest ona tworzona i to też jest fajne, bo bardzo rzadko, ale zdarza mi się zobaczyć takie właśnie zespoły 3-5 osób i one tworzą taki corporate shit ups. Zapis tego może być różny. Taki smart up i on będzie bardzo istotny. Ostatnio miałem takiego product ownera, jak bardzo istotny. I co się okazuje, aplikacja faktycznie duży zasięg, bo w ciągu miesiąca 20 tysięcy użytkowników. To jest duża widoczność. Tylko, co się okazało. Ona może na przykład 3 dni nie działać i jeżeli nie działa jeden dzień aplikacja, nikt się nie obrazi, bo proces jest zupełnie poboczny. Było na początku przekombinowane parę rzeczy, a okazuje się, że mogłaby to być budowa cepa.
SW: Tak samo jak większość systemów księgowych jest nieużywana przez większość miesiąca, jest używana na zamknięcie miesiąca, gdy księgowi siadają do faktur, rozliczają wszystko, robią przelewy.
ŁK: Albo te najbardziej krytyczne moduły, kiedy zamykamy miesiąc.
SW: Tak, dokładnie. Generalnie to jest zamykanie miesiąca. Księgowi pracują tak, że oni przez dużo czasu po prostu nie mają, co robić, albo nie mają zbyt wiele a potem siedzą po 12 i więcej godzin w pracy.
ŁK: Bo wszyscy, takie osoby jak ja nawet, czy Ty pewnie robi pewne rzeczy w firmie na koniec miesiąca, bo już trzeba.
SW: Tak to mniej więcej wygląda. Nie oszukujmy się, ale trzeba brać właśnie taką specyfikę pracy pod uwagę przy projektowaniu systemu generalnie.
ŁK: Wiesz, co jedna rzecz, która jest w opus magnum fajna, sam wiem, że popełniłeś kiedyś podobną, zaczynanie od własnego frameworka, bo dużo osób od dnia zero próbuje zbudować sobie kawałek framework firmowego, albo pod projekcik.
SW: Tak popełniłem. Z perspektywy czasu uważam, że to miało sens. Było bardzo bardzo ryzykowne i to jest zawsze odpowiedź, że zależy jak daleko się pójdzie, bo nie oszukujmy się pewna standaryzacja jest potrzebna, żeby tych deweloperów ogarnąć. Freamworki są robione ogólnie, a my będziemy dostosowywali je w kontekście naszego użycia i dobrze jest zawęzić ten scope, na którym możemy operować. Z drugiej strony, jak budujemy opus magnum, to tej wartości nie dostarczymy po prostu, jej nie będzie. To bardzo trudne z punktu widzenia ego, wartości. Nie ma chyba odpowiedzi dobrej. Ryzyko jest ogromne.
ŁK: Tak, bo ja widziałem taki projekt, gdzie znowu kilka miesięcy nie było release, ale za to tyle nowych funkcjonalności doszło do frameworka. Robiliśmy też cloudowo ten project, więc pewne rzeczy były out of the box, jako funkcjonalności w bibliotekach. No, ale trzeba było to przykryć swoją wystandaryzowaną warstwową.
SW: Bo może zmienimy kiedyś Azure na aws albo bazę relacyjną na bazę Key Value. Więc to wszystko musi być abstrakcją. Tak naprawdę to jest wybór ryzyka gdzie pójść, czy przykrywamy abstrakcją, to jest naprawdę trudne.
ŁK: Przy własnych frameworkach pojawiły się dwa kulty i one są dla mnie okej i nie okej. Mamy coś, co jest starą rzeczą, bo mamy commodity, które na rynku stawanie się rzeczami towarem i dla mnie to jest bardzo fajne, ponieważ standaryzuje dużo rzeczy w IT.
SW: Tak i buduje oczekiwania, co możemy od tego produktu wymagać.
ŁK: Tak, gdzieś tam tak, jak teraz o cloud się mówi, że właśnie tak docelowo powinno być kompatybilne. Są próby, żeby stało się commodity. To jest niby fajne, ale ludzie też próbują to przemycać podejście commodity to bardziej jeszcze cargo, czyli do wożenia tego, próbują to przemycać do projektów.
SW: Tak i potem zlepiamy ten cały system i łączymy elementy, które ze sobą do końca nie powinny być połączone. Śmieliśmy się tego, że to jest tak jak budujesz dom, to łączysz cegłę, z cegłą białą z cegłą czerwoną i coś z tego wyjdzie. Tylko pytanie czy to powinno wyjść to, co wyjdzie. Czy to wygląda dobrze w ogóle.
ŁK: Budowa domu metodą gospodarską.
SW: Mnie w tym commodity i w całym ruchu martwi trochę spojrzenie na, a szczególnie w chmurze, na to czy ta usługa, o którą się opieramy, jak długo ona będzie żyła też. Bo nie oszukujmy się w chmurze też są usługi są niektóre discarded i to jest ten problem opus magnum wracany, że a ja tu użyję najnowszych rzeczy. Niektóre rzeczy nie wychodzą z preview i na to też trzeba uważać. Z drugiej strony znowu pchanie się w rzeczy stare nie jest zbyt fajne, bo nowe dają nam nowe możliwości rozwoju. Jest trudno.
ŁK: Wiesz, co ja jeszcze tak do cargo dorzucę, to mi się kojarzy, że ludzie teraz biorą dużo wzorców projektowych, biorą i wrzucają, bo one się gdzieś sprawdziły to jest troszeczkę bez popatrzenia, czy ja ich potrzebuję. Chyba tu pasuje.
SW: Ja częściej bardziej widzę odwrotną sytuację, że mam taki pattern to gdzie by go przylepić, bo ja bym chciał go użyć.
ŁK: Właśnie to jest pattern i chyba tu pasuje, bo mam tutaj, kilka ostatnio przeczytałem i tu chyba, któryś będzie pasował.
SW: Bo on rozwiązuje problem, który my może mieć 5 lat.
ŁK: Albo w ogóle. SK: Albo w ogóle.
ŁK: Dobra, jak jesteśmy przy zwinności. Mówiliśmy trochę o ewolucyjnym wyrzucaniu, wkładaniu i teraz duże zmiany i zmiany w projektach. Czasami mam wrażenie, że w starych fixowych w projektach, było łatwiej przemycić pewne zmiany, jak się waliło, jak było widać, że będzie się w projekcie źle działo, bo zaczyna się back fixing i inne rzeczy, że łatwiej się to troszeczkę w porównaniu do agilowych, bo tam byliśmy w Agile nastawieni też no nie oszukujmy się nastawieni na dostarczenie tego produktu. Stąd czasami było zbyt duże sfokusowanie, polaryzacja na te dostarczenie, a czasami nie zrobienie porządku z pewnymi rzeczami, kiedy trzeba.
SW: Mnie bardzo cieszy, że użyłeś słowa łatwiej, bo słowo łatwiej powoduje, że jak pójdziemy na skróty, to będzie łatwiej, ale jak się wyślijmy to dalej da radę zrobić. Zmianę warto rozbić na mniejsze części. To dalej da się zrobić. Jest na pewno trudniejsze, wymaga dużo więcej koordynacji, ale to dalej jest do zrobienia.
ŁK: Wiesz, co, ale czasem masz problemy, których nie rozbijesz. To taka moja perspektywa.
SW: Zgadzam się, jak najbardziej się zgadzam.
ŁK: Często przy troszkę większych już systemach, załóżmy, że team deweloperski ma 20-30 osób, to czasem powstają funkcjonalności, których tak łatwo mi przerobisz.
SW: Bez dwóch zdań tak, jak najbardziej. Są obejścia. Ważne, żeby nie zamrozić developmentu. Część zamrozimy, potem są problemy nadganianiem feature i tak dalej. Jest to to, co powiedziałeś dużo trudniejsze. Będę twierdził, że jest rabialne. A czego Ci nie żal w przejściu z fixów na Agile? Czego pozbycia się Ci nie żal?
ŁK: Dokumentacji w takim starym stylu.
SW: Dokumenty Worda piękne, które się otwiera i…
ŁK: Tak 300 stron dokumentu nie wiadomo, po co. To fakt. Dokumentacji czy dokumentacji w starej formie nie żal, bo uważam, że przepalaliśmy na to, jakość tego, która była dostarczana przed wdrożeniowej dokumentacji analitycznej czy po wdrożeniowej. Nie oszukujmy się, piszą ją juniorzy.
SW: Tak, papier wszystko przyjmie, to chyba oboje wiemy i problem jest taki, że często tam ci ludzie piszący dokumentację, rozwiązują problemy, które właśnie zauważyli, a nie problem, które powinni rozwiązywać.
ŁK: Wiesz, co rzecz, bo dokumenty jest drogi, więc powinien być pisany tekstem nie buletami i często jest lanie wody.
SW: Tak to jest często po prostu powieść, to jest nowelka przerażająca, bardzo długa nowelka, której nikt później nie czyta. Ja zawsze, jak taki dokument biorę, to moje pytanie jest jak bardzo jest to nieaktualne. To jest mój punkt wyjścia, bo to naprawdę jest nieaktualne,. Okej, ale w takim razie, czym zastępujemy dokumentację taką?
ŁK: Ja widzę kilka podejść do tego. Po pierwsze pojawia się teraz bardzo dużo tuli, żeby razem releasach i innych rzeczach po prostu ściągać historie z naszych systemów do trakowania. Jeżeli mamy dobrze opisane user stories przykładowo, back jest w miarę zatytułowany i opisany to są pluginy tak jak Azure, do dampowania. Więc możemy przykładowo release ze wszystkim, zrobić do tego release note, co się zmieniło i masz odnośniki.
SW: Widoczność jest bardzo ważna.
ŁK: To od tej strony fajnie wygląda.
SW: Ale to nie załatwia wszystkiego.
ŁK: Tak, od strony technicznej teraz jestem fanem mark down w repo w kodzie.
SW: Stosujemy, fenomenalna opcja.
ŁK: Po prostu masz folder na swój projekt, robisz do tego katalog docs, do tego katalogu wrzucasz break downy i we wszystkim czy to GitHub, Devops czy inne, żaden confluens i inne rzeczy, po prostu wszyscy chamski mark down, bo deweloper będzie uzupełniał, co trzeba.
SW: I co jest fajne w tym, możesz robić pull requesty, czyli jest review, ale jest jeszcze mega fajny feature w Devopsie, że możesz robić edycję in portal. Więc w tym momencie nie tylko muszą być ludzie techniczni, którzy to uzupełniają.
ŁK: Tak, akurat teraz powiem Ci jedną rzecz, bo już z tego ficzera w ogóle szkolenie robiłem wyobraź sobie z używania Wiki. Jest jedna rzecz licencyjna. Użytkownik musi mieć licencję basic w Azure Devops to taka ciekawostka. Są dwie wersje Wiki tam. Jak ta fajniejsza to musi mieć licencję. Nie wystarczy state holder. To taka ciekawostka dla Ciebie.
SW: Tak state holder jest bardzo ograniczony.
ŁK: Mimo, że Wiki może edytować to nie tą, która jest trzymana w normalnym repo, mimo, że git też tam jest pod spodem i jest do niego dostęp.
SW: Ciekawe czy coś się zmieni. Microsoft ma tendencję do prostowania takich ułomności bym powiedział.
ŁK: Zobaczymy. Jak jesteśmy przy dokumentacji to jest jedna rzecz, co z architektoniczną. Jest coś, co się nazwa bardzo ładnie architekture decision rekord ADR i mówi o tym, że produkowanie oryginalnie brzmiało strasznie, bo powinno być, dokument, który mówi nam o analizie, czemu wybraliśmy taki produkt anie inny, ale też powstał bardzo fajny trend, który staram się pokazywać, żeby ludzie się tym zainteresowali, spróbowali to wdrożyć przy projektach, który ma trochę potrwać. Jjest sobie wersja tego light lightweight, czyli polega to na tym, że robimy bardzo prosty mark down w repo, może być to oddzielne repo, w którym robimy sobie normalny mark down, który mówi, jaki mieliśmy problem, co zobaczyliśmy, z jakiego powodu wybraliśmy akurat to rozwiązanie. Nie wiem, czemu ma nasza dyskusja wcześniejsza rabbit vs kafka.
SW: Tak dokładnie.
ŁK: Gdzie dosłownie w ogóle nie piszemy jakiejś tam noweli, o której powiedziałeś, tylko piszemy zwykłe, brzydkie bullety tak, żeby wejść, zobaczyć i potem jest bardzo fajne, bo ktoś może Ci zrobić riview, czy można zrobić komentarze po prostu w ramach normalnej pracy z tym. Dostajemy historię. Można założyć sobie do tego inne rzeczy, można wbudować całą historię i to bardzo fajnie chroni przed syndromem takim jak jest z panem od remontów, czyli kto panu to spierdolił.
SW: Ja często widzę taką opcję, że nie patrzymy na rozwiązanie i myślimy o Jezu to jest źle. W IT jest zawsze i w życiu jest zawsze to zależy. Jeżeli nie poznamy, czemu decyzja była podjęta, jaki problem rozwiązywała, sorry, ale to w tym momencie nie możemy oceniać. Jeszcze jednego elementu, co do dokumentacji brakuje mi to takiego wysokopoziomowego spojrzenia na architektirę. Nie chodzi mi tutaj o wielką dokumentację. Prosta dokumentacja 4C, podejście 4C. Zejście na te pierwsze 3C, 2C. ŁK: Czym jest C?
SW: W zależności może być kontekstem, kontenerem, klasą, komponentem. To jest fajne porównanie do tego jak mapy są zbudowane, jak się patrzy na mapę świata to nie widzi się dróg w Polsce, bo to nie ma sensu. Więc takie spojrzenie, okej jak cały system wygląda. Wygląda tak, z takimi serwerami w ogóle gada. Potem schodzimy niżej, a ten proces biznesowy, z czym rozmawia, przez co płynie i nagle mamy takie ogólne pojęcie z lotu ptaka. To daje momentalne wdrożenie, okej to w miarę tak to wygląda. To już wiem, co, z czego wynika, co, z czym gada. Bo często dogadanie tego obszaru jest naprawdę trudne. Jak wrzucimy 4C to do tego, co powiedzieliśmy, ja jestem wesołym człowiekiem. To naprawdę wystarcza w zupełności. Jest jeszcze jeden fajny temat, który nam się trochę ominęliśmy przy naszym wielkim opus magnum, to jest to, że czas życia systemu się skraca. Obecnie to jest około 5 lat.
ŁK: Nawet troszeczkę krócej bym powiedział w niektórych przypadkach. Tak, to jest fajne miałem bardzo dobry dowcip ze spotkania, kiedy ja i parę innych osób, było takie spotkanie chyba 3 czy 4 architektów i osoba techniczna od klienta rzuciła, że musi być ta architektura przez najbliższe 10 lat.
SW: Nierealne.
ŁK: W cloudzie.
SW: To jest w ogóle nierealne.
ŁK: Powiedzieliśmy, że 3 lata damy gwarancję.
SW: Trzy lata to jest rozsądna wartość.
ŁK: Tak, że 3 lata damy. Teraz chyba też czasem uświadomić, że sposób, w jaki żyjemy ogólnie, szybciej, więcej, lepiej, zmiana, zmiana, zmiana, zmiana, dobra zmiana powoduje, że ta architektura zaraz nie będzie aktualna.
SW: Jest fajne podejście Google, który jak projektuje nowy system to projektuje system na ruch obecny razy 10 czy do 30 generalnie. Czemu? Bo oni wiedzą, że do momentu jak oni będą mieli ruch razy 40, to będą inne systemy, inne rozwiązania, inne rzeczy, inne rzeczy będą, jako commodities, co powiedzieliśmy, więc nie ma sensu robić teraz planować na ruch razy 100, bo będziemy żyli w innym świecie. A może ten system w ogóle nie dożyję. Zobaczmy, jak dużo firm jak feniks powstaje i nagle ich nie ma tak naprawdę.
ŁK: A procesy biznesowe też ostatnio tak giną.
SW: Tak giną, ale to nawet dobrze, bo ten zbiór procesów biznesowych to jest ciężar dla firmy. To jest to, czemu się często przepisuje system. Po to, żeby przeorganizować proces biznesowy, żeby go odchudzić, żeby zastanowić się, a czemu w ogóle to robimy, czemu my tego maila wysyłamy, on kosztuje nas pół godziny z każdej obsługi. Nie ma sensu, wywalamy. To jest duża wartość. To, co podsumowujemy?
ŁK: Tak, to, co zaczniesz?
SW: Tak, dla mnie takim kluczem, który chcę, żeby ludzie zrozumieli, przyjęli to jest nastawmy się na zmianę. W Agile da się, tylko są inne realia. Zmiana to jest coś, co musimy przyjąć jako normalne. To dla mnie jest bardzo ważne. Kolejne niejako implikujesz, żebyśmy mogli w ogóle ją zrobić. To jest to, że budowanie relacji z biznesem, żeby nam zaufał, żeby nam wierzył, żebyśmy mieli poparcie od biznesu, jest tak samo ważne, jak budowanie rzeczy technicznych. Nie da się Agile robić, jeżeli mamy dwie strony barykady. To musi być jeden team. Musi być zaufanie, bo czasami coś popsujemy, czasami musimy coś przepisać. Potrzebujemy tego zaufania. Musimy sobie pomagać.
ŁK: Dobra, jak Ty mówisz miękko to ja będę twardo.
SW: Dajesz.
ŁK: Zakończ sprint czymś, co można pokazać.
SW: Podpisuję się rękami, nogami.
ŁK: Tak, drugą rzeczą adr-y, o których wspomniałem, czyli jeżeli masz nie robić dokumentacji, bo często też tak bywa w Agile’owych rzeczach. Dokumentuj tylko decyzje.
SW: Tak, bardzo bardzo ważne. W zupełności się zgodzę. To są proste triki, o których mówimy. Tu nie ma nic skomplikowanego. Jak to będzie to projekty będą dużo lepsze.
ŁK: Relacja z biznesem nie jest taka łatwa.
SW: Nie jest, zgodzę się, ale to nie jest coś, co wymaga ogromnych nakładów pracy, to wymaga systematycznego rozmawiania z ludźmi. Po prostu.
ŁK: Czyli zmiana, zaufanie, częste wydawanie i dokumentowanie decyzji.
SW: Tak, tyle.
ŁK: Tyle.
SW: To kończymy. Dziękujemy.
ŁK: Dzięki.
SW: Na razie Łukasz.