To jest 4. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem będę rozmawiał o Scrumie.

W tej audycji, witają Cię Krzysztof i Jacek. W naszym podcaście, rozmawiamy ze sobą i z naszymi gośćmi o branży informatycznej. Przedstawiamy trendy, zjawiska i opinie. Staram się przybliżyć tę branżę tym, których w niej na co dzień nie ma, jak również zaciekawić stałych bywalców. Pozostań z nami.

A teraz zapraszam już na kolejny odcinek.

Krzysztof: Dzień dobry. Cześć! Witam Was w kolejnym odcinku i dzisiaj będzie to nieco inna forma, bo będzie to wywiad. Moim i Waszym gościem jest Paweł Prociów. Paweł, bardzo mi miło cię gościć. Dzięki za przyjęcie zaproszenia.

Paweł: To ja dziękuję za zaproszenie mnie.

Krzysztof: Super. Bardzo się cieszę. Paweł jest CTO w poznańskiej firmie Proxy Cloud, działającej w branży dicom networks i Internet of things. Pracował w wielu firmach związanych z elektroniką, takich jak Qualcomm czy Huawei, gdzie oprócz zadań typowo technicznych był zaangażowany w zarządzanie ludźmi, procesami, kontakt z klientem. Paweł ma doktorat z bioinżynierii biomedycznej, a sam siebie określa jako problem solver. I dzisiaj z Pawłem porozmawiamy sobie i wymienimy się naszymi doświadczeniami związanymi z metodologią Scrum. Ja może zacznę od kilku słów o tym, czym jest Scrum, dla tych, którzy jeszcze nie mieli do czynienia z tą metodologią. Otóż Srum, to jest framework, to nie jest jakiś gotowy proces czy zestaw metod czy określonych właśnie procedur, to jest framework, do prowadzenia, do rozwoju i budowania nowych produktów, nowych projektów i forma w jakiej obecnie Scrum funkcjonuje została stworzona na początku lat 80. przez Kena Schwabera i Jeffa Sutterlanda. Można powiedzieć, że Scrum, to jest taka właśnie forma działająca w obrębie spintu. Spint jest to okres czasu, dwóch tygodni do przeważnie miesiąca, w ramach którego toczy się budowanie aplikacji, budowanie kolejnych fitcherów czy też rozwój obecnych fitcherów. I na Scrum składają się takie rzeczy, jak: eventy, role, artefakty i zasady, które w ramach tego Scruma funkcjonują i myślę, że o tym powiemy sobie później. Trzeba powiedzieć, że Scrum jest taką dosyć lekką metodologią, dosyć łatwo zrozumieć zasady w niej panujące, ale jest trudny w implementacji, trudny w pełnym takim zaimplementowaniu zgodnie z zasadami. Paweł, chciałem ciebie zapytać, jakie ty masz doświadczenie ze Scrumem? Jakie projekty realizowałeś z wykorzystaniem tej metodologii?

Paweł: Tak, powiedzmy, że moje doświadczenie ze Scrumem, jest początkowo, bo ja zawsze pracowałem w takich rolach gdzieś pomiędzy biznesem, pomiędzy sprzedażą a developmentem, czyli bardziej byłem tą osobą, która te wymagania klienta gdzieś tam do zespołów Scrumowych dostarczała i jeszcze jako product owner, a potem pracowałem jako stricte menadżer produktu i to było właśnie przez mój krótki czas w Huawei’u, gdzie byłem product ownerem właśnie w takim procesie Scrumowym, który był dopiero co wdrażany, więc jeżeli chodzi o Scrum, to znam go głównie z perspektywy biznesu, w najlepszym razie product ownera niż z perspektywy developera, ale to daje mi taką trochę ciekawą optykę na to jak wykonać tą pracę, w pewnym sensie z zewnątrz, chociaż czasami z wnętrza.

Krzysztof: Super. To bardzo fajnie, bo ja mam z kolei zupełnie inną perspektywę właśnie od strony developerskiej, także fajnie będzie skonfrontować swoje doświadczenia czy swoje opinie na ten temat. Scrum bardzo często jest używany w projektach informatycznych, można powiedzieć, że te projekty informatyczne, programistyczne zwłaszcza, bardzo się lubują w Scrumie, wydaje mi się, że po części to jest dlatego, że Scrum dosyć dobrze wpasowuje się w podejście agilowe, tak chętnie stosowane przez programistów i odpowiada specyfice właśnie tych projektów informatycznych, aczkolwiek oczywiście należy powiedzieć, że Scrum nie został zaprojektowany czy stworzony tylko i wyłącznie do projektów informatycznych, natomiast w dzisiejszym czasie, to najczęściej spotykanie tego typu przedsięwzięcia.

Paweł: Trzeba powiedzieć, że Scrum jest też bardzo wygodny dla programistów. Jeżeli chodzi o developerów, to chyba jest to lepsza organizacja dla sposobów w jaki ci ludzie zazwyczaj myślą i myślę, że dlatego też jest bardzo popularny, bo łatwiej jest dla tej specyficznej grupy organizować pracę.

Krzysztof: Dokładnie. Myślę, że jak najbardziej właśnie tak jest. Ja myślę, że zanim przejdziemy sobie do omawiania jakichś naszych doświadczeń czy opinii związanej ze Scrumem, tytułem jeszcze wstępu opowiem kilka takich faktów z życia Scruma. Może zacznę od tego jakie są role w Scrumie, ponieważ to nam później pokaże jakie są perspektywy powiedzmy różnych osób w Scrumie. Pierwszą rolą, jest product owner, czyli osoba, która ma za zadanie formułowanie wymagań w stosunku do projektu, definiowania, określenia kolejnych fitcherów czy też definiowanie jak fitchery mają się rozwijać. Może to być osoba z wewnątrz firmy, ale w ogólności, może to być również osoba oddelegowana od strony klienta, dla którego dany projekt np. informatyczny realizujemy. Nie jest to osoba, czy też nie musi to być osoba techniczna, natomiast jest to osoba odpowiedzialna w głównej mierze za właśnie ten zbiór wymagań, tzw. product backlog, o którym też za chwilę sobie powiemy. Czyli musi dbać o to, żeby w sposób jasny i klarowny i przejrzysty było napisane, co należy wykonać. Kolejną rolą jest Scrum master i to jest taki można powiedzieć po części coach, czyli osoba, która ma za zadanie rozwiązywanie problemów wewnątrz zespołu projektowego. Jego nadrzędnym zadaniem jest wspieranie tych developrerów jak również product ownera i całej firmy we wdrażaniu Scruma, ale również w rozwiązywaniu takich jakichś personalnych problemów czy problemów w dostępie do materiałów, czyli jest gdzieś musi słuchać, wiedzieć, co w trawie piszczy, musi wiedzieć na jakimś etapie rozwoju projektu, projekt jest, natomiast w ogólności nie musi to być osoba techniczna. Oczywiście, praktyka pokazuje, że bardzo często Scrum masterem jest lead developer czy też osoba, która gdzieś tam się wyróżnia w zespole programistów i wówczas zadaniem takiej osoby jest rozwiązywanie konfliktów czy też wybieranie jakichś określonych rozwiązań, jeżeli zespół nie wie na co się zdecydować, ja osobiście najczęściej właśnie z takim schematem miałem do czynienia. Natomiast wiem, że w większych organizacjach, w większych korporacjach Scrum master to jest po prostu osobna rola, osobna osoba, która sprawuje tą rolę i wówczas to nie musi być osoba techniczna. Tutaj trzeba powiedzieć, że to jest taka rola, która najbardziej jest wymagająca pod względem właśnie takich umiejętności miękkich. I trzecią rolą jest developer. To jest taka zbiorcza nazwa na wszystkie te osoby, które w sposób techniczny realizują projekt i to nie tylko obejmuje developerów czyli programistów, ale również grafików, designerów, nawet testerów. Mamy takie ujednolicone nazewnictwo, jeśli chodzi o te osoby, po prostu określa się jako developer. W ramach scruma, mamy różne eventy, czyli ten cykl życia projektu, jego rozwoju jest właśnie określany po przez taki event, często określa też je się jako ceremonię czy wydarzenia, Wszystko zaczyna się od planowania sprintu, na którym product owner mówi co dobrze by było zrealizować w następnej kolejności. Daje jakiś ton, czy jakiś kierunek, w którym powinniśmy iść z rozwojem, następnie zespół developerów, bazując na swojej wiedzy, czy na tym co może być zrealizowane, albo  co uważa, że dobrze byłoby zrealizować. Wybiera zadania do tego sprintu z produkt backloga i definiuje tak naprawdę, co zostanie w tym nowym sprincie. Kiedy rozpoczyna się sprint, mamy codzienne daily scrum, które codziennie gdzieś tam się odbywają, krótkie, w których uczestniczą developerzy i na tych mitingach mówią po prostu, co udało im się wykonać dnia poprzedniego, jakie mają, z czym mają problemy, na co czekają od pozostałych developerów i również wiem, co planują wykonać w dniu dzisiejszym. Po upływie tych dwóch tygodni czy miesiąca, w zależności jaka jest potrzeba w danej firmie, czyli po upływie udanego sprintu, przychodzi czas na sprint review, to jest takie spotkanie, w którym uczestniczą nie tylko developerzy, ale też product owner, stackholderzy, mogą być zaproszeni nawet reprezentanci klienta, na którym robi się demo, pokazuje się, co udało się zrealizować, przy czym tutaj jest taka informacja, że tutaj muszą być funkcjonalności zakończone. Takie, które można z deployować, można wrzucić na tą produkcję. Można też podczas tego spotkania wysłuchać jakie są oczekiwania klienta, stackholderów, co uważają, że dobrze byłoby wdrożyć albo ewentualnie jak zmienia się przemysł, jak zmienia się ten rynek na którym działamy. Później przychodzi na retrospekcje, czyli spotkanie bardziej dla programistów, ale również dla Scrum mastera. Rolą tego spotkania jest umówienie, co poszło dobrze w tym sprincie, co można byłoby ulepszyć, co zmienić, żeby przybliżyć się bardziej do takiego idealnego wrażenia Scruma. To są właśnie eventy, które określają Scrum, tak jak gdzieś tam już wcześniej mówiłem, w Scrumie mamy takie rzeczy jak product backlog czyli zestaw, listę tych zadań, fitcherów, które chcemy zrealizować, to jest ciągle rosnące, nigdy nie zamykająca się lista rzeczy do zrobienia. Jest sprint backlock, czyli lista zadań, lista tasków, które zostały określone do zrealizowania w danym sprincie. To myślę na tyle, jeżeli chodzi o taką suchą teorię związaną ze Scrumem, tak jak wspomniałem na początku Scrum jest bardzo popularny w projektach informatycznych, być może właśnie z uwagi na to, że fajnie wpasowuje się w manifest agilowy, w takie lekkie podejście. Tak zastanawiam się Paweł, co ty myślisz na ten temat? Jak Scrum ma się do agila?

Paweł: Tak, zdecydowanie jest to dobry framework, w którym można by realizować agile, takie agilowe podejście, czyli zwłaszcza w takim świecie zmieniających się wymagań i często te wymagania nie są jasne, albo bardzo szybko się zmieniają, zwłaszcza na rynku IT, więc to jest jak najbardziej mądre podejście i myślę, że tutaj dużo zależy od właściwego, z braku lepszego słowa, feedowania tych wymagań do zespołu, czyli tutaj myślę, że bardzo ważną jest rolą, jest rola product ownera, który, żeby jasno wytyczał te cele i informował w odpowiedni sposób o zmianach w wymaganiach, czy to klienta, czy wymaganiach biznesowych.

Krzysztof: Tak, dokładnie. Następny taki temat, który chciałbym z tobą poruszyć, to jak teoria ma się do praktyki, tzn. doskonale wiemy, że w Scrumie nawet bezpośrednio jest napisane, że albo wdrażamy Scruma w całości albo lepiej jest nie wdrażać jego, tylko jego fragmenty. Natomiast praktyka często pokazuje, że nie ma takiego idealnego wdrożenia Scruma, gdzie wszystkie elementy funkcjonowałyby zgodnie z tym jak to jest określone w Scrum gate, raczej często wybiera się tylko te elementy Scrum, które nam pasują albo właśnie odpowiadają zespołowi i zastanawiam się czy według ciebie to jest dobre podejście czy złe, czy powinniśmy ryzykować czy może raczej trzymać się wymagań?

Paweł: Wiesz co, to jest temat rzeka dla mnie, bo pierwsze nie widziałem dobrze wdrożonego Scruma chyba. Tak po prawdzie nie mogę powiedzieć, żeby w którejkolwiek organizacji pracowałem, ten Scrum był tak idealnie wdrożony, więc nie wiem jak dobry byłby Scrum, gdyby był wdrożony w pełni. Wiem natomiast, że Scrum otwiera drogę do pewnych nadużyć, ale też ma pewne genialne elementy. Może najpierw o tej pozytywnej stronie, więc jeżeli zespół nie do końca wdraża Scruma, czy to ze względu na rozmiar, czy to ze względu, jakiekolwiek faktory, które by decydowały, że akurat Scrum nie jest wdrożony, to warto brać te dobre elementy Scruma, które się sprawdzą nawet nie przy pełnym Scrumie. Na przykład moim osobiście ulubionym elementem Scruma, jest ceremonia daily. Świetny sposób, żeby zespół rozmawiał ze sobą, informował się na wzajem o problemach, żeby ktoś, kto zarządza tym zespołem, wiedział, czym się zajmuje jego zespół, czym będzie się zajmował, jakie są problemy, można pomóc innym kolegom, bo np. słyszą od razu jakie są problemy, nie ma tego problemu „może poprosić o pomoc, może nie”, wszystko jest fajnie tą ceremonią załatwione. Inna sprawa, że nie w pełni wdrożony Scrum, właśnie otwiera taką drogę do takich trochę nadużywań, np. taki mit, który często się słyszy, to jest to, że ponieważ jest agile, ponieważ jest Scrum, to nie trzeba robić dokumentacji, bo ważniejsze jest, żeby działało, niż żeby było udokumentowane i to nie jest zgodne ze Scrumem, a jednak w wielu zespołach tak to trochę funkcjonuje. Tak samo jest rola sprintu często przeceniana, bo jest to wygodne, mianowicie, że jak jest sprint, to niczym go broń Boże nie zakłócamy, ponieważ sprint jest niejako święty i nie dorzucamy zadań w trakcie sprintu i to jest często wykorzystywane do działania wbrew filozofii agile, czyli niedostosowywania procesu do nowych wymagań. Takie są moje spostrzeżenia, jeżeli chodzi o plusy i minusy nie w pełni wdrożonego Scruma.

Krzysztof: Tak, dokładnie. Ja mam całkiem podobne doświadczenia. Scrum jako taki oczywiście nie może być wdrożony od razu, z dnia na dzień, oczywiście to jest pewien proces, chociażby istnienie takich rzeczy jak retrospekcja jest tutaj informacją do tego, żeby ten Scrum był udoskonalany przez sam zespół, więc siłą rzeczy, to wdrożenie, czy ta adaptacja Scruma, to jest zawsze jakiś proces, natomiast zgodzę się, że nie powinniśmy rezygnować czy nie powinniśmy pomijać Scruma w wyborze metodologii tylko dlatego, że nie jesteśmy w stanie wdrożyć wszystkich jego elementów. Ja osobiście też bardzo cenie sobie te daily stand up’y, natomiast podobnie jak ty wspomniałeś, często wydaje mi się, że cała ta metodologia czy te zasady są taką tarczą stosowaną przez programistów do tego, żeby powiedzieć, że albo coś im się nie chce zrobić, albo na coś nie mają ochoty, albo bo w Scrumie jest napisane tak a tak. To jest wówczas pewne nadużycie i stosowanie tych zasad, czy tych reguł w niewłaściwy sposób. Natomiast patrząc na ten bilans plusów i minusów, to oczywiście uważam, że wdrożenie Scruma nawet częściowo jest lepsze niż nie posiadanie tutaj żadnej metodologii i robienie wszystkiego na tak zwanego czuja.

Paweł: Ja tutaj mam taką, nie wiem czy to jest dobre miejsce na tą anegdotę, ale obecnie mój zespół w Praxicalt pracuje w czymś, czego nie można nazwać Scrumem, zdecydowanie to jest taki nie w pełni wdrożony Scrum, a wręcz taka metodologia, która wyewoluowała z podejścia Scrum to za dużo, zróbmy coś w rodzaju kanbana, i to jest ciekaw jak ten system, który zaadoptowaliśmy ewoluuje, dodajemy co raz to kolejne elementy, ewoluuje w stronę takiego Scruma. Ja podejrzewam, że być może za rok będziemy w pełni używać Scruma nawet o tym nie wiedząc.

Krzysztof: Tak, właśnie. Na pewno jest to pewien proces. To się zgadza. Super. Chciałem cię również zapytać, jakie jest twoje zdanie na temat wdrożenia Scruma przez programistów, versus fakt, że to raczej cała firma musi się dostosować czy być świadoma tego, że stosujemy Scruma. Z moich doświadczeń wynika, że niezbędne jest to, żeby nie tylko programiści, ale pozostali take holderzy, czy nawet szef firmy był świadomy, tego, że właśnie ta metodologia jest stosowana. Jest to chociażby niezbędne po to, żeby produkt owner czuł się umocowany na tyle, żeby decydować o produkcie, żeby klienci byli poinformowani w jaki sposób się praca odbywa, czyli nie fokusujemy się tylko z wdrożeniem Scruma na zespole programistów, ale Scrum master ma tutaj taką rolę, żeby ewangelizować, jeżeli chodzi o Scrum, całą firmę. Zastanawiam się jakie ty masz tutaj zdanie na ten temat.

Paweł: Zdecydowanie cała firma powinna być wdrożona w to, czy może nie powinna być wdrożona, powinna wiedzieć o tym, że stosujemy Scruma i powinna wiedzieć jakie są tego konsekwencje, jakie są plusy, jakie są minusy. Nie użyłbym słowa ewangelizować, bo ja wiem jak np. w sprzedaży jest ciężki Scrum, jak ciężko jest obiecać coś klientowi, albo powiedzieć, że coś będzie gotowe na kiedyś. Wiem, że to jest ciężki kawałek chleba do zgryzienia w działach, które funkcjonują zupełnie inaczej, nie mniej jednak muszą być tego świadome, muszą wiedzieć z czym to się wiąże, więc nawet jeżeli nie będą chwalić tej metodologii przed klientem, to muszą wiedzieć z czym ona się wiąże i w jaki sposób rozmawiać potem z klientem. Jeżeli chodzi o informowanie klientów, to nie jestem przekonany, że jest to takie konieczne, oczywiście można to powiedzieć, ale myślę, że koniec końców klient trochę jest święty i w zasadzie to nie powinno go obchodzić, czy pracujemy w Scrumie, czy pracujemy w waterfallu, czy w jakiejkolwiek innej metodologii, bo dla niego ważny jest efekt i trzeba się tego trzymać.

Krzysztof: Tak, nie da się ukryć, że to jest najistotniejsza rzecz dla klienta. Paweł na początku wspomniałeś, że programiści w twojej opinii bardzo sobie cenią i lubią takie podejście Scrumowe. Mówiłeś też, że masz takie doświadczenia takie zawodowe związane z biznesem i z relacjami z klientem końcowym. Zastanawiam się właśnie jak do Scruma podchodzi biznes albo klient końcowy. Już wspomniałeś, że być może klienta końcowego nie powinno interesować z jakiej metodologii my korzystamy, ale jestem ciekaw, czy miałeś okazję zaobserwować, jak biznes, stackholderzy odnoszą się do Scruma?

Paweł: Tak, myślę, że to jest ciężki trochę temat, zwłaszcza dla takich tradycyjnie ustawionych biznesów, z tradycyjnie ustawioną sprzedażą, z tradycyjnymi, może nie produktami, bo w IT ciężko mówić o tradycyjnych produktach, ale jest to ciężki też kawałek chleba, bo tu przede wszystkim bez dobrych znajomości Scruma, a najczęściej na takim froncie przed klientem, nie mamy osoby, która bardzo dobrze zna ten proces, ciężko jest estymować, ciężko jest powiedzieć, kiedy będzie coś dowiezione, kiedy jakiś konkretny fitcher wjedzie na produkcję, a tego powiedzmy potrzebuje klient, albo od tego uzależniona jest sprzedaż, więc nie jest to łatwe funkcjonowanie w Scrumie poza Scrumem, że tak powiem, a siłą rzeczy ciężko, żeby sprzedaż, wsparcie techniczne też w pełni było wdrożone w Scruma, więc jest pewien opór zazwyczaj ze strony biznesu i jeżeli chodzi o mnie, jest on w pewnym sensie zrozumiały, dlatego też nie można przyjmować takiego podejścia, no dobra, ale scrum to jest coś takiego, co działa i to jest najlepsze do zmieniających się wymagań , dlatego zostajemy przy tym i tyle, i po prostu to niech klient się martwi. Bo trzeba po prostu mieć też na uwadze, że klientowi trzeba przedstawić konkretną wizję produktu, konkretną look mapę i konkretne daty często kiedy coś będzie dowiezione.

Krzysztof: Tak, zgadza się. Klienci jak najbardziej cenią sobie zawsze pewną stałą informację, czy pewną informację. Myślę sobie, ze wymaga to naprawdę świadomego klienta, żeby zgodzić się na takie podejście i ten klient musi sobie zdawać sprawę z pewnych ryzyk związanych ze Scrumem, ale również z pewnych pozytywów z tego wypływających. A z drugiej strony, jeżeli chodzi o biznes, też wymaga to pewnego zaufania do zespołu projektowego, do developerów, że właśnie to co ma być, zostanie dowiezione mnie więcej w oczekiwanym czasie i, że to wszystko nam się po drodze nie rozjedzie. Także wymaga to na pewno zaufania. Paweł, wspomniałeś, że Scrum jest lubiany przez programistów, daje im pewną swobodę, faktem jest, że jest taka swoboda samo stanowienia, jeżeli chodzi o Scrum. Developerzy podejmują decyzję z jakiej technologii korzystają, a nawet jakie fitchery wybierają do sprintu, sami się organizują w zespoły, jeśli jest to potrzebne, mają dużą swobodę w tej materii. Tak jak też mówiłem na początku w tym temacie o rolach w Scrumie, jest jedna tylko rola developera, w sensie Scrum nie rozróżnia na takie tradycyjne jakieś podejście typu lead developer, mit developer, jakiś junior developer, jest po prostu powiedziane, że mamy do czynienia z developerami i zastanawiam się wobec tego, gdzie w takim podejściu jest miejsce czy rola team lidera albo takie lead developera, jak mogą się takie osoby, które wcześniej pracowały na takich stanowiskach odnaleźć w Scrumie, skoro wszyscy są równi?

Paweł: Wszyscy są równi, jeżeli chodzi o sam proces, ale nie mniej tak jak powiedzieliśmy, nie cała firma pracuje w Scrumie i jeżeli chodzi o moje doświadczenia, to w zespole Scrumowym, w którym pracowałem, w tym najbardziej Scrumowym zespole, gdzie pracowałem w Huawei, to był lead developer, był jak najbardziej częścią zespołu i on był pewnego rodzaju, to była osoba, która była już bardziej doświadczona od zespołu i pełnił taką rolę, nazwałbym ją poza Scrumową, bo on był trochę taką tarczą, która broniła zespół przed takim zewnętrznymi wpływami, że wiadomo, że jeśli ktoś miał problem, że coś jest niedowiezione, że czegoś brakuje, to nie szedł z tym do konkretnego programisty, tylko bardziej to się rozbijało o tego lead developera. On trochę zapewniał ten komfort pracy tego zespołu, więc on był takim menadżerem, ale takim poza Scrumowym. Takim menadżerem w sensie czysto tradycyjnym.

Krzysztof: Czyli mówisz, że to powiedzmy, że mamy developerów, tylko developerów, którzy gdzieś tam zewnętrznie mogą być właśnie widziani jako taka, brzydko mówiąc ujednolicona masa, to wewnętrznie w danym zespole, w danej firmie i tak istnieją mniej lub bardziej schowane role, które odpowiadają za określone rzeczy. Myślę, że to jak najbardziej ma sens.

Paweł: Nie mówiąc o tym, że lead developer ma też bardzo ważną rolę, jeżeli chodzi o sprint planning i też moim zdaniem to nie jest tak, że zespół w pełni może sobie dobrze zaplanować i jest potrzebna taka osoba, która jest bardziej, bo z jednej strony mamy product ownera, który reprezentuje bardziej klienta, reprezentuje bardziej wymagania, ale musi być też trochę taka przeciwwaga w postaci kogoś, kto rozumie, co trzeba zrobić, czego nie można zrobić i jak to można zrobić, to najlepiej jak to jest też mimo wszystko lider w jakimś tam sensie, mimo, że nie ma takiej roli przewidzianej w Scrumie.

Krzysztof: Ale myślisz, że to powinna być taka osoba, która jest tam gdzieś mianowana z góry tym team liderem czy lead developerem? Czy też raczej to jest taka osoba, która sprawuje taką rolę, ponieważ lubi, albo właśnie ma doświadczenie i została jakoś nominowana przez zespół sam w sobie?

Paweł: Chyba to drugie podejście jest dość dobre, aczkolwiek to znowuż rodzi takie ryzyko, że zespół trochę się będzie zdawał na taką osobę, więc wiadomo, że decyduje o tym Krzysiek, bo on jest najbardziej doświadczony, więc trochę ujmujemy w tym momencie zespołowi tego samostanowienia, a z drugiej strony to jest jeszcze bardziej pogłębione, jeśli kogoś mianujemy lead developerem trochę z góry, więc myślę, że takie role się chyba jednak naturalnie tworzą. Polemizując trochę z tym, co powiedziałem przed chwilą, nie uważam, że istnienie postaci lead developera czy lidera jest konieczne w Scrumie, ale twierdzę, że może się po prostu przydać.

Krzysztof: Tak, jak najbardziej. Ja mam podobne doświadczenia. Tak jak mówiliśmy w sprincie realizujemy nowe funkcjonalności albo rozszerzamy funkcjonalności, które już istnieją, to jest coś, co najbardziej interesuje biznes, czyli dowożenie kolejnych rzeczy, które są dla niego cenne, ale oczywiście tak jak dobrze wiemy, projekty informatyczne, projekty programistyczne, to nie tylko nowe fitchery, to również shaggy, od czasu do czasu jakiś refaktoring, spłacanie tego zaciągniętego długu technologicznego i zastanawiam się, jak myślisz, czy w Scrumie, a jeśli tak, to gdzie jest miejsce na tego typu rzeczy? Czy może powinna to być normalna praktyka w sprincie, część sprintu jest przeznaczona na tego typu badania czy refaktoring, czy też może od czasu do czasu powinniśmy sobie zrobić osobny sprint przeznaczony tylko na tego typu działalności?

Paweł: De facto w przeciwieństwie do bugów, dług technologiczny to jest jeszcze coś, co można zaplanować, bo wiemy mniej więcej jaki mamy dług technologiczny, więc możemy zalookować sobie jakieś miejsce i uznać, że jakąś tam część poświęcamy długowi technologicznemu, jednak wiem, że w praktyce w większości wypadków po prostu nie ma na to czasu, więc albo trzeba coś zrobić bardzo szybko, więc ten dług technologiczny rośnie, albo w najlepszym razie się nie zmienia i koniec końców on jest, jeżeli jest spłacany, to jest spłacany w takich wolnych chwilach i wtedy wówczas cały sprint jest poświęcony niejako długowi technologicznemu i to jest też, i jeszcze raz w przeciwieństwie do bagów, dług technologiczny jest często bardzo ciężki do zrozumienia od strony biznesu, bo biznes nie rozumie, co wyście robili przez cały tydzień, przecież nic się nie zmieniło, produkcja działa, to co to znaczy, że refakturowaliście jakąś bibliotekę, która nie długo przestanie być wspierana. To jest rzecz, którą łatwo jest zaplanować, ale ciężko jest sprzedać biznesowi, który mniej lub bardziej płaci za te godziny developerom, a z drugiej strony mamy bugi. Bugi, które bardzo potrzebne są biznesowi, które są często klienci krzyczą, że coś jest nie tak, trzeba coś naprawić na teraz, a tutaj mamy trwający sprint i jest znowuż ciężko zaplanować, ale są mega ważne z punktu widzenia biznesu, więc myślę, że i na jedno i na drugie musi się znaleźć czas w sprincie, tak naprawdę.

Krzysztof: Tak. Ja myślę, że robienie osobnego sprinta tylko na tego typu rzeczy nie jest dobre. Wręcz Scrum mówi, że się tak nie powinno robić. To są rzeczy, które są tam zdefiniowane jako takie wymagania nie funkcjonalne, czyli ta technologia można powiedzieć, według Scruma, to powinien być element każdego sprintu i z mojej praktyki też wynika, że najlepiej by było, jeśli byśmy właśnie naprawiali bugi czy próbowali coś refaktorować w każdym sprincie, ale myślę, że istotne jest to, żeby nie próbować tego robić gdzieś tam poza sceną, ukrywać tego przed biznesem, bo wówczas dosyć łatwo stracić zaufanie, a nie raz właśnie tak jak wspomniałeś trudno wybrnąć czy uzasadnić, gdzie ten czas został spożytkowany. Myślę, że takie zaufanie jest niezbędne, że to robimy w dobrej wierze i jeżeli jest to transparentne i przejrzyste to się sprawdza.

Paweł: Otóż to, ale muszę powiedzieć też, że to jest według mnie jedna z wad Scruma, że nie ma jasnej przestrzeni, jasnego procesu jak się obchodzić z bugami, czyli z czymś, co wjeżdża w połowie sprintu i często musi być załatwione na już i tutaj jest, bardzo często rodzą się konflikty, no ale mamy sprint, możemy się dopiero zająć tym pod koniec przy planowaniu następnego sprintu, ale nie, to klient potrzebuje na teraz, trzeba to wcisnąć itd. To jest dużo konfliktów, które nie do końca jest jasne jak rozwiązywać. Nawet w myśl ideologii Scrumowej.

Krzysztof: Dokładnie. Myślę sobie, że kontynuując ten temat, powiedzieliśmy, że Scrum skupia się na kliencie, na dostarczaniu nowych fitcherów i oprócz tych bagów czy długu technologicznego są też takie istotne rzeczy każdego projektu informatycznego, jak np. planowanie, ustalanie architektury, wprowadzanie pewnych innowacji, coś, co również nie dostarcza bezpośrednio nowej funkcjonalności dla klientów. Zastanawiam się jakie tutaj masz doświadczenia? Gdzie i kiedy to powinno się odbywać?

Paweł: Jakby naturalnym miejscem sprint planning, ale tak naprawdę musi być też ten, to musi być w jakimś takim szerszym zakresie ustalane i tak jak mówię, tutaj w ramach tych takich tradycyjnych ceremonii Scrumowych, często jest ciężko znaleźć to pole, bo tych take coderów jest trochę w każdym projekcie i moim zdaniem nie ma dobrej odpowiedzi na to pytanie.

Krzysztof: Dokładnie. Myślę, że to jest właśnie jeden z problemów Scruma, że dosyć prosto stwierdzić, żeby wszystkie tego typu niefunkcjonalne elementy, były elementami sprintu, natomiast w praktyce jest dosyć trudne w realizowaniu, bo o ile faktycznie naprawianie bugów, dosyć dobrze tutaj się wpasowuje, o tyle takie rzeczy jak ustalanie architektury czy później tak dokładnie np. dokumentacja, myślę, że wprowadzanie tego typu rzeczy w Scrumie jest zawsze taką żonglerką, nie ma dobrej odpowiedzi, to zależy od zespołu, od projektu, od klienta pewnie. Właśnie, a jeszcze taki temat związany ze Scrumem, w obecnych czasach mamy certyfikat prawie na wszystko, jeśli chodzi o IT. Nawet są żarty czy różne memy związane z tą certyfikacją. Są oczywiście technologie, gdzie certyfikowanie się ma sens, inne, gdzie to jest taka przysłowiowa wisienka na torcie. Ja osobiście, jeśli chodzi o certyfikacje w Scrumie, mam takie mieszane uczucie. Sam mam certyfikat, ale to jest certyfikat Scrum mastera i to jest według mnie jedyna rola, która ma sens, żeby się certyfikować, ale nie dla samego certyfikatu, nie dla samego papierka, tylko to jest dosyć specyficzna rola. taka trochę miękka, która gdzieś tam ociera się o coaching, o takie ludzkie podejście. Wydaje mi się, że wiedzę, którą ja np. nabyłem ucząc się, przygotowując się do dostania tego certyfikatu, trochę mi otworzyła oczy na pewne relacje. Na takie właśnie rzeczy z którymi, normalnie developerzy na co dzień nie do końca mają do czynienia, także moja opinia jest taka, że jeżeli chodzi o certyfikację w Scrumie, to tak, ale tylko dla Scrum mastera. Nie wiem, czy miałeś okazję w swojej karierze spotkać się z kimś, kto robił certyfikat w Scrumie?

Paweł: Tak, ja sam się biłem z tą myślą, czy tutaj się nie certyfikować, czy nie pomoże to w jakimś tam sensie, ale zgodzę się z tobą, że jeżeli chodzi o Scrum mastera, to jest jedyna rola, gdzie tak naprawdę widzę, nawet jeżeli nie rozumieją tego certyfikatu, to jest bardzo potrzebna rzetelna wiedza na temat Scruma, żeby go po prostu dobrze wdrożyć, bo to trochę się potem zupdatuje w dół na resztę zespołu. Jeżeli jest dobry Scrum master, to dobrze ustawi tego Scruma, jeżeli nie, to nie. Certyfikacja to jedno, a wiedza to drugie, więc nawet ważne jest, żeby taka osoba była wyszkolona. Ja osobiście nie jestem fanem certyfikacji w ogóle, faktycznie, to dochodzi do absurdów, jeżeli chodzi o certyfikaty i niestety moim zdaniem to jest efekt, trochę zboczę tutaj z tematu, ale to jest efekt rynku rekrutacyjnego, którego trochę mamy, że rekrutują często osoby, które nie są w stanie sprawdzić wiedzy danego kandydata, więc jeżeli kandydat ma certyfikat, to pewnie się zna na tym, jeżeli nie ma, to po co ryzykować, więc tak naprawdę certyfikat nie powinien świadczyć o tym, czy ktoś ma jakąś umiejętność czy nie, ale niestety jest to często potrzebne, żeby przejść jakieś sito rekrutacyjne i tylko i wyłącznie po to.

Krzysztof: Tak. Zgodzę się z tobą, że faktycznie dochodzi do różnych absurdów, jeżeli chodzi o certyfikację, ale myślę sobie, że zrobienie samemu dla siebie certyfikatu po to, żeby się nauczyć pewnych rzeczy, to jest taka jedyna sensowna według mnie droga. Robienie tego dla papierka, to tak jak ze wszystkim, robienie studiów dla papierka też ma mały sens i jest stratą czasu. Tak samo w przypadku certyfikatów. Chciałbym z tobą poruszyć też taki wątek związany  z tym, czym się stresują developerzy w Scrumie, bo mówiliśmy sobie gdzieś tam, że oni, ta odpowiedzialność troszeczkę rozmyta i chowają się za wspólną odpowiedzialnością, ale z drugiej strony product ownerzy często wprowadzają takie mechanizmy jak śledzenie postępu, czy wymagają estymacji, tasków od programistów, jakiegoś raportowania godzin. Niekoniecznie tutaj chodzi o to, żeby robić to w złej wierze, ale po to, żeby zobaczyć jak właśnie ten postęp idzie do przodu i zastanawiam się czy tego typu praktyki mogą być stresujące dla developerów?

Paweł: Każda forma kontroli myślę, że może być stresująca dla developerów. Dla mnie jest oczywiste, czemu tak jest. Po prostu są naciski często ze strony biznesu, ze strony sprzedaży, ze strony wymagań ze strony klienta często bezpośrednio, które rozbijają się gdzieś tam, są przekazywane do teamu Scrumowego za pośrednictwem product ownera i dokładnie stąd jest ta potrzeba kontroli, potrzeba takiego sprawdzania, że ten postęp jednak i przede wszystkim potrzeba wiedzy, kiedy coś zostanie ukończone, nawet w trakcie sprintu, bo często też jest taka kwestia zaufania, bo jeżeli jakieś fitchery przez parę kolejnych sprintów nie zostały dowiezione, to też jest podejrzenie, że nie będzie dowiezione w tym sprincie, więc to jest też kwestia tego, czy faktycznie biznes czy tam product owner może mieć zaufanie, że jak coś zostało zaplanowane, to faktycznie na koniec sprintu będzie i przez dwa tygodnie nie muszę się tym martwić, bo wiem, że za dwa tygodnie na koniec sprintu dostanę swój fitcher.

Krzysztof: Też sobie tak myślę, że jeśli jestem programistą, który rzetelnie pracuje, który faktycznie ma za swój cel dowiezienie tych rzeczy do których się zobowiązał, to tak naprawdę nie powinien się tych rzeczy obawiać. To nie powinien być jakiś straszak, bo ja rzetelnie pracuję i chcę ukończyć rzeczy do których się zobowiązałem. W trakcie dzisiejszej rozmowy wspomnieliśmy o tym, że ten Scrum ma różne oblicza. Są różne plusy dodatnie i plusy ujemny Scruma. Czy w związku z tym według ciebie Scrum jest dobry dla każdego projektu informatycznego, programistycznego?

Paweł: Zdecydowanie nie. To chyba nawet w manifeście, może nie w manifeście, ale w każdym szkoleniu ci powiedzą, że w projektach, gdzie ważne jest bezpieczeństwo czy życie ludzkie nie powinno się stosować Scruma, bo po prostu tam musi być wszystko sprawdzone w odpowiedni sposób i procesy są inne, więc nie. Zdecydowanie nie jest dobry dla każdego projektu. Myślę, że też nie jest dobry, gdy mamy niedoświadczony zespół albo zespół złożony głównie z osób takich jak mówiliśmy junior – młodych, więc uważam, że zespół musi być odpowiedzialny i dojrzały, aby w pełni wdrożyć Scruma, bo inaczej skończymy z takim niepełnym Scrumem, gdzie jest on używany tylko jako tarcza, którą nawzajem używają czy to programiści, czy biznes, żeby coś od siebie wymagać.

Krzysztof: Dokładnie. Ja myślę podobnie, czyli powinniśmy wybrać metodologię czy technologię do problemu, który mamy a nie odwrotnie. Czyli zawsze wybierać Scruma, ponieważ słyszy się, że on jest fajny, że on się sprawdzi, czyli nie postępować tak w ciemno.

Paweł: Tak, nie zgadzam się tu ze stwierdzeniem, że Scrum się sprawdza, że już dwóch czy trzech osób można mówić o Scrumie, uważam jednak, że Scrum jednak lepiej zdecydowanie się sprawdza, kiedy jest duży zespół, a przy małych zespołach, to trochę tak jak z każdym procesem, wśród małych tak jak w startupie nie masz procesów z korporacji, bo po prostu się nie sprawdzają a niekoniecznie dlatego, że nie mają sensu, tak samo w małym zespole też Scrum może być po prostu takim za dużym, mieć za duży koszt wejścia.

Krzysztof: Super. Bardzo ci dziękuję Paweł. Bardzo miło było mi ciebie dzisiaj gościć. Fajnie się rozmawiało, Dzięki, że podzieliłeś się swoimi doświadczeniami i powiedz, gdzie cię można znaleźć w Internecie?

Paweł: Jak już wspomniałeś, moim głównym zajęciem jest bycie CTO w firmie Proxy Cloud, więc zachęcam w ogóle do kontaktu, do zajrzenia na naszą stronę proxy.cloud i tak samo można do mnie napisać na mail: pawel@proxy.cloud. A jeżeli ktoś się interesuje technologią IOT w szerszym zakresie, to zapraszam na moją stronę www.prociow.com.

Krzysztof: Super. Dzięki Paweł jeszcze raz. Do usłyszenia. Cześć!

Paweł: Cześć!

Krzysztof: I to na tyle z tego, co przygotowałem dla Was na dzisiaj. Bardzo fajnie mi się z Pawłem rozmawiało. Więcej informacji o tym odcinku podcastu możesz znaleźć na stronie PorozmawiajmyoIT.pl/4. Dzięki wielkie i do następnego razu. Dziękuję Ci serdecznie za wysłuchanie kolejnego odcinka podcastu Porozmawiajmy o IT. Chcielibyśmy, aby ten podcast docierał do jak najszerszego grona słuchaczy. Możesz nam w tym pomóc, zostawiając gwiazdki i opinię w katalogu iTunes lub innej aplikacji, z której korzystasz do słuchania podcastów . Będziemy Ci wdzięczni za podzielenie się informacją o tym podcaście w mediach społecznościowych. Jeszcze raz dzięki za bycie z nami i do usłyszenia w kolejnym odcinku. Cześć.