Mateusz: Cześć! Witamy w kolejnym odcinku podcastu Piwnica IT. Cześć wszystkim! Z tej strony Piwnica IT z nowym odcinkiem, już szóstym. Dzisiaj razem z Wojtkiem chcielibyśmy się z Wami przywitać i porozmawiać na tematy może trochę bardziej miękkie, może bardziej związane z zarządzaniem, ponieważ chcieliśmy poruszyć temat Scruma i tematy bezpośrednio z tym Scrumem powiązanych. Cześć Wojtku.

Wojtek: Cześć Mateuszu.

Mateusz: Temat jak widzisz wybraliśmy dość miękki, więc pewnie wypadałoby zacząć, już chyba klasycznie troszeczkę, od naszego doświadczenia i od tego jak się nam pracuje w Scrumie i w ogóle od definicji tego, czym jest ten Scrum. Powiedzmy "Scrum", bo tak naprawdę pod hasłem Scrum mam na myśli dość szerokie pojęcie i zakładam, że pewnie Ty również.

Wojtek: Zdecydowanie. Scrum to dość szerokie pojęcie.

Mateusz: Dość szerokie, bo sam Scrum jest tak naprawdę tylko frameworkiem, ale bardzo często, kiedy mówimy o Scrumie, w to pojęcie wrzucamy tak naprawdę bardzo dużo pojęć bezpośrednio powiązanych ze zwinnym zarządzaniem projektami. Natomiast chciałbym zacząć przewrotnie. Miałeś przyjemność pracować w Waterfall'u albo w niezwinnych technikach zarządzania projektami.

Wojtek: Proszę bardzo, Mateuszu, my już się dobrze znamy. Ewidentnie tutaj widać nasze połączenie jaźni, bo ja dokładnie to samo pytanie chciałem Ci zadać. Ja ze swojej strony nie miałem okazji pracować nigdy w Waterfall. Miałem okazję pracować w takich projektach, czy tak naprawdę zarządzałem sam sobą, więc mogłem sobie wybrać jak to wyglądało, ale nigdy nie pracowałem w projektach stricte Waterfall'owych. Ty masz jakieś inne doświadczenia?

Mateusz: Oj, mam dużo. Zaczynałem w projektach, które właśnie w ten sposób były zarządzane tak naprawdę. Czyli klient przychodził, mówił cześć zespole, macie mi zrobić to i to, daje wam tyle i tyle pieniążków i za 3 miesiące czy tam 5 miesięcy się widzimy. No i spróbujecie mi dostarczyć to, co sobie zaplanowaliśmy. Na końcu się zazwyczaj okazywało, że trochę rynek się zmienił. To, co klient chciał trochę nie było tym co dostał, bo inaczej się zrozumieliśmy i trzeba było robić kolejne sesje poprawek i dosyć dużo frustracji zazwyczaj było. Nie wiem skąd.

Wojtek: To bardzo dziwne, zapłaciłeś za coś i dostałeś zupełnie coś innego. Jak to może być?

Mateusz: No właśnie problemy komunikacyjne, które przy takich projektach Waterfallowych się pojawiają, są dość koszmarne. Natomiast w większości przypadków zazwyczaj były to sklepy internetowe, więc tak naprawdę scope był podobny zazwyczaj do wykonania. Tylko wiesz, trudno jest przewidzieć pewne niewiadome, które mogą się pojawić w trakcie projektu, kiedy masz po prostu sztywno ustalony budżet i wtedy trzeba iść na pewne kompromisy. Z takich najbardziej klasycznych, może nie klasycznych, takich najbardziej przejaskrawionych przykładów, które mam, to była jedna firma, w której pracowaliśmy w Poznaniu. To była firma, która zajmowała się sprzedażą tonerów do drukarek w internecie i tak naprawdę ta firma w waterfallowy, nie agile'owy tworzyła scope, dostarczała go do klienta, klient nie dostarczał. Szło do kolejnej agencji kreatywnej, interaktywnej, software house'u, zwał jak zwał, w Poznaniu, która próbowała dostarczyć to samo. Co ciekawe, pamiętam ja pracowałem w dwóch firmach przez okres czterech lat. I obie te firmy miały ten sam projekt z takim samym scope'm i obie go nie dowiozły.

Wojtek: To ciekawe.

Mateusz: Taka historia. Już nie będę wymieniał nazw, ale to bardzo mi pokazało jak trudno jest zbudować projekt w oparciu już o z góry narzucony budżet w oparciu o z góry narzucony zakres rzeczy do wykonania, kiedy tak naprawdę klient sam nie do końca wie czego chce. Kiedy klienta nie ma w realizacji tego projektu, kiedy on się pojawia tak naprawdę tylko na początku, przy ustaleniu mniej więcej zakresu i na końcu, kiedy ten projekt trzeba odebrać. Później - kolejne doświadczenia, takie już może mniej waterfall'owe, ale waterfall jest mocno też, że tak powiem, zaszyty - to były projekty, gdzie klient przychodził, chciał waterfall, ale firma chciała zrobić agile. I to często prowadziło do kolejnego problemu. Jak przełożyć sztywne ramy waterfall'owych projektów, czyli takich, które mają z góry ustalony scope, budżet i czas na coś, co jest bardzo elastyczne, gdzie to zespół podejmuje decyzje o tym, co chce wziąć, kiedy chce wziąć, na podstawie oczywiście priorytetów dostarczonych od klienta. Kiedy klient nie pracuje z tym zespołem. I to był. To są bardzo trudne tematy i według mnie niemożliwe do osiągnięcia, kiedy się robi takie miksy. Waterfall może i ma rację bytu w moim odczuciu, ale najczęściej przy projektach, które są powiedzmy schematami, które można powtarzać wielokrotnie. Typu właśnie taka strona internetowa, która ma być wizytówką, czy też np. sklep internetowy, który ma sprzedawać jakiś zakres produktów, ale bez jakiś tam większych zmian w samym procesie sprzedażowym.

Wojtek: To ciekawe, co mówisz, bo ja właśnie widzę ten Scrum i wszystkie te frameworki, które są z nim związane, czy też metodologie, które są z nimi związane, jako bardzo naturalną ewolucję i rozwiązanie tych problemów właśnie, o których wspomniałeś, chociażby z Twojego doświadczenia, Mateuszu. Ale też totalnie nie widzę już miejsca na ten waterfall. Totalnie nie wyobrażam sobie projektu, w którym jeszcze taki waterfall by się sprawdził. Chyba, że byłoby to coś super małego i na zasadzie chcę dokładnie coś takiego samego.

Mateusz: A mi się wydaje, że to miejsce na waterfall'a jest. Tyle tylko, że tak jak, pamiętasz kiedyś rozmawialiśmy w ramach naszego podcastu o tym, że są różne rodzaje firm, takie jak agencje kreatywne, interaktywne, które dostarczają strony internetowe. Najczęściej są to strony wizytówki. Czasami są to sklepy internetowe oparte o jakieś WooCommerce, Magento, Presta, zwał jak zwał, cokolwiek i dla nich w ich przypadku często ta praca, którą oni mają do wykonania jest już na tyle powtarzalna po iluś tam projektach, że oni są w stanie bardzo precyzyjnie określić ile godzin dokładnie zajmie cały projekt. Sam pamiętam realizacje, w formie landing page np. wykonywałem i przychodził klient i mówił słuchaj: to ile Ci taki landing page z podłączeniem pod aplikację mobilną blablabla zajmie, to ja nie estymując tego, byłem w stanie z głowy powiedzieć ok: 40 i pół godziny. I zazwyczaj trafiałem. Więc oczywiście zdarzało się tak, że nie trafiałem. Ale fakt faktem po którymś tam powtarzalnym projekcie, który w zasadzie jest taki sam, pomimo tego, że klient mówi, że to jest, unikalne cudeńko, to tak naprawdę Ty widzisz tam schematy, które po prostu pojawiają się non stop w tych samych projektach. I dla takich projektów według mnie Waterfall jak najbardziej ma rację bytu. Tutaj Scruma wdrażać w projekt, który trwa dwa tygodnie, tydzień może - całość by się zamknęła w jednym sprincie, tak naprawdę - wydaje mi się, że to nie ma sensu.

Wojtek: Zgadzam się z tobą. Myślę, że ja tutaj chciałem podkreślić, że mówiłem o takich większych niż mniejszych projektach i zdecydowanie rozumiem, że dla takiej agencji, która robi 50. sklep, który wygląda dokładnie tak samo jak czterdziesty dziewiąty, który zrobili przed chwilą, to nie mają z tym najmniejszego problemu, że tam jest tutaj 10 tysięcy, 20, cokolwiek. Mówi klient: chcę mieć sklep i oni mówią ok, będziesz miał sklep za tyle i tyle pieniędzy. Już kopiują tak naprawdę kod, który napisali wcześniej. I rozumiem, że wtedy to działa.

Mateusz: Tak. Natomiast też warto podkreślić, że niektóre z tych rzeczy są dość duże, no bo jak by nie spojrzeć, to takie sklepy internetowe też są wyceniane na kilkaset godzin. To nie jest tak, że to się zamknie jedna osoba w dwóch tygodniach i wszystko zrobi. Konfigurację, pewnie gdy to konfigurują od zera, pewnie pewne rzeczy są takie same, powtarzalne, ale w wielu przypadkach te sklepy internetowe to jest dużo godzin do przepalenia, które po prostu trzeba wypracować. Wtedy rzeczywiście może ten projekt nie zamknie się w jednym czy dwóch sprintach, takich powiedzmy dwutygodniowych, ale fakt faktem, zajmie trochę czasu, kiedy klienta tak naprawdę nie potrzeba. Ale tu warto też podkreślić, że nawet w takiej pracy waterfall'owej jedna z technik Agile'owych jest całkiem przydatna. Tutaj mam na myśli Kanban, z jego tak naprawdę tablicą zadań, która dość dobrze porządkuje nam cały proces i wewnętrznie widzimy dość fajnie jak ten projekt idzie, w którym kierunku, czy możemy liczyć, że dopniemy projekt na czas, czy że jednak zajmie to troszeczkę więcej czasu?

Wojtek: Domyślam się, że nawet posługując się Waterfall'em, jeśli chodzi o wdrażanie jakiegokolwiek projektu, to dalej potrzebujesz czegoś do śledzenia tych zadań. Domyślam się, że jeśli to robi więcej niż jedna osoba, to potrzebują być gdzieś zadania zapisane w jakiś sposób, żebyśmy się nie pogubili, nie robili tego samego.

Mateusz: Przychodzi Project manager i wysyła Tobie listę codziennie. Dzisiaj musisz zrobić to i to, i to i to. Mailem.

Wojtek: Jest to też jakaś opcja. To prawda, ale on też musi gdzieś to trzymać, więc wiesz.

Mateusz: No tak, to prawda, on też musi gdzieś to trzymać, porządkować i nie zawsze zeszyt z możliwością przekreślenia zadań, które są do wykonania jest najlepszą opcją.

Wojtek: No tak, to prawda. No to Mateuszu, może zostawiając trochę tego Waterfall'a chciałbym Ciebie zapytać: czy w Twoim doświadczeniu, czy z Twojego doświadczenia możesz powiedzieć czy ten Scrum, o którym dzisiaj chcemy porozmawiać, rozwiązał te problemy, które wynikały właśnie z tych wdrożeń w postaci Waterfall?

Mateusz: Nie, nie rozwiązał, oczywiście, że nie. To by było zbyt proste, gdyby rozwiązały. Początkowo, pamiętasz, wspomniałem chwilę wcześniej o projekcie, który był takim miksem waterfall'a i scruma. I najczęściej było tak, że zespół chciał coś zrobić w sposób zwinny. No i brał tego, powiedzmy scruma, kanbana czy cokolwiek innego i próbował to dostarczyć w taki sposób. I w początkowej fazie, kiedy ja zacząłem pracować w takich bardziej zwinnych metodologiach to największym problemem okazywał się kontakt z klientem, który ufał temu, że rzeczywiście zarządzanie zwinne jest fajne, ale sam go do końca nie rozumiał, przez co tak naprawdę my mieliśmy kolejny moment, kolejny fragment naszego Timeline. W projektach, w których brałem udział, gdzie klient myślał, że jest zwinny. A tak naprawdę był bardzo waterfall'owy i ten Scrum był tylko utrudnieniem tak naprawdę do tej komunikacji z klientem. W moim odczuciu najważniejsze w zarządzaniu zwinnym jest to, żeby zrozumieć rolę klienta w projekcie. Bo jak sam wiesz Scrum z zasady, czy każda metodyka Agile'owa - polega na kooperacji pomiędzy tym, co mamy, tym co mamy, czyli tym co klient w tym wypadku dostarczy. Czy tam ten, kto definiuje wymagania - chce osiągnąć na ten moment, a tym, co my jako zespół mamy dowieźć, dostarczyć. Jakie mamy możliwości dostarczenia tego? Jeżeli się dobrze zrozumiemy, to dostarczymy dużo, dużo i w takiej formie, w jakiej oczekiwane jest to od nas. Jeżeli się źle zrozumiemy, albo jedna ze stron nie będzie chciała współpracować z drugą, będzie wychodziła np. z pozycji siły, albo nie będzie miała czasu na to, żeby doprecyzować swoje wymagania, to nie dostarczymy nic.

Wojtek: No tak.

Mateusz: Nawet z perspektywy czasu, kiedy pracujemy z klientami, którzy są już bardziej świadomi tego, co chcą, uczestniczą żywo tak naprawdę w projektach, które tworzymy. Widać problem komunikacyjny, który polega właśnie na tym, że klient nie zawsze do końca wie, czego chce i nie do końca definiuje wymagania. A to jest powód problemów, takie według mnie pierwsze miejsce, gdzie może nastąpić poślizg, w którym klient przekaże nam coś nie tak jak by chciał. My nie pytamy i nie dowozimy albo dowozimy nie to, co by chciał.

Wojtek: Rozumiem. No właśnie. I zgadzam się z Tobą, że ten Scrum, szczególnie w takim wdrożeniu pracy z klientem, choć nie miałem okazji dużo tak pracować, to tyle, ile miałem okazji pracować - wiem, że jest naprawdę ciężko to zrobić. Jestem ciekawy, czy ktoś spotkał się z tym zrobionym dobrze, bo ja nie miałem okazji. Ponieważ jest masa problemów od samej wiedzy, tak jak wspominałeś klienta jeśli chodzi o procesy: jak to powinno wyglądać - po definicje wymagań, po oczekiwania klienta odnośnie tego jak ten proces wygląda, po rzeczy takie jak samo definiowanie jeszcze raz tych zadań w takim kontekście programistycznym: ciężko czasami wytłumaczyć klientowi, że potrzebujesz dwóch tygodni na zrobienie, wdrożenie jakiegoś API czy czegokolwiek. Też specyficzność i poziom techniczny tych zadań, domyślam się, że może być bardzo różny. Dla klientów może być to mylące.

Mateusz: Tak, tu jest dużo rzeczy, które mogą być dla klienta mylące. Samo definiowanie zadań, pomimo tego, że mamy narzędzia, które mają to usprawniać, takie jak chociażby UserStory. Natomiast samo to, że my definiujemy, zdefiniujemy te wymagania, określimy co my chcemy, to tak naprawdę jeszcze pojawiają się kolejne schody: jak to dostarczyć, kiedy co zostanie dostarczone? I co znaczy, że zadanie zostało dostarczone czy też wykonane? Tutaj pojawiają się kolejne problemy. I tutaj chociażby określenie estymat. Estymata tak naprawdę dla klienta jest czymś ważnym, no bo on de facto będzie to rozliczał w jakikolwiek sposób. Natomiast dla nas jest powinna być istotna z tej perspektywy, żebyśmy chociaż byli w stanie oszacować możliwości zespołu, ale z drugiej strony nigdy nie jesteśmy w stanie tego wykonać w stu procentach dobrze. Bo oszacowanie zadania, które dla nas jest czymś nowym, można powiedzieć, że jest bardzo trudne. Czy zajmie nam to dzień, dwa, godzinę, czy nawet cały tydzień. A odwracając troszeczkę to pole estymat. Kiedy szacujemy w sposób konkretny, czasowy, tak i przechodząc np. na te tzw. story pointy, czyli wartości, które określają czasochłonność czy też wymagany poziom trudności danego zadania, skomplikowania zadania. Tak naprawdę to to już jest w ogóle niejasne dla klienta. Będąc klientem nie wiem czy byłbym w stanie wytłumaczyć za co ja płacę.

Wojtek: To jest mega skomplikowane, co i dla Ciebie jako programisty w takim Scrumie, o którym rozmawiamy. Z jednej strony masz te etymacje, w których chciałbyś wyrobić i te dwutygodniowe sprinty standardowe i określanie tych zadań, w szczególności jak robić coś nowego, które jest praktycznie niemożliwe, przynajmniej z mojej perspektywy. Zdecydowanie nie jestem też najlepszy, jeśli chodzi o estymacje zadań. No i też z perspektywy klienta, który wiesz, tak jak powiedziałeś, rozlicza Cię potem z tego i teraz tłumaczenie mu za każdym razem czemu Twoje estymacje albo próbowanie wytłumaczenia dlaczego to zajęło tyle, a nie tyle ile myślałeś, że zajmie, domyślam się, że może być mega skomplikowane.

Mateusz: Tak, ta perspektywa klienta według mnie jest bardzo trudna. I jeżeli chcemy przejść na techniki zarządzania zwinne, to według mnie pierwsze co powinniśmy zrobić to uświadomić sobie rolę, ważną rolę i chyba najważniejszą w całym projekcie nie zespołu technicznego, a właśnie klienta, który też musi przejść, chcieć przejść i chcieć zrozumieć na czym polega zarządzanie zwinne. Ok, ale sam Scrum to jest tak naprawdę tylko narzędzie. I na pewno jak pracowałeś, mówili ci, że pracujesz w Scrumie.

Wojtek: Mówili mi dużo, mówili mi dużo razy.

Mateusz: To pewnie nie zawsze to był Scrum.

Wojtek: Tak, to prawda. W ogóle ten Scrum, gdzie nie pracowałem na przestrzeni jednego projektu, mam wrażenie, że u nas się zmieniał tysiąc razy. Może trochę przesadzam, ale zdecydowanie dużo razy ewoluował i zmieniał swoją perspektywę, więc zdecydowanie jest to ciekawe. I chyba nigdy nie pracowałem w takim prawdziwym, prawdziwym Scrumie, gdzie miałem do czynienia chociażby z klientem.

Mateusz: Tutaj nie musi być klient, może być PO tak naprawdę, czyli Product Owner, który de facto powinien, tu też jest ważna kwestia tego, co wiem, powinna to być osoba, która reprezentuje interesy klienta, a więc w idealnym świecie jest od klienta, jest osobą wyznaczoną przez klienta czy też inwestora do tego, żeby właśnie zbierać wymagania, przygotowywać w odpowiedni sposób i dostarczać do zespołu. Tutaj bardzo często były patologie z tym związane, a to naszym PO będzie ktoś wewnętrznie od nas, co nie jest może najgorszym rozwiązaniem. Tylko ta rola jest wtedy podwójnie trudna.

Wojtek: No tak, to prawda.

Mateusz: Bo tutaj musi być obiektywny, musi obiektywnie zbierać te wymagania i samo zbieranie wymagań od samego klienta, od inwestora jest trudne. Szczególnie jeśli to nie jest jednostka, tylko jest to grupa ludzi: jakiś stakeholderów i dostarczanie ich w odpowiedni sposób, przygotowanie i dostarczanie ich do zespołu to jest już kolejna, że tak powiem, belka rzucana pod nogi. No i trzeci stopień, czyli kiedy PO, jest od nas wewnętrznie zespołu i on ma jakąś zażyłość z zespołem bliższą. To tak naprawdę to musi być naprawdę trudne. Ja miałem raz przyjemność pracować w takim czystym Scrumie. Mieliśmy Scrum Mastera z prawdziwego zdarzenia, które trudnił się tylko tym i zajmował się w zasadzie wdrażaniem Scruma w całej organizacji. I tutaj tak naprawdę główną, oprócz tego, że mieliśmy ciągłe ciągle spotkania odnośnie samych filarów Scruma, które wymagały od nas bardzo głębokiego zrozumienia tych kilkunastu stron agile Manifesto czy tam Scrum Manifesto to tak naprawdę duży nacisk był na to, żeby traktować zespół jako zespół, czyli jako grupę ludzi, które sąodpowiedzialne za dostarczenie projektu bez dzielenia ich na kompetencje. Nie ma znaczenia, czy ktoś jest testerem, frontend'owcem, backend'owcem czy kimkolwiek innym w projekcie, w zespole. Jeżeli jest w tym zespole, to znaczy, że on jest też odpowiedzialny za dostarczenie czegoś. Czy jeżeli nie mam kompetencji bezpośrednio związanych ze zrobieniem czegoś, ale jestem częścią zespołu, to muszę to wyestymować w jakiś sposób. W taki sposób jakbym to ja miał to wykonać. Wyobraź sobie: jesteś frontendowcem, nigdy nie pisałeś nic w backendzie, nagle dostajesz zadanie do wyestymowania - patrzysz ni cholerę, nie wiesz co to jest, z czym to się je, tych technologi nie widziałeś na oczy - masz to wyestymować. Wyestymujesz to na maksa na wysokich wartościach, bo jeżeli jesteś szczery wobec tego to zazwyczaj jest tak, że zespół powinien się zgodzić na to, co zrobi najsłabszy z tych członków zespołu i potem te estymaty mogą być bardzo rozłożone w czasie.

Wojtek: No zgadzam się. Czy to w ogóle nie zakłada, że mamy bardzo podobne kompetencje, jeśli chodzi o zespół i w momencie, kiedy pojawiają się te dysproporcje, to troszkę przestaje mieć to sens. Jak ja mogę brać odpowiedzialność za backend, powiedzmy, jeśli go nie znam. Czy tak samo jakiś backend developer jak może brać odpowiedzialność za frontend, którego nie rozumie?

Mateusz: Dlatego uważam, że to jest akurat patologiczne i że trudno jest powiedzieć, że zespół musi mieć te same kompetencje, bo w samym projekcie IT, który jest dość złożonym, pomimo wszystko trudno jest zebrać zespół o tych samych kompetencjach, który będzie realizował cały projekt w stu procentach.

Wojtek: Zdecydowanie. Też pytanie, czy to w ogóle ma sens. Myślę, że to naturalne, że ludzie się specjalizują, interesują ich różne rzeczy. Dlatego masz tyle też tych ról. Nie masz roli developera zazwyczaj tylko masz frontend developera albo nawet React developera. Jeśli chodzi o bycie programistą, tak samo jest po stronie backendu. Nie jesteś backend developerem czy też software developerem. Jesteś Java developerem powiedzmy czy Ruby On Rails developerem?

Mateusz: To prawda, ale nawet jak byśmy spojrzeli sobie na to, co się teraz dzieje na rynku, to bardzo często już nie jest tak, że szukają frontend developerów, tylko raczej software engineer albo full stack developerów albo cokolwiek innego, programistów bez określenia technologii, z założeniem, że osoba która orientuje się w technologiach po prostu będzie w stanie dość płynnie wejść w nową technologię i dobierać ją pod kątem tego, co trzeba napisać czy też przygotować. Trochę w moim odczuciu jest to zwodnicze, bo pomimo tego, że zgadzam się, że należy się specjalizować, bo jest za dużo tej wiedzy do ogarnięcia, i że dobry programista powinien mieć dość szerokie pojęcie, to jeżeli się wyspecjalizuje w jednej dziedzinie to w innych nie będzie w stanie być alfą i omegą. Zawsze jest ten taki moment, kiedy programista z jednej strony powiedzmy jest full stackiem, ale np. z naciskiem na którąś ze stron.

Wojtek: Myślę, że tak dokładnie też tak wygląda nasza sytuacja. To nie jest tak, że Ty czy ja napisaliśmy jakiegoś serwera, wystawili bazy danych i tak dalej, i tak dalej. Tylko że to nie jest to, czym się zajmujemy i to chyba co nas najbardziej jara, mówiąc kolokwialnie. Dodatkowo jeszcze myślę, że jeśli chodzi o bycie full stackiem, co jest troszkę odpowiedzialną dyskusją w sumie, ale możemy już dokończyć temat. To jest kwestia trafiania z technologią. Ciężko jest znaleźć full stacka, to znaczy ciężko jest znaleźć osobę, która będzie się specjalizowała akurat w tych dwóch technologiach. Szczególnie, jeśli nie jest to jakieś oczywiste połączenie. Która będzie miało doświadczenie zarówno w tej technologii, która jest w projekcie na frontendzie i na backendzie, przecież tych kombinacji może być tysiące.

Mateusz: Tak, dokładnie. React, Angular, Vue, Svelte, Next, ble ble ble ble ble, czysty JS. Po drugiej stronie Java, Python, .NET i miliony innych jeszcze kombinacji. Nawet JavaScript tam też może się znaleźć.

Wojtek: No dobra, ale wracając do tematu Agile jeszcze, a dokładniej Scrum. Chciałbym się dowiedzieć i poznać Twoją opinię jak wygląda sprawa jeśli chodzi o Ciebie i ceremoniały związane z Scrumem.

Mateusz: W zasadzie, jeśli chodzi o Scruma i ceremoniały to tak na pierwszy rzut oka pierwszy ceremoniał, który przychodzi mi do głowy - to jest daily. To jest coś, co w zasadzie robią wszystkie zespoły. To jest chyba ceremoniał, który najczęściej jest wyciągany z listy ceremoniałów Scruma i wrzucany praktycznie do każdego sposobu zarządzania projektem. I daily jest, najprościej rzecz ujmując, taki najprostsze, krótkie spotkanie, które ma za zadanie podsumować nam, co się wydarzyło w ostatnim czasie, żeby wyrównać wiedzę wszystkich członków zespołu na temat aktualnego postępu prac, problemów, które mamy, żeby znaleźć po prostu te najsłabsze punkty i je jak najszybciej wyeliminować. Trochę też mi się wydaje, że tutaj też mamy często bardzo dużo problemów z tym daily. Po pierwsze za długie. Co do zasady powinno być krótkie. To powinien być szybki update. Dlatego też często stosuje się, stosowało się przynajmniej daily na stojąco.

Wojtek: Teraz wszyscy siedzą.

Mateusz: Tak i potem gaduły. Najdłuższe daily na którym byłem trwało 3 godziny.

Wojtek: O kurcze, to ja zdecydowanie nie. Dla mnie pół godziny to dużo.

Mateusz: To jest długo, To jest długo, bardzo długo, bo Daily się mówi, że powinno trwać 15 minut. Ale jak się zespół rozgada i wejdzie zbyt głęboko w szczegóły techniczne, to potem to trwa i trwa i trwa i może trwać dość długo. Natomiast fakt faktem, to jest pierwsza patologia tego ceremoniału. Druga to jest ten case, że albo Scrum Master, który jest na takim spotkaniu, odpytuje po kolei osoby i te osoby mówią o tym, co robiły, nie zwracając uwagi na to, co się wydarzyło u pozostałych członków zespołu. Ewentualnie każdy mówi, ale mówi do Scrum Mastera lub osoby prowadzącej, a nie do zespołu. I to jest dość istotne, bo tak naprawdę, jeżeli patrzymy na Scruma z tej perspektywy wspomnianej na początku, czyli wszyscy jesteśmy odpowiedzialni za dostarczenie tego projektu, tego sprintu, tego naszego scope'u, naszego Backlogu zadań. Tak, to mamy za zadanie pomóc pozostałym, jeżeli mają z tym problem, czyli tak naprawdę powiedzmy, że Marcin siedzi już czwarty dzień nad jakimś zadaniem i komunikuje dość jasno na daily, że ma z tym problem, ale nikt od trzech dni mu nie pomaga. Bo każdy jest skupiony na swoim fragmencie i potem się okaże na dwa dni przed końcem sprintu, że on nadal ma z tym problem i nie jest w stanie tego dostarczyć. A zatem cały zespół nie dostarcza, bo jeżeli jedna osoba nie dostarczy swojej części, to cały zespół nie dostarczył.

Wojtek: No tak, no i tutaj myślę, że znowu wracamy do tej zbiorczej odpowiedzialności, jeśli chodzi o Scrum. Czy uważasz wogóle, że takie daily mają sens?

Mateusz: To zależy jakie daily, bo jeżeli to są krótkie update'y, gdzie rzeczywiście zespół jest zaangażowany, to tak myślę, że tak. Natomiast w przypadku kiedy jest Scrum Master, który przychodzi i odpytuje po kolei każdą osobę, wyczytuje z listy każdą osobę, to myślę, że nie. Dlatego np. w projekcie, w którym jestem, podchodzimy do tematu troszeczkę z drugiej strony, czyli bierzemy zadanie po zadaniu, które jest do wykonania w ramach sprintu niezależnie od osoby. Nie jesteśmy sfocusowani na osoby, które wykonują te, które wykonują te zadania, tylko na zadaniu, które uaktualnie jest in progress.

Wojtek: Rozumiem. OK, to jest fajne podejście. U nas jest też w sumie podobnie. I ogólnie się z Tobą zgadzam, że daily to chyba jedno z najbardziej przydatnych narzędzi z mojej perspektywy przynajmniej, jeśli chodzi o te wszystkie ceremoniały. W szczególności jak jest dobrze realizowany może naprawdę dużo zmienić, jeśli chodzi o pracę i dużo usprawnić. Jeśli członkowie zespołu są aktywni, chcą pomagać i też słuchają tego, co mówią inni, to może dojść do takiej sytuacji, gdzie coś implementujesz, okazało się, że to już jest zaimplementowane. Powiesz o tym na daily, ktoś Cię poprawi i będzie rozumiał jasną informację w kontekście tego, że było już to zrobione i że nie musisz implementować tego drugi raz.

Mateusz: OK, jeśli chodzi o inne ceremoniały, to wydaje mi się, że warto wspomnieć o ceremonii, której ja osobiście nie lubię. A który wydaje się, że dosyć istotny, czyli retrospektywie. Lubisz swoje retro czy nie lubisz?

Wojtek: Tak, całkiem tak. Szczególnie w kontekście tego, jak one teraz wyglądają. Wyglądają moim zdaniem nieźle.

Mateusz: Powiedzmy czym jest retro w takim razie? Bo może nie wszyscy wiedzą.

Wojtek: Jedziesz Mateusz.

Mateusz: Tak naprawdę retro to jest podsumowanie naszej pracy z ostatniego okresu, czyli sprintu. Tutaj warto chyba powiedzieć, czym jest sprint. Praca w Scrumie najczęściej dzielona jest na okresy, w ramach których dostarczamy jakąś wartość dla klienta. Te okresy, różnie wyznaczane czy to w postaci tygodnia, dwóch tygodni, czy może dłuższych definiuje się właśnie jako sprinty. Natomiast po każdym takim sprincie robi się retro, czyli taką retrospektywę, czyli się cofamy do tego, co się wydarzyło przez ostatni sprint i próbujemy omówić wszystkie rzeczy, które poszły nam dobrze, które poszły nam gorzej i znaleźć jakieś usprawnienia, które można by poprawić. Nad czym mogliśmy popracować, żeby kolejne sprinty szły lepiej. Tak naprawdę z mojej perspektywy to jest bardzo trudne spotkanie.

Wojtek: Widzisz ja wiedziałem, że miałeś otwartą definicję po prostu.

Mateusz: Nie miałem.

Wojtek: Nie miałeś?

Mateusz: Nie.

Wojtek: Kurcze to niezły jesteś. Brzmiało jak definicja.

Mateusz: Czekaj, bo to pewnie przez chat GPT.

Wojtek: Teraz klasyk. Dobra, sorry, bo Ci przerwałem. Kontynuuj.

Mateusz: Mówiłem, że to Chat GPT mi dyktował, a ja tylko w słuchawce słyszałem i leciałem.

Wojtek: To już taką technologię masz.

Mateusz: No a co? Jak prawdziwy aktor.

Wojtek: Dobra, opowiadaj, czemu tego retro tak nie lubisz.

Mateusz: Nie, że nie lubię, tylko że uważam, że to bardzo trudne spotkanie. Nie lubię go z tej perspektywy, że jeśli miałbym powiedzieć, że go nie lubię, to mógłbym powiedzieć, że go nie lubię dlatego, że jest to spotkanie, które wymaga bardzo dużej otwartości. I trudno jest tą otwartość znaleźć w zespole, który jest początkujący, który się nie zna dobrze, jeżeli zespół długo ze sobą pracuje, jest dosyć dobrze, że tak powiem, zgrany, to ta otwartość wychodzi bardziej naturalnie. W zespołach, które są początkujące, ale nie w sensie stażu technologicznego, tylko początkujące w pracy ze sobą to retro jest trudne, jest bardzo trudne, wydaje mi się. Ja porównując retro w obecnym projekcie sprzed kiedyś i porównując je ze stanu obecnego widzę plusy tego, jak ważne, jak wartościowe jest to, że pracujemy ze sobą niezmiennie od dłuższego czasu, że poznaliśmy się, polubiliśmy się. Przez to jest nam łatwiej powiedzieć pewne rzeczy. Nawet wiesz, w Retro nie chodzi o to, żeby wytknąć komuś z imienia i nazwiska: słuchaj Wojtek, ale sp.....

Wojtek: Tak, to powinno być anonimowe z tego co pamiętam.

Mateusz: Tak, to powinno być anonimowe. Ale jak coś się wykrzaczy, to wiadomo kto to zrobił.

Wojtek: Wojtek.

Mateusz: Wojtek. Nikt nie musi powiedzieć, że to Ty. Tak, ale może być taka sytuacja. To jest bardzo trudne według mnie, żeby tak powiedzieć o problemie, o błędzie i tak go zaznaczyć, jeżeli rzeczywiście dotknął lub był problemem dla zespołu, żeby nie powiedzieć tego personalnie, tylko zaadresować to jako do całego zespołu, a jednocześnie w sytuacji, kiedy to ta jedna osoba wie, że jest winna, nie zranić jej jakoś, bo to też nie o to chodzi w retro, żeby się obrzucać błotem. Celem tego spotkania będzie wyciągnięcie wniosków na przyszłość.

Wojtek: Ale myślę, że kilka punktów tutaj dobrych podniosłeś Mateuszu. Zacznę od pytania, które chyba powinienem zadać na samym początku, ale zadam teraz. Czy Ty pracujesz w Scrumie? Takim czystym?

Mateusz: W czystym nie.

Wojtek: A w czym pracujecie?

Mateusz: Mówią, że Scrum, ale tak nie jest czysty scrum.

Wojtek: Ok, rozumiem. Spoko.

Mateusz: Nie mamy Scrum Mastera w zespole. Też jest trochę inaczej, bo mamy, że tak powiem, Engineering Managera, który w zasadzie, w moim odczuciu trochę pełni taką rolę Scrum Mastera, takiego gościa, który pilnuje ceremoniału i tego, jak to wszystko powinno przebiegać. Aczkolwiek wydaje mi się, że sama ta osoba też mówi oficjalnie, że ona nie jest i nie będzie Scrum Masterem ponieważ Scrum Master jest gdzieś indziej w firmie. W zasadzie to ja go nigdy nie widziałem, ale to, co jest jeszcze odmienne wydaje mi się od takiego klasycznego Scruma w tym projekcie, to jest też taki sztywny podział kompetencyjny, czyli frontend w zasadzie jest frontend, backend jest backend i nie mieszamy tych kompetencji. I też estymujemy w godzinach. Czyli tak naprawdę mamy mamy taki miks estymat: story pointy razy godziny i wychodzi nam jaka jest magiczna liczba, której nikt nie rozumie.

Wojtek: To z takim podejściem się jeszcze nie spotkałem. Spotkałem się z godzinami, spotkałem się ze Story Pointami, ale z mnożeniem godzin przez story pointy to słyszę pierwszy raz.

Mateusz: Akurat tu się trochę wygłupiam z mnożeniem, ale to jest wiesz...

Wojtek: Rozumiem. Jakiś magiczny algorytm.

Mateusz: Na podstawie story pointów wychodzi Ci jakaś magiczna liczba godzin, która niedokładnie jest mapowania. Powiedzmy nie znajdziesz zadań, które miały np. tą samą liczbę story pointów i tę samą liczbę godzin.

Wojtek: Rozumiem. To mega ciekawie. No dobra, wracając jeśli chodzi o moje opinie o retrospektywy, to zdecydowanie zgadzam się z Tobą, że dużą rolę odgrywa otwartość uczestników. Zastanawiam się na pewno to, o czym Ty mówiłeś Mateuszu, czyli to jak ludzie ze sobą długo pracują to pomaga. Myślę, że to też trochę zależy od tego, jaką osobą jesteś i czy dzielenie się takim feedbackiem jest dla Ciebie w miarę naturalne czy nie. To naturalne, że są osoby, które są bardziej lub mniej otwarte. Na pewno się z kimś takim spotkałeś. Dodatkowo jeszcze też ciekawiej jest jeśli chodzi o te retrospektywy, nie wiem jak u Ciebie, ale u nas jak pracowaliśmy jeszcze w takim w miarę klasycznym Scrumie powiedzmy, doszło do takiego momentu, że ten sprint mijał i tak naprawdę po tych dwóch tygodniach nie bardzo mieliśmy o czym ze sobą rozmawiać na retrospektywie, jak tych sprintów zrobiło się 50, to kurczę, jak lepiej można już zrobić ten proces i jak można to usprawniać. Tak więc te retrospektywy naprawdę szybko zrobiły się takie powtarzalne, nudne i stały takimi spotkaniami dla samych spotkań.

Mateusz: Ile razy można pisać, że fajnie się z Wami pracuje?

Wojtek: Klasyka. Dobra komunikacja to też klasyka.

Mateusz: Może i się trochę zgodzę, a trochę nie, bo to też ma taką funkcję budowania morali w zespole. Nie wiem czy zwróciłeś uwagę, że długo funkcjonujące zespoły mają taką, działają trochę na zasadzie takiej sinusoidy, czyli jest super, potem idzie trochę gorzej, zespół się trochę wypala, na retro wytykamy jakieś problemy, błędy, próbujemy znaleźć optymalizację, potem wchodzimy w fazę wzrostową, wszystko poprawiamy. Kilka sprintów jest fajnie. Potem znowu następuje jakieś wypalenie, trochę obniżenie standardów. Dochodzimy do retro, w którym znowu sobie wytykamy pewne rzeczy, wytykamy tak jak mówię to jest w cudzysłowie i znowu wchodzimy w tę fazę zwyżkową. W zasadzie to jest taka sinusoida. Więc gdybyśmy zaprzestali retro, to co się może wydarzyć? Zespół przestaje ze sobą rozmawiać. Zespół przestanie ze sobą rozmawiać, w ogóle przestanie mówić o problemach. A tak to zostawiamy sobie jakąś wolną, mam nadzieję bezpieczną przestrzeń, która pozwala nam powiedzieć o tym, czy coś jest tak w zasadzie w porządku. Czy w zasadzie coś warto by było zmienić? Bo to też chyba zależy od dojrzałości członków tego zespołu.

Wojtek: Zgadzam się z Tobą. Dlatego też doceniam to, jak to wygląda u nas teraz, że zrezygnowaliśmy z takiego podejścia: robimy to retro co dwa tygodnie zawsze. Zamiast tego staramy się robić to retro co jakiś czas, ale mimo wszystko je robić. Właśnie żeby było takie miejsce, które zdecydowanie się zgadzam, że jest ważne. I super jest mieć taką właśnie możliwość, która ma jeszcze jakiś konkretny format, do wyrażania swoich opinii. W szczególności tak jak mówisz Mateusz, kiedy ma się osobę w zespole, które potrafią dawać feedback, nawet negatywny, który może ciężej usłyszeć, bo taki jest najbardziej budujący. Tak?

Mateusz: No ok. Jak mówiliśmy o ceremoniałach, to wspomnieliśmy o retro, wspomnieliśmy o daily. Zostają nam planningi. Planningi i review, ale review za chwilę. Planning, czyli spotkanie, które bezpośrednio jest powiązane z tym, co mamy do wykonania. A w zasadzie łączy się z tym, że musimy zaplanować tę pracę na następne sprinty. I co ważne czy nieważne?

Wojtek: Z mojej perspektywy w projektach, w których ja pracowałem. Ogólnie to planowanie to ważna sprawa, ale jeśli wiążemy z tym właśnie trzymanie się tych dwutygodniowych interwałów i wszystkie te rzeczy, o których wspomnieliśmy i dotknęliśmy trochę, jeśli chodzi o estymację zadań, to tutaj zaczynają pojawiać się problemy.

Mateusz: Tak, tutaj też warto rozróżnić spotkania typu planning i spotkania typu refinement. W zasadzie można je wrzucić do jednego worka, ale ja bym ich tak bardzo nie unifikował, bo jedne służy do określenia oczekiwań klienta, a drugie do zaplanowania naszej pracy. I wydaje mi się, że planning z tej perspektywy, takiej czysto zespołowej jest przydatny, żeby powiedzieć sobie: hej panowie, co my w zasadzie chcemy? Panowie i Panie, przepraszam, zespole, co my w zasadzie chcemy dowieźć i jakie mamy w ogóle możliwości przerobowe? I w takim układzie najczęściej PO nie jest nam potrzebny. Chyba żeby nam miał dopowiedzieć jakie są priorytety. Ale przy dobrze zorganizowanym backlogu. Backlog, czyli dla tych, którzy nie mieli przyjemności pracować z backlogiem, to jest lista zadań, które są do wykonania w przyszłości.

Wojtek: Kiedyś tam...

Mateusz: Kiedyś tam, tak jest. Gdzieś tam na dnie backlogu są zadania, które pewnie pamiętają erę dinozaurów.

Wojtek: Są tam od zawsze, to są takie klasyki.

Mateusz: Są tam od zawsze, są klasykami. Przypuszczam, że przy dobrze zorganizowanym backlogu, PO na takim planningu być nie musi. Po prostu dostaje informację o tym, co zespół dostarczy na podstawie możliwości, ile to zajmie itd. Natomiast refinement znowóż - bez PO już sobie nie wyobrażam takiego spotkania.

Wojtek: Tak, myślę, że to nie ma sensu. Samo to, że to jest refinement mówi nam o tym, że chcemy dopracować te historyjki.

Mateusz: I tu jest bardzo ważna kwestia. Coś co też zauważyłem, że kuleje bardzo często przy spotkaniach typu refinement czy planning to aktywność zespołu. I to w większości projektów, w których byłem - aktywność w zasadzie członków spada na takich spotkaniach. Zazwyczaj jest to jedna osoba, która jest żywo zainteresowana wykonaniem tego zadania, która wie, że będzie to robiła, tak naprawdę - zadaje pytania, a reszta siedzi cicho.

Wojtek: No tak, to prawda.

Mateusz: I to jest wielki problem, bo nie o tym mówi scrum, prawda? Scrum zakłada, że cały zespół będzie dostarczał, że nie wiemy na początku, kto to będzie dostarczał, że cały zespół ma mieć wiedzę o tym, biznesową, przede wszystkim, co będzie do wykonania.

Wojtek: Kurczę, ten scrum jak tak sobie rozmawiamy - ja coraz bardziej sobie uświadamiam, że to jest mega ciężko po pierwsze zrobić dobrze, a po drugie w ogóle znaleźć takich ludzi, z którymi możesz to wszystko zrobić. Wyobrażasz sobie stworzyć taki zespół super zmotywowanych ludzi, masz mniej więcej ten sam poziom kompetencji? Przecież to jest mega skomplikowane, żeby coś takiego zrobić. Właśnie masz te różne temperamenty tych osób, które się udzielają się, nie udzielają. Kurczę.

Mateusz: Zależy od Scrum Mastera chyba wiesz. W jednym projekcie, gdzie pracowałem była Scrum Masterka, która jak gubiłeś, że tak powiem koncentrację to rzucała w Ciebie czymś. Jak byłeś nie skoncentrowany to mogłeś oberwać jakimś twardym przedmiotem w środek czaszki, więc mogło być bolesne. Kiedyś pamiętam, że dla naszego lidera, który lekko, że tak powiem zwiesił głowę i sobie coś tam notował, skończyło się to dosyć dużym guziakiem na środku czoła.

Wojtek: Czyli odpowiednie sposoby motywacji jednym słowem. Mówisz, że jest rozwiązanie.

Mateusz: To był bardzo odpowiedni sposób motywacji. Ja bym trochę to nawet wtedy pod ścianą pod mobbing, aczkolwiek uwagę zachowała. Natomiast tak, zgadzam się w stu procentach, że ogólnie Scrum nie jest łatwy i zależy bardzo dużo od ludzi, którzy do tego Scruma podchodzą i ich świadomości, że tak powiem, bo trudno jest zrobić z ludźmi, którzy tego nie czują. Na bootcampie, który realizuje też jest, że tak powiem, taki projekt a'la scrumowy. Gdzie mamy rzeczywiście jakieś daily, sobie uczestnicy tego projektu, wykonują daily, mają spotkanie typu planning, mają na końcu review, retro, tylko nie robimy - zazwyczaj ja krótko podsumuję, bo nie ma za bardzo czasu najczęściej co i jak. Natomiast te wszystkie ceremoniały się odbywają i wśród nich największym problemem jest to, że przez pierwsze półtora tygodnia z 3 tygodniowego projektu prawie w ogóle ze sobą nie pracują. Co powoduje, że ten projekt bardzo spowalnia, zatrzymuje się, pojawia się bardzo dużo konfliktów, ludzie wchodzą sobie w kompetencje, ktoś wziął zadanie, ktoś inny je wykonał. To jest po prostu klasyka gatunku.

Wojtek: No tak, to prawda.

Mateusz: Tak. I dopiero po pewnym czasie, kiedy uświadamiam ich, jak bardzo istotne jest to, żeby zaczęli ze sobą komunikować, po co piszą, to daily, po co jest code review w projektach do Pull Requestów, zaczynają kumać, zaczynają dobrze działać. Na tyle dobrze, że są w stanie dostarczyć ten projekt chociażby w zarysie. Aczkolwiek, powiedzmy dostarczyć, to jest dużo powiedziane. Chodzi przede wszystkim o to, że nauczenie ludzi komunikacji jest mega trudne. I teraz, jeżeli my pracujemy w IT już kilka, kilkanaście może lat, to my wiemy już, co nas czeka. Wiemy, mamy bardzo dużą, że tak powiem, szerokie rozpoznanie domen biznesowych i często jest tak, że może ułatwia nam to w jakiś sposób pracę. Niezmiennie jednak jest tak, że nawet w zespołach seniorskich te problemy komunikacyjne występują. I ta uwaga jest trudna do utrzymania i według mnie trudno jest zrobić czystego Scruma w takiej idealnej formie, jak został on opisany.

Wojtek: No myślę, że tak. Poza tym też domyślam się, że mega ciężko jest utrzymywać tą motywację na wysokim poziomie, co jest wymagane tak jak teraz tutaj sobie rozmawiamy. Jeszcze raz przechodzimy przez te najważniejsze rzeczy, które są ze scrumem związane - to utrzymanie tej motywacji na wysokim poziomie. Przecież to nie jest Twój produkt, bo zazwyczaj są to jakieś odległe problemy biznesowe, które nie do końca Ciebie dotyczą. Bądź teraz zmotywowanym przez cały rok powiedzmy, tak, żeby robić to na najwyższym poziomie. Zdecydowanie nie jest to proste.

Mateusz: Pytanie co Cię motywuje?

Wojtek: No, to prawda.

Mateusz: To jest właściwie kolejny trudny temat. Po to jest ta rola chyba Scrum Mastera. Rola Mastera jest po to, żeby utrzymywał Scruma na odpowiednim poziomie, tak żebyśmy trzymali się zasad, których Scrum nam dostarcza, narzuca, żebyśmy byli Agile, żebyśmy byli elastyczni i byli w stanie dostarczać. Z drugiej strony, jak napotykasz na człowieka, który nie jest zmotywowany, to ten człowiek będzie tylko i wyłącznie kulą u nogi. I tak naprawdę dojdziesz do takiego momentu, w którym wiesz, że nie będziesz mógł na tę osobę liczyć, a zatem twoje zaufanie do tej osoby spadnie. W zasadzie może sięto skończyć posypianiem projektu. Albo przynajmniej sprintu jednego czy dwóch. Kto powinien być odpowiedzialny za utrzymanie tej motywacji? W projektach, w których ja do tej pory pracowałem, była to albo rola Scrum Mastera, jako dodatkowa funkcja, którą on pełnił, albo rola lidera technicznego, czy też lidera w zespole, który był osobą, która jako członek zespołu miał odpowiednio dużo kompetencji miękkich, najczęściej albo ich nie miał wtedy było gorzej, żeby ten zespół ze sobą spiąć i umiejętnie pokierować rozmowę w taki sposób, żeby ci ludzie chcieli ze sobą rozmawiać, żeby wiedzieli o swoich problemach, ale też jednocześnie byli w stanie trochę empatycznie do siebie podejść. I to jest trudne. To jest ten case, o którym ty mówisz.

Wojtek: No tak, domyślam się, że motywacja ludzi to chyba jeden z najcięższych tematów, jeśli chodzi o IT. W ogóle to tak im dłużej pracuję jako software developer, tym bardziej dociera do mnie, że technologia jest łatwa, Tego wszystkiego można się nauczyć. To wszystko można zaprogramować, zrobić wcześniej czy później, ale właśnie jeśli chodzi o pracę z ludźmi i komunikacja z ludźmi to jest prawdziwe wyzwanie.

Mateusz: I mam dokładnie takie same odczucia, że w zasadzie technologicznie to jest wszystko do ogarnięcia. Najtrudniejsze w tym wszystkim jest to, że nasza praca, pomimo tego, że stosunkowo łatwa, już po pewnym czasie jest dość złożona, bo wymaga bardzo wielu czynników, które trzeba ze sobą połączyć, a te czynniki są uzależnione od ludzi najczęściej. I teraz zgrać tych 50, stu ludzi w jednym projekcie to już jest...

Wojtek: To już jest sztuka.

Mateusz: Sztuka. Nawet kiedyś chciałem napisać artykuł: Programowanie, rzemiosło czy sztuka? I tutaj rzeczywiście to byłby argument a'propo, że to jest bardziej sztuka już niż rzemiosło.

Wojtek: Tak, tak zgadzam się z Tobą, ale to na każdym etapie też to...

Mateusz: Inaczej trochę wygląda.

Wojtek: Tak. Też to pytanie widać czy to jest sztuka, czy rzemiosło, prawda? No tak, ale właśnie te rzeczy związane z tym planingiem.

Mateusz: Mamy jeszcze jeden ceremoniał, czyli review, demo. Moje ulubione. Robicie review?

Wojtek: No to opowiadaj. Review oczywiście, że robimy.

Mateusz: Wewnętrznie czy przed klientem?

Wojtek: Wewnętrznie robimy, to znaczy my mamy PO, więc to wiesz, jest wewnętrznie, tak na dobrą sprawę. U nas to nie wygląda tak klasycznie. To znaczy zależy, gdzie rysujesz linię jeśli chodzi o klienta.Ty pracujesz dla firmy, której klienci powinni być twoimi klientami, czy to w tej firmie, dla której pracujesz, traktujesz jako klientów.

Mateusz: W zasadzie z stakeholderzy czy też zarząd, czy też Product Ownerzy czy zwał jak zwał są w moim przypadku są moimi klientami, bo de facto jest to własny produkt.

Wojtek: Dobra, ale oni muszą go komuś sprzedać, tak?

Mateusz: Oni go sprzedają. I tam jest rzeczywiście robione dla nich review. Mają robione dema itd. Klienci mają swoje opinie i na tej podstawie zbierane są kolejne wymagania, usprawnienia systemu. Więc tam jakiś system jest, aczkolwiek my nie lubimy w ogóle review. U nas nie ma review, natomiast było robione w poprzednich projektach i to w zasadzie jest taki ceremoniał, który jak się pierwszy raz z nim spotkałem, był dla mnie bardzo stresujący.

Wojtek: No tak, dla mnie też. Robiliśmy wcześniej jeszcze jak pracowaliśmy nad czymś takim, co zdecydowanie bardziej przypominało Scrum. Teraz już nie robimy i też pamiętam, że dość mocno się stresowałem.

Mateusz: Tak, w tamtym projekcie, który mam na myśli. To była taka taka sztuka, że tak powiem, że każdy prezentował swoją pracę. Nie było jednej osoby, która była wybierana przez zespół, która przygotowała prezentację i prezentowała to za wszystkich, za swój zespół. Każdy podchodził do komputerka i pokazywał obszar, za który był odpowiedzialny.

Wojtek: Gdzie tu teraz można kliknąć i co nowego się pokazuje?

Mateusz: Tak, dokładnie. Ewentualnie jak to działa w interakcji z API czy jakąś integrację jak się zrobiło, ale to było bardzo stresujące i to było bardzo podniosłe wydarzenie, raz na 2 tygodnie, gdzie cały zespół, cała firma w zasadzie, schodziła się do jednej wielkiej sali i trwało to pół dnia, bo każdy zespół zanim zaprezentował itd. Na końcu prezes mówił: zaakceptuję sprint lub nie akceptuję sprintu.

Wojtek: Kiedyś nie zaakceptował?

Mateusz: Tak, wiele razy. Bardzo często nie akceptował sprintów, mogę powiedzieć. On był bardzo wymagający, bardzo wymagający. Trzeba to podkreślić. Zespół bardzo często pracował po godzinach i można powiedzieć, że to była trochę patologia scruma w pewnym momencie, bo tak naprawdę oszacowanie, że tak powiem, możliwości zespołu versus to, co byliśmy w stanie dostarczyć. Realnie była totalna rozbieżność pomiędzy tymi dwoma aspektami. Było w zasadzie niemożliwe. Projekt ostatecznie upadł po kilku latach. To był produkt własny w ogóle, więc też trochę inaczej. Natomiast fakt faktem, prezes dość często nie akceptował tego. Tego nie akceptuje, bo coś tam, bo to było w tym i też trochę narzucał, co ma być wykonane w ramach danego sprintu. Natomiast było to bardzo stresujące.

Wojtek: Domyślam się. Jak masz takiego Cezara jak w starożytnym Rzymie, który pokazuje kciuk w górę albo kciuk w dół.

Mateusz: To była w ogóle patologiczna firma. Nie chcę już czytać nazwami, bo to nie o to chodzi. Ale po latach ludzie się sądzą z tą firmą: o wynagrodzenia, o wszystko.

Wojtek: Nie brzmi to dobrze.

Mateusz: Fakt faktem, tam było takie review bardzo konkretne, długo trwające z zarządem z przodu, który odbierał, że tak powiem, ten produkt.

Wojtek: Chciałbym zmienić swoją odpowiedź. Przepraszam, że Ci przerwę. Moje review jednak nie było stresujące, wszystko było ok. Totalnie bezproblemowe się okazuje jednak.

Mateusz: To się cieszę. Cieszę się, że zmieniłem Twoje zdanie.

Wojtek: Przekonałeś mnie zdecydowanie Mateuszu.

Mateusz: Ale też miałem bardzo przyjemne doświadczenia z review. W niektórych projektach, gdzie rzeczywiście to wyglądało całkiem w porządku i do dzisiaj nie wiem, jakie są konsekwencje niedostarczenia sprintu, bo w zasadzie nigdy się z żadnymi konsekwencjami tego nie spotkałem.

Wojtek: Czy uważasz, że to jest sensowne takie review?

Mateusz: Z perspektywy klienta pewnie ma to wartość. Tak, pewnie ma to wartość, bo klient chce zobaczyć co zrobiliśmy, za co płaci. Więc z tej perspektywy to jest mega istotne. Natomiast z perspektywy zespołu to jest w ogóle nieistotne i nieadekwatne. W firmie, w której jestem to jest trochę też inaczej rozwiązane, ale klasycznie jest tak: sprint trwa dwa tygodnie i w ostatni dzień masz review. Więc estymujesz pracę na dwa tygodnie, ale tak naprawdę realnie jesteś w stanie trwać półtora tygodnia.

Wojtek: Jak jeszcze doliczyć te wszystkie ceremoniały, to ja nie wiem czy tam.

Mateusz: Właśnie, jesteś realnie w stanie przepracować może tydzień, może półtora. I musisz robić review tego, co zrobiłeś, więc nie możesz pracować w drugim tygodniu, musisz się przygotować do review: ustabilizować środowiska, zmergować wszystko, jeszcze podsumować itd. W przypadku małych zespołów takie review nie ma sensu. W przypadku dużych zespołów też nie ma sensu, bo sama faza stabilizacji często jest bardzo długa.

Wojtek: No tak.

Mateusz: Widziałeś kiedyś review, na którym wszystko działa? Wszystko poszło tak, jak powinno być?

Wojtek: No nie. Masz rację. Chociaż w sumie. Ale to jest zależne od szczegółów jak to wygląda?

Mateusz: Według mnie jak review powinno być dwa tygodnie po sprincie. Ewentualnie tak jak to jest w tym projekcie, w którym jestem jest to rozwiązane. Można zrobić jakiś Code Freeze po prostu i ustabilizować sobie środowisko i wtedy prezentujesz tylko małą część tego, co było do dostarczenia.

Wojtek: Stary u nas to się działy takie rzeczy, że np. wiesz na swoim komputerze, jakieś środowisko u siebie lokalnie pokazywałeś na komputerze i tyle.

Mateusz: Tu jest rygor. Tu nie ma możliwości takiej, żeby pokazać ze swojego środowiska lokalnego. I ja też jestem za tym, żeby nie robić tego jednak. U mnie działa - tak jak ktoś ostatnio powiedział: no dobra, u Ciebie działa, ale co? Będziemy kopiować Twój komputer i wszystkim wysyłać wszystkim klientom. To nie tędy droga. Więc u mnie działa - to jest słaby argument.

Wojtek: Zdecydowanie, bardziej chodzi o podniesienie morale w zespole, pokazanie czegoś fajnego i to też w sumie jest dobrym seguem do następnego punktu dyskusji. Drobnego, bardziej może nie punktu do dyskusji, ale pytania. Jestem bardzo ciekawy, Mateuszu, jak często dowoziecie a jak często nie dowozicie sprintów?

Mateusz: A to chyba w naszym przypadku teraz to jest fifty fifty. U nas akurat robimy sobie wewnętrzne, przy każdej retrospektywie, takie team assessment'y. Powiedzmy, gdzie odpowiadamy sobie na pytania o tym, jak się czujemy w zespole? Tak anonimowo zbieramy statystyki i porównujemy sobie to z poprzednim sprintem. Ja np. dość dużą analogię widzę pomiędzy tym, jak zespół się czuje, kiedy dowozimy, kiedy nie dowozimy i jak to bardzo ładnie widać tę zależność pomiędzy właśnie poczuciem bezpieczeństwa chociażby a takimi rzeczami jak work and life balans, który gdzieś tam jest, powiedzmy górnolotnym stwierdzeniem i hasłem, ale kiedy np. zespół dość nisko ocenia work life balance, kiedy dość nisko ocenia tę sekcję, to wtedy ewidentnie widać, że najczęściej tych sprintów nie dowoziliśmy.

Wojtek: To mega fajnie, że macie coś takiego, i że możecie właśnie takie, data driven, decyzje podejmować.

Mateusz: Ja bardzo lubię statystykę Confidence, która mówi nam o tym jak się czujesz pewnie w zespole, czy czujesz pewność, że zespół dowiezie czy nie dowiezie. I to jest bezpośrednio powiązane np. z rzeczami, które mają impakt na nas, czyli przychodzą dane z zewnątrz od PO, zmieniane są wymagania czy ile jest wrzutek w czasie sprintu do wykonania, jak dużo bugów się pojawia, jak wygląda realizacja kontraktów pomiędzy frontendem a backendem? Wtedy ten wskaźnik Confidence się zmienia i widać ewidentnie, że sprinty które były nie dowiezione, ten Confidence miały niski poziom, a te które były dowożone bardzo często tym Confidence był dużo wyższy. Ludzie to w jakiś sposób emocjonalnie traktują troszeczkę, jesteśmy wszak tylko ludźmi.

Wojtek: Tak, to prawda, ale tutaj wspomniałeś o jednej z takich najczęściej spotykanych patologii. Skoro już używam takiego słowa, które jest dość mocne, ale powiedzmy, że już trzymajmy tego słownictwa, czyli wrzutki podczas sprintu, bo to jest chyba właśnie jedna z takich pierwszych z brzegu, które przychodzą mi do głowy, rzeczy, które są wbrew właśnie tej metodologii scrumowej. Przecież tam powinno być tak ze dwa tygodnie, jest zabite dechami, mówiąc kolokwialnie.

Mateusz: Ale widziałeś kiedyś dwutygodniowy zabity dechami sprint?

Wojtek: No nie widziałem.

Mateusz: Zdarzyło Ci się chociaż raz mieć sprint, gdzie nie było chociaż jednej małej wrzutki?

Wojtek: Magiczne zwierzęta i jak je znaleźć.

Mateusz: Nie ma chyba takich sprintów i to wynika trochę z podejścia biznesowego. Jeżeli jesteśmy zwinni, to argumentem tego, kto wrzuca jest: Ej, ale wy jesteście zwinni. Jesteście zwinni, to wyrzućcie coś, wrzućcie coś. Tylko, że to często rozwala naszą pracę i często doprowadza do głupiego niezrozumienia tego, na czym polega w zasadzie to, czym się zajmujemy. W moim odczuciu to jest bardzo złe i to powinno być tak, że 2 tygodnie zabite dechami, chcesz mieć wrzutkę to wrzucimy jako priorytet na początek następnego sprintu. Ewentualnie jeżeli wykonamy swoją bieżącą robotę, to wtedy po prostu wrzućmy to. Ale fakt faktem często jest tak, że przychodzi PO i mówi: Ej! Ale to jest to ma wyższy priorytet. Ja to muszę mieć na już. Więc w zasadzie wyrzućmy coś ze sprintu, wrzućmy coś innego. Zróbmy taki swap.

Wojtek: U Was i tak są mili, że chcą coś wyrzucić - przynajmniej w nagrodę.

Mateusz: Nie w nagrodę. Po prostu nasz menadżer, że tak powiem, bardzo mocno pilnuje tych zasad. Jeżeli zgadzamy się na wrzutkę to ewidentnie widać po burndown chart, że coś zostało wrzucone, a nie zostało nic usunięte. Wtedy jest dość ostra nagonka ze strony ze strony managera na PO, więc on już ma na sobie taki trochę nóż na gardle, że jeżeli nie chce mieć dyskusji z kimś tam od góry to musi pilnować tego, żeby ten chart ładnie wyglądał.

Wojtek: Rozumiem. To ja już trochę nie mogę powiedzieć jak to wygląda u mnie, bo już na szczęście nie pracujemy w Scrumie takim czystym, z dwutygodniowymi sprintami, więc to inaczej wygląda. Ale też chciałem się jeszcze podpytać Mateuszu, jak to wygląda jeśli chodzi o zadania, które są długie, które są skomplikowane, ciężko je wyestymować i które z perspektywy mogą zająć więcej niż dwa tygodnie. Co się wtedy dzieje? Jak to wygląda z Twojego doświadczenia?

Mateusz: To jest kosmos ogólnie. To jest kosmos. Inaczej tego nie idzie nazwać. Warto by było zwrócić uwagę na to, czym jest zadanie w rozumieniu Scruma i w ogóle z wyzwaniem Sprintu. Jeżeli na to spojrzymy, to w zasadzie wszystko, co bierzemy do Sprintu, powinno mieć jakąś wartość dla klienta. A zatem, jeżeli my bierzemy jakieś, wykonujemy jakieś zadanie, to to zadanie powinno przynieść jakąś wartość dla produktu ze strony biznesowej, przynajmniej w idealnym świecie. Z drugiej strony pojawiają się koncepcje w stylu dług technologiczny, który trzeba spłacać i którego Scrum jednak nie lubi i zespoły scrumowe nie lubią, bo jak wytłumaczyć przyrost biznesowy spłacając dług technologiczny, spłacenie długu technologicznego jakimś przyrostem biznesowym? A z innej strony pojawiają się rzeczy typu właśnie zadania na investigation, na rozpoznanie tematu? To też nie jest żadna wartość biznesowa. Jakby nie patrzeć tak w ogólnym rozumieniu, bo gdybyśmy się wpali głębiej, to może byśmy gdzieś tam jakąś wartość znaleźli. Co do zasady to nie jest żadna wartość dla klienta, że my wykonujemy investigation, że badamy temat i teraz może się okazać, że my nie znamy tematu w ogóle i temat jest na tyle obszerny, złożony, że i frontend i backend zajmą nam dłużej niż długość całego sprintu. W takich sytuacjach, akurat u mnie w projekcie co jest uważam, że złe i w większości przypadków się nie sprawdza, jest rozdzielenie merytoryczne, czyli po prostu bierzemy tylko frontend, tylko backend i dzielimy sobie to na dwie storyjki. Często razem nie wejdą do sprintu, tylko backend weźmie swoją frontend weźmie swoją do następnego sprintu. Ale to też jest złamanie tej zasady, o której wspomniałem wcześniej, czyli nadal bierzemy coś do sprintu, co nie przynosi wartości biznesowej, bo sam backend nie daje żadnej wartości biznesowej i sam frontend też nie. I tu się pojawia kolejny problem. Jak to w takim razie podzielić? Czy jesteśmy w stanie to w ogóle dzielić? No i u nas się to dzieli, na bardzo małe fragmenty, nawet jeśli samodzielnie nie są w stanie dostarczyć wartości biznesowej. Staramy się mniej więcej w tym samym czasie wrzucać w frontend i backend do tego samego sprintu, ale chowamy to za feature toggle'ami. Tak, aby klient nie był w stanie tego zobaczyć do momentu, kiedy nie zbierzemy całej funkcjonalności, której dostarczenie może zająć kilka sprintów.

Wojtek: No właśnie myślę, że to też jest duży minus Scruma. Z mojego doświadczenia, jeśli chodzi o pracę w nim, bo właśnie wbrew pozorom jak pracuje z rzeczami, których nigdy wcześniej nie robiłeś, to zdarzają się takie momenty, że właśnie są jakieś inwestygacje, o których wspominałeś, Mateuszu, chociażby i same to zadanie może prowadzić do stworzenia następnych zadań. Tak, są też jakieś ślepe zaułki, w które wchodzimy, testujemy jakieś biblioteki, testujemy jakieś rozwiązania. Okazuje się, że to jest zupełnie nie ta droga, którą chcemy podążać. Coś się okazało zbyt skomplikowane itd. A to jest właśnie łamaniem podstawowych założeń tego Scruma.

Mateusz: Dokładnie. No dobra, a powiedz mi, skoro nie pracujecie w Scrumie, czyli co się stało? Przestał mieć dla was sens?

Wojtek: Tak, dokładnie tak. Przestał mieć sens. To jest świetny sequej Mateuszu do właśnie odmian tego, co można zrobić zamiast tego Scruma. My pracujemy w Scrumban'ie, który świetnie się sprawdza. Była to ewolucja, jeśli chodzi o Scruma, w którym pracowaliśmy wcześniej. Gdzie właśnie te sprinty dwutygodniowe były dla nas dość sporym problemem i zaczęły się robić totalnie wymyślone i timeline'y dwutygodniowe nie istniały tak na dobrą sprawę, więc stwierdziliśmy, że zdecydowanie lepiej podzielić zakres na funkcjonalności, zostawić te części ceremoniałów, które nam się podobają, które uważamy, że przynoszą wartość, chociaż w też zmienionej formie, tak jak wspominałem i pracujemy teraz w taki sposób, że właśnie w momencie kiedy taka funkcjonalność jest dowieziona, jakieś story jest skończone, wtedy je prezentujemy i możemy się cieszyć, że zostało zrobione, podbić wszystkim morale, to o czym wspominaliśmy i też jesteśmy zdecydowanie bardziej responsywni, bo nie jesteśmy zamknięci w tych tygodniowych interwałach. Dema możemy mieć pierwsze co 3 tygodnie, co 2 tygodnie co tydzień itd. Nieważne kiedy, ważne kiedy jest skończona funkcjonalność i osoba, która się nią zajmowała prezentuje tę funkcjonalność.

Mateusz: Ok, czyli to jest taka mieszanka kanban ze Scrum - z naciskiem, że ze Scruma bierzemy ceremoniały, z Kanban bierzemy narzędzia.

Wojtek: Tak. O ile się nie mylę, w kanbanie nie ma daily, w scrumbanie jest. Podobało nam się to daily i widzimy zdecydowanie wartość dodaną, jeśli chodzi o nasz projekt, więc korzystamy właśnie z tych ceremoniałów i wpisuje się to najlepiej właśnie w tą metodologię Scrumbanową.

Mateusz: Macie prawdziwą tablicę?

Wojtek: Czy my mamy prawdziwą tablicę? Znaczy nieprawdziwą. To znaczy nie wiem do końca, co rozumiesz przez prawdziwą tablicę czy taką wiszącą, wiesz?

Mateusz: Opowiem ci historię. W jednym projekcie mieliśmy fana, zresztą też mojego imiennika, fana agileowego zarządzania projektami. No i chciał wykorzystać właśnie Kanban, więc wziął, pogadał z szefem i zainwestował w taką tablicę, która zajmowała całą ścianę w pokoju jednym. Taką normalną tablicę szkolną, taką na mazaki. I codziennie rano przychodził. Robił tam przy tej tablicy, dzielił ją na kolumny - odpowiednio to do, in progress, done itd. I przyklejał karteczki. Takie kolorowe karteczki. Każdy feature miał swój kolor karteczek. Idea była taka, ponieważ to tablica jest taka wielka i była idealnie pomiędzy całym zespołem, chodziło o to, żeby każdy członek zespołu po wykonaniu zadania podchodził do tablicy, brał karteczkę, przyczepiał na nowe miejsce...

Wojtek: Ceremonialnie.

Mateusz: Ceremonialnie, tak, żeby każdy członek zespołu widział. Bo jak twierdził nasz PM, było to bardzo motywujące dla zespołu, bo wtedy ten zespół widział. O kurde, a Zenek to już wykonał trzy zadania. Ja się jeszcze z tym swoim jednym małym męczę, kołysze, że tak powiem, bujam i ponoć on mówi, że w kanbanie tak to powinno działać. Nie jestem specjalistą od kanbana. W Kanbanie pracowałem tylko w tym jednym projekcie plus mieliśmy wykorzystanie tablicy kanbanowej już przy jakiś tam mniejszych rzeczach, ale to już chyba nie był czysty kanban, więc tak naprawdę gdzieś tam z tego co pamiętam opowiadał to dość dużą wartość w kanbanie ma to w jaki sposób podchodzimy do prezentacji tego, że coś zostało zrobione, że samo to motywuje zespół do cięższej i bardziej wytrwałej pracy. Co by się w zasadzie zgadzało z tym, skąd Kanban się wywodzi. Wywodzi się tak naprawdę od Toyoty, czyli z firmy japońskiej, gdzie jak wiemy kult pracy jest na dość wysokim poziomie.

Wojtek: Zdecydowanie. W Japonii. No to chyba nie ma na wyższym.

Mateusz: Chyba nie ma na całym świecie wyższego poziomu kultu, że tak powiem, do pracy niż jest w Japonii.

Wojtek: TOP3. Możemy na spokojnie powiedzieć.

Mateusz: Tak, zdecydowanie tak. Więc dlatego też zapytałem czy macie rzeczywistą tablicę chociaż w czasach po-pandemicznych, że tak powiem, ciężko chyba mieć takie miejsce, gdzie taka tablica mogłaby wisieć.

Wojtek: No tak, poza tym też zaczynają się problemy pojawiać, kiedy to są teamy, które nie znajdują się w jednym miejscu, a gdzieś w wielu miejscach na świecie. Poza tym domyślam się, że z mojej perspektywy fajna sprawa mieć coś takiego fizycznego i domyślam się, że to może dawać taki dodatkowy boost motywacyjnym powiedzmy, ale domyślam się, że może być to dość niepraktyczne. Wiesz takie narzędzia pozwalają wpisać naprawdę dużą ilość informacji plus zarządzanie jakimiś release'ami i tego typu rzeczami, więc trochę nie wyobrażam sobie jakby to miały działać, korzystając tylko i wyłącznie z takiej białej tablicy.

Mateusz: I karteczek.

Wojtek: Tak i karteczek. Ale jeśli ktoś lubi takie podejście analogiczne, to proszę.

Mateusz: Z tego co wymagań to są lata 70 czy 80, więc zakładam, że raczej Jiry nikt wtedy nie miał.

Wojtek: Tak, domyślam się że tak. Więcej kartek mieli na pewno.

Mateusz: No tak, drzew więcej było na świecie, to prawda.

Wojtek: Też nie wiedzieli o konsekwencjach ścinania takiej ilości, więc proszę bardzo.

Mateusz: Trochę tych Toyota samochodów wyprodukowała przez ten czas. Zresztą Japonia to chyba też jest kolebka papieru.

Wojtek: Wszystko się zgadza. Wszystko układa się w jedną całość.

Mateusz: Dokładnie tak. Wojtku, fajnie jakbyśmy sobie wspomnieli troszeczkę o dwóch aspektach myślę, czyli User Story, o którym już wspominaliśmy, czyli tak naprawdę tym, co jest narzędziem, bo można tak powiedzieć, że User Story to jest narzędzie do komunikacji, do prezentacji tego, co należy wykonać przez zespół od strony biznesowej. Czyli tak naprawdę User Story opisuje świat programiście, można powiedzieć, np. mamy jest User Story, które mówi, że jako użytkownik chciałbym się zalogować do Twojego systemu.

Wojtek: No właśnie, i czy taka historyjka, którą przedstawiłeś i ona brzmi pięknie, prawda? Jako użytkownik chciałbym zalogować się do systemu, do platformy. Ale kurczę masz takie zadanie? No i właśnie, żeby coś takiego się zadziało, to 1000 rzeczy musi się zadziać po drodze.

Mateusz: Z perspektywy klienta nie ma żadnego znaczenia.Wojtek Ja to rozumiem.

Mateusz: Z perspektywy naszej technicznej to tam jest roboty a roboty.

Wojtek: Dla mnie to tytuł sprintu może być.

Mateusz: Nie jednego nawet. Natomiast też warto wziąć pod uwagę to, że tak naprawdę po to są refinementy. Żeby zespół powiedział: Ej, PO kochany, ale my tego nie dostarczymy, bo to jest za szerokie. Rozbijmy to na mniejsze storyjki. To jest jedna rzecz. 2. PO wcale nie musi rozumieć tego ze strony technicznej. To zespół musi powiedzieć, co technicznie należy z tym zrobić. Co więcej, to zespół jest w stanie po zrozumieniu perspektywy klienta stworzyć kilka tych właśnie user stories po to, żeby odpowiednio opisać to, co należy wykonać.

Wojtek: Ale czy w takim kontekście jest sens nazywać to jeszcze user stories?

Mateusz: Pytanie co to będzie zawierało? To ma zawierać perspektywę klienta, ale jeżeli np. doprecyzujemy, że będzie logował się za pośrednictwem jakiegoś providera, dostawcy, to mamy to już bardziej doprecyzowane.

Wojtek: Ok, tylko że dochodzimy do takiego momentu, że co: As a User I want to database to be setup. Na zasadzie, że chciałbym żeby baza danych była działająca.

Mateusz: Tutaj zmienimy teraz osobę, która pełni tę rolę AS A. Czyli tak naprawdę już nie będzie AS A user, tylko będzie AS A developer, o ile może być ona personą w projekcie.

Wojtek: No właśnie, ale tutaj zaczyna się robić moim zdaniem jeszcze trochę problemów.

Mateusz: Robi się trochę chaos, to prawda, ponieważ jakby nie patrzeć stworzenie takiej bazy danych z perspektywy biznesu nie ma żadnej wartości. PO w zasadzie ma w nosie to, czy tą bazę zasetupujesz czy nie ma po prostu działać logowanie. Z tej perspektywy po to się dopisuje wymagania (acceptance criteria) do takiego User Story, które opisują po kolei co powinno być zrobione. I tutaj już się używa różnych technik: given, when, then itd. Nie wiem czy się z tym spotkałeś?

Wojtek: Tak, miałem okazję. Co prawda właśnie niedużo, też z perspektywy projektu, w którym aktualnie pracuję, mam wrażenie, że te historyjki użytkownika, które jeszcze czasami się oczywiście zdarzają, ale one w większości przypadków po prostu nie mają sensu, bo trzeba je zrobić tak małe, że przestaje...

Mateusz: Mieć to sens.

Wojtek: Tak, mieć to sens, żeby to opakować w te ramy, bo to tworzy jakiś tam niepotrzebny chaos powiedzmy. A nie zapewnia żadnej wartości, jeśli chodzi o komunikowanie tego, co tak naprawdę powinno się dziać. Myślę, że taki user stories, to jest fajne jako epika, albo jeśli masz coś mega prostego do zrobienia. Jeśli masz wyświetlić coś a'la, użytkownik ma zobaczyć formularz to spoko.

Mateusz: User Story jest tym najmniejszym narzędziem. Poniżej US masz jeszcze taski, tylko już techniczne. Tak naprawdę już w większości projektów do tego z czego składa się z User Story tak naprawdę PO już nie ingeruje, bo taski tworzy sobie deweloper czy zespół deweloperski. Natomiast User Story to jest jakaś mniejsza jednostka. Z kilku User Story zbudowany jest np. Epic, ewentualnie Feature - zwał jak zwał. W każdym razie można się spotkać z tym nazewnictwem albo z tym nazewnictwem. I teraz, traktując epic czy też feature jako tę główną funkcjonalność, to US w zasadzie mogą być już bardziej rozbite. Ale fakt faktem zgadzam się. To narzędzie jest fajne z jednej perspektywy, językiem naturalnym pozwala nam opisać wymagania klienta. A to jest trudne, bo język naturalny jest dość pojemny. Język, którym posługujemy się na co dzień. Dzięki niemu możemy wyrazić praktycznie wszystko i tu nie mówimy tylko i wyłącznie o języku jako języku, ale i na język naturalny składają się też inne aspekty, chociażby nasza mimika twarzy czy gestykulacja. Całościowo, za pomocą swojej osoby jesteśmy przekazać bardzo dużo. Językiem maksymalnie zbliżonym do języka naturalnego chcemy opisać w sposób ustandaryzowany to, co należy wykonać. Tak, żeby każda osoba, zarówno ta techniczna, jak i ta biznesowa była w stanie to zrozumieć w ten sam sposób. Więc z tej perspektywy User Story ma dużą wartość.

Wojtek: Zgadzam się z Tobą, że fajnie jest mieć taki framework. Zdecydowanie jak się to powie, powiedzmy, jeśli już mamy ten przykład: jako użytkownik mogę zalogować się do platformy. Brzmi to super? Ja jako developer wiem od razu co się powinno zajrzeć.

Mateusz: Pod warunkiem, że są Acceptance Criteria dopisane w odpowiedni sposób.

Wojtek: Zaczyna się trochę tych ale robić nagle.

Mateusz: Zaczyna się pojawiać dużo rzeczy, które należy doprecyzować. Co to znaczy, że coś zostało zrobione? Np. Czyli Definition of Done. Albo co to znaczy, że w ogóle ta storyjka jest gotowa do pracy? Czyli Definition of Ready. Kolejne narzędzia nam wchodzą i zrozumienie tego, co jest czym i do czego służy i dobre tego wykorzystanie - może być problematyczne czy też trudne. OK. Oprócz User Stories mamy jeszcze role, bo ról też mamy kilka w takim projekcie z scrumowym.

Wojtek: Za każdym razem mam wrażenie, że to wyglądało inaczej. Może opowiadaj jak to jest u Ciebie Mateuszu...

Mateusz: Tak jak Ci mówiłem, nie mamy Scrum Mastera, ale w poprzednich projektach zazwyczaj ten Scrum Master był. Scrum Master to jest osoba, która co do zasady powinna opiekować się tym Scrum Manifesto, procesami itd. Więc to jest osoba, która w idealnym świecie nie jest potrzebna. W idealnym świecie ta osoba stoi z boku i obserwuje.

Wojtek: Czyli jak jesteś dobrym Scrum Masterem to szybko zmieniasz pracę.

Mateusz: Jak jesteś dobrym Scrum Masterem, to masz mało pracy, za którą Ci płacą w pełnym wymiarze, bo dobry Scrum Master tak pokieruje swój zespół i tak go wyszkoli i tak poprowadzi ten zespół w kontekście tego Agile Manifesto, że nie będzie potrzebny. Takie jest moje zdanie. Natomiast w zespole mamy też funkcję Product Ownera, o której wspominaliśmy dość dużo i funkcję deweloperów bez rozróżnienia na kompetencje. Z naszej perspektywy nie ma znaczenia czy Ty lubisz Reacta. Jak powiedzą Ci, że projekt jest Svelte czy Angularze to piszesz.

Wojtek: To ja mówię wypowiedzenie.

Mateusz: Deweloperze, że nie możesz tak często zmieniać pracy - w końcu się doigrasz. Ten rynek nie jest z gumy, ale fakt faktem mamy te różne role i zrozumienie kim jest PO i kim jest Scrum Master jest OK. Ale zrozumienie tego, że nie ma znaczenia kim Ty jesteś, jaką rolę pełnisz w zespole nie będąc PO lub Scrum Masterem jest już trudne, bo tak naprawdę jesteś wszystkim. QA, frontendem, backendem itd. I nie ma lidera. Najczęściej w takich klasycznych projektach lider nie jest potrzebny, bo zespół jest ładnie powiedziane samo organizujący się. Aczkolwiek z mojego doświadczenia wiem, że lider jest potrzebny.

Wojtek: Zdecydowanie się przydaje. Też dotknęliśmy rzeczy związanych z motywacją i kierowaniem developerami. Dodatkowo zapewniają odpowiednią komunikację pomiędzy członkami zespołu.

Mateusz: Tak jest - dokładnie tak. Stoję na stanowisku, że to jest bardzo ważna rola, która najczęściej ma bardzo dużo, powinna mieć przynajmniej, dużo umiejętności, kompetencji miękkich po to, żeby wesprzeć swój zespół w osiąganiu celów, ale niekoniecznie tych technicznych. Czy mamy coś jeszcze do dodania na ten temat? Podsumowując Wojtku, dzisiaj pogadaliśmy sobie troszeczkę o Scrumie i wydaje mi się, że obaj stoimy na stanowisku, że Scrum może być fajny, ale jest bardzo trudny i w zasadzie zrealizowanie projektu w czystym Scrumie jest w zasadzie niemożliwe w momencie, kiedy pracujemy z niedoświadczonym zespołem i z nieaktywnym zespołem. Rola, którą się pełni w takim zespole Scrumowym nie ma większego znaczenia, bo de facto cały zespół jest odpowiedzialny za dostarczenie i często tak naprawdę, wydaje mi się, że masz podobne zdanie, kładziemy za duży nacisk na to, że chcemy być Scrumowi. Zamiast na to, że po prostu chcemy dostarczyć po prostu coś, jakiś projekt. Łatwo się zgubić w procesach. Nie mówię, że wszystkie procesy są złe. Ale tak jak ty powiedziałeś, dojrzeliście do momentu, w którym Scrum był bardziej przeszkodą niż wsparciem dla waszej produktywności, w związku z czym podjęliście świadomą decyzję, że należy troszeczkę to zmienić i zaadaptowali kilka różnych frameworków do tego, żeby być jednak agile. I chyba na tym polega bycie Agile.

Wojtek: Zdecydowanie.

Mateusz: Zwinnie, zwinnie, nie? Jak przyjdzie PO i nie weźmiesz taska to ty nie jesteś zwinny. Więc myślę, że to tyle na temat Scruma. Dziękujemy ślicznie za rozmowę. Dziękuję Tobie Wojtku przede wszystkim. No i dziękujemy przede wszystkim też naszym słuchaczom, którzy są z nami już od sześciu, powiedzmy sobie szczerze, odcinków. Zachęcamy do dalszego śledzenia, słuchania. Gdybyście mieli jakiekolwiek pytania to śmiało kontaktujcie się z nami i do usłyszenia.

Wojtek: Dziękujemy bardzo.