Praca programisty to nie tylko kodowanie i tworzenie aplikacji, to także ustrukturyzowanie tej pracy na podstawie różnych metod pracy. W dzisiejszym odcinku podcastu DEVision porozmawiamy o jednej metodzie z zakresu zwinnych metod programowania, czyli o 🅂🄲🅁🅄🄼. Gościnią odcinka jest Eliza Willim, która opowie o tym jak została Scrum Masterką oraz jak wygląda jej współpraca z programistami. Odpowie ona także na główne pytania, które mogą nurtować programistów IT, czyli:
👉 Czym jest Scrum?
👉 Jak metoda scrumowa pomaga w pracy programistom IT?
👉 Czy jest on potrzebny programistom?
👉 Jakie są korzyści / wady tego podejścia?
Nikodem: Cześć, z tej strony Nikodem. Witam w kolejnym odcinku podcastu DEVision. Jest dzisiaj ze mną Eliza – cześć, Eliza (Eliza: cześć)! Eliza jest Scrum Masterką i będę z nią dzisiaj rozmawiał o Scrumie.
Eliza: Tak jest. 🙂
Zanim przejdziemy do głównego wątku, chciałbym, żebyś opowiedziała nam kilka słów o sobie, bo słyszałem, że masz całkiem ciekawą historię na temat tego, jak zostałaś Scrum Masterką. 😉
Ja z wykształcenia jestem farmaceutką. Skończyłam studia farmaceutyczne i pracowałam przez pięć lat w aptece jako magister farmacji. Po pięciu latach powiększyła mi się rodzina, więc trochę przewartościowałam pewne rzeczy i stwierdziłam, że praca na zmiany to nie jest to, co chcę robić do końca życia.
Miałam przyjaciół programistów, którzy doradzili mi, żebym spróbowała wziąć udział w kursie internetowym z podstaw programowania i zobaczyła, czy to jest w ogóle coś, co mi się podoba. Zaczęłam taki kurs i faktycznie szło mi całkiem dobrze. Na początku były bardzo fajne tematy, ja miałam dużo czasu – moje dziecko dużo spało. Potem, tak się złożyło w czasie, że tematy zrobiły się trudniejsze, a moje dziecko spało coraz mniej, więc w pewnym momencie jednak wymiękłam z samodzielną nauką.
Wtedy potrzebowałam trochę szczęścia i się ono pojawiło, ponieważ był organizowany kurs dla osób spoza branży IT w celu przebranżowienia się. Taki kurs był dofinansowany przez jedną z firm telekomunikacyjnych. Przeszłam kilka etapów rekrutacji na ten kurs, dostałam się, skończyłam go i po zakończeniu dostałam stanowisko Junior Testera w tej firmie telekomunikacyjnej, w zespole testerskim.
Bardzo dużo szczęścia miałam z zespołem – trafiłam do zespołu bardzo otwartego, pomocnego, gdzie ludzie nie chcieli tworzyć takich silosów kompetencji, tylko chętnie uczyli nowe osoby. Miałam też bardzo fajnego mentora. Pracowałam tam jako Tester przez dwa lata i (znowu przez przypadek) koleżanka, która była Scrum Masterką, postanowiła skierować się na ścieżkę techniczną rozwoju i ja wtedy podjęłam częściowo rolę Scrum Mastera – byłam częściowo Testerem, a częściowo Scrum Masterem.
Brzmi to bardzo prosto! Czy to znaczy, że każdy może zostać Scrum Masterem?
Może brzmi to prosto, ale tak naprawdę wymagało to ode mnie bardzo dużej dozy wytrwałości, samodyscypliny, i bardzo dużo musiałam się nauczyć – poza kursem, na który uczęszczałam. Pracując już jako Junior Tester musiałam bardzo dużo się uczyć, żeby nadrabiać jakieś zaległości, które wydawało mi się, że mam. Zdobyłam doświadczenie jako Tester, zaczęłam interesować się zarządzaniem w metodykach zwinnych – musiałam się bardzo dużo nauczyć w tym temacie i dopiero dzięki dużej ilości nauki, dzięki próbom i błędom, jestem teraz tutaj, gdzie jestem – i nadal się rozwijam!
Skoro już jesteś tym Scrum Masterem, to możesz nam opisać czym jest Scrum?
Scrum to jest framework, czyli ramy postępowania, ramy procesu, które ułatwiają nam wytwarzanie produktów w środowisku niestabilnej złożoności – może powiem na przykładzie. 😉
Możemy produkować produkty złożone albo trudne, skomplikowane, takie jak budowa mostu. Budowa mostu natomiast nie jest taka złożona, bo wiemy od początku jakie jest założenie, co chcemy osiągnąć, i ogólnie możemy z dużą dozą pewności przewidywać, jak nasz produkt będzie odebrany przez klienta. Jak klient sobie zamówił most, to raczej chce otrzymać most i nie powie nam później, że “Ej, bo ja tu chciałem most kolejowy, a wy mi tu zrobiliście czteropasmówkę, autostradę”. Nie będziemy musieli tego mostu w połowie pracy burzyć i budować go na nowo.
Natomiast w wytwarzaniu oprogramowania bardzo często nie wiemy, czego tak naprawdę chce klient, albo nie wiemy, czy nasze założenia, że rozwój produktu przyniesie wartość i będzie dobrze odbierany przez klienta, są prawidłowe. Dowiemy się dopiero wtedy, kiedy to wytworzymy, wydamy i sprawdzimy reakcje użytkowników – to jest ta złożona niepewność. I wtedy Scrum bardzo dobrze się sprawdza. 😉
Powiedziałaś, że w tych warunkach Scrum się sprawdza. A w których warunkach Scrum się nie sprawdzi?
Na przykład przy budowie mostu. Nie ma sensu go wtedy używać. Jeżeli założymy, że produkt przyniesie jakąś wartość, a się to nie sprawdzi, to musimy w miarę niskim kosztem się z tego wycofać – więc mostu, który jest w połowie wybudowany, nie będziemy burzyć. W tworzeniu oprogramowania mamy system kontroli wersji, produkujemy w Scrumie w cyklach – czyli w sprintach (ale o tym pewnie później powiemy), więc po maksymalnie miesiącu pracy możemy się z jakiegoś założenia wycofać i to nas nie będzie strasznie dużo kosztowało.
Nie powinniśmy stosować Scruma w miejscu, gdzie nie ma zaufania czy otwartości na eksperymentowanie, sprawdzanie i popełnianie błędów. Każde założenie, gdzie nie mamy 100% pewności, że coś się sprawdzi, to jest jakiś eksperyment, który może pokazać nam, że to założenie nie miało sensu i trzeba od tego odstąpić. Jeśli w organizacji nie ma otwartości na takie podejście, to ciężko będzie wprowadzić Scruma.
Jakie warunki muszą być spełnione, żeby można było pracować w Scrumie?
Organizacja powinna być gotowa na zmiany, ponieważ takie przejście na zwinność, na Agile, to jest duża zmiana. Tutaj trzeba zaufać zespołowi, Product Ownerowi – po prostu pozwolić im działać i sprawdzić, czy to faktycznie przynosi wartość.
W idealnej sytuacji byłoby dobrze, gdyby organizacja była otwarta na tę zmianę bardzo szeroko – żeby to nie był jeden dział, który przechodzi transformację i zaczyna pracować zwinnie, Scrumowo; tylko żeby całość organizacji te zmiany przechodziła i aby więcej działów, które są ze sobą powiązane, jednocześnie przechodziły na pracę zwinną. Ale tak jak mówię – nie zawsze w praktyce jest to możliwe.
Scrum nie ma sensu też w zespołach supportowych, gdzie wpadają supporty i jest mniej planowania niż wrzutów, które wpadają w trakcie Sprintu. Nie ma sensu planować, jak i tak wiemy, że będziemy mieli supporty i trzeba będzie się tym zająć. Wtedy może być lepsza inna metoda, też zwinna, np. Kanban, ale niekoniecznie Scrum. Tam, gdzie nie możemy nic zaplanować, nie mamy długiej wizji produktu, tylko pracujemy ad hoc z jakimiś wrzutami, Scrum nie będzie miał zastosowania.
Wspomniałaś o Agile’u. Wcześniej nic o tym nie mówiłaś, więc mogłabyś wytłumaczyć czym jest Agile, a czym Scrum? Jak to się ma do siebie?
Oczywiście. Scrum to framework, czyli ramy postępowania, których używamy w zwinnym podejściu do wytwarzania oprogramowania. Wytwarzając oprogramowanie powinniśmy być gotowi na to, że:
- po pierwsze – w międzyczasie klient może zmienić zdanie;
- po drugie – po zobaczeniu jakiejś części naszej pracy klient może stwierdzić, że nie o to mu chodziło;
- po trzecie – może zmienić się sytuacja na rynku, np. konkurencja może wprowadzić coś podobnego, a my będziemy musieli wtedy pójść w innym kierunku.
W klasycznym, kaskadowym zarządzaniu mamy następujące po sobie fazy. Należą do nich: planowanie, implementowanie, testowanie, itd. – i dopiero wychodzimy już z całym gotowym produktem na rynek. To może trwać bardzo długo. W podejściu zwinnym, Agile’owym, robimy cykle, w których wytwarzamy przyrosty i każdy taki przyrost poddajemy inspekcji, która mówi nam jak na to zareaguje klient i rynek oraz sprawdzamy, co się w międzyczasie wydarzyło – jak się zmieniło nasze środowisko, co robi konkurencja, czy nadal powinniśmy iść w tym kierunku. Reagujemy zwinnie na wszelkie zmiany, które są w środowisku, wewnątrz i na zewnątrz organizacji.
Jaka jest Twoja rola jako Scrum Masterki?
Scrum Master pracuje na trzech poziomach: z organizacją, z zespołem Scrumowym, czyli deweloperskim, i z Product Ownerem. Na każdym z tych poziomów musi się wykazać trochę innymi umiejętnościami i ma inne zadania do wykonania.
Pracując z organizacją, zapewnia warunki dla zespołu Scrumowego do pracy w Scrumie. Pracując z Product Ownerem, dba o to, żeby backlog produktu był przejrzysty i zrozumiały dla zespołu deweloperskiego – żeby było wspólne zrozumienie tego, co trzeba zrobić i jak to się przekłada na wzrost wartości produktu, ponieważ Product Owner zapewnia maksymalną wartość produktu, który jest wytwarzany przez zespół Scrumowy.
Scrum Master oczywiście pracuje też z zespołem, usuwając przeszkody, które może zespół napotkać podczas pracy w Sprincie. Te przeszkody mogą zostać usunięte fizycznie poprzez deweloperów lub przez kogoś z zewnątrz teamu; natomiast Scrum Master odpowiada za to, aby dopilnować tego, żeby te przeszkody zostały usunięte.
Padło tutaj wiele dziwnych i trudnych słów, takich jak backlog, produkt, Product Owner. Czy mogłabyś je wyjaśnić?
W Scrumie, który – jak wspominałam – jest frameworkiem, mamy wymienione trzy filary: transparencję, inspekcję i adaptację. W Scrumie znajduje się Scrum Master, zespół deweloperski i Product Owner. Scrum Master, tak jak już wspomniałam, odpowiada za to, żeby Scrum miał miejsce. Product Owner odpowiada za maksymalizowanie wartości produktu; innymi słowy, Product Owner wie najlepiej co powinien ten produkt zawierać i czego chce klient, a czasem Product Owner wie to nawet lepiej od klienta. 😀 Zespół deweloperski to zespół, który wytwarza przyrosty tego produktu.
Są też wydarzenia w Scrumie. Każde wydarzenie w Scrumie ma jakiś swój sens – i będę do tego nawiązywać. Pierwszym wydarzeniem w Scrumie jest Sprint i może on trwać od jednego do czterech tygodni. W Sprincie wytwarzamy przyrost produktu. Wydarzeniem jest Daily Scrum – to codzienne piętnastominutowe spotkanie zespołu deweloperskiego, gdzie zachodzi inspekcja i ewentualnie adaptacja procesu; zespół sprawdza, czy to, do czego się wszyscy zobowiązali wcześniej, zostało wykonane bądź czy napotkane zostały jakieś przeszkody. Jeśli przeszkody zostały napotkane, to szybko należy wprowadzić adaptację.
Jest też Sprint Planning, czyli spotkanie, które może trwać maksymalnie osiem godzin i na którym Product Owner wraz z zespołem decyduje, co zostanie wzięte do Sprintu i nad czym zespół będzie pracował w ramach Sprint backlogu. Z mojego doświadczenia wiem, że to spotkanie bardzo rzadko trwa aż osiem godzin, ale maksymalnie może tyle trwać (Nikodem: Z mojego też 😀).
Następnym wydarzeniem jest Review, czyli przegląd Sprintu. Review jest kolejną okazją do inspekcji i adaptacji. Na Review zaproszeni są interesariusze, Product Owner i deweloperzy. Inspekcja polega na tym, że pokazujemy co zostało wytworzone i otrzymujemy feedback, czyli informację zwrotną. Możemy też od razu wprowadzić adaptację, bo na podstawie tych feedbacków wszyscy obecni na Review mogą zastanowić się czy jest sens iść dalej w tym kierunku, bądź czy nie należy zmienić czegoś w naszym założeniu jak rozwijać dalej produkt i jakie czynić następne kroki w rozwijaniu tego produktu. Na przeglądzie Sprintu każdy uczestnik może wypowiedzieć się na temat przyrostu i przekazać informację zwrotną.
Kolejnym wydarzeniem jest retrospektywa. Retrospektywa jest okazją do inspekcji Sprintu pod kątem tego, jak nam poszło z użyciem narzędzi, komunikacją, procesem. Na retrospektywie wybieramy co możemy ulepszyć w naszym procesie, naszej pracy, i adaptujemy to w następnym Sprincie.
W Scrumie mamy trzy artefakty: Sprint backlog, product backlog i przyrost. Product backlog to uporządkowana lista rzeczy do zrobienia w celu wytworzenia naszego produktu. Ta lista może się zmieniać, ponieważ wraz z postępem pracy Product Owner ma więcej więcej wiedzy, informacji zwrotnych od klienta. Obserwuje też rynek, więc może wprowadzać nowe zadania do product backlogu, bądź je usuwać – ta lista żyje. Sprint backlog to lista zadań, które zespół zobowiązuje się wykonać w Sprincie. To taka umowa, która powstaje na Sprint Planningu między Product Ownerem i zespołem, a zespół mówi, że w celu osiągnięcia celu Sprintu, mogą zrobić te i te zadania.
Kwestia jest taka, że błędy są nieuniknione w naszej pracy i myślę, że i najlepszym się zdarzają. Często przychodzi tak, że faktycznie ten błąd był na tyle istotny i poważny, że należy go naprawić jak najszybciej – wtedy w pewien sposób zaburzamy ten backlog.
Jest taka praktyka, żeby na Sprint Planningu zostawić 20% czasu w Sprincie na różne nieprzewidziane rzeczy, czyli np. bugi, które trzeba rozwiązać jak najszybciej. My jednak pracujemy w organizacjach, gdzie mamy różne spotkania obowiązkowe w organizacji, więc jeżeli nagle CIO zechce się spotkać z całym zespołem i zabierze nam dwie godziny czasu w Sprincie, to trzeba pójść na to spotkanie i trzeba to uwzględnić. Nie jest to nigdzie zapisane w żadnym Scrum Guide’dzie czy w zasadach, ale praktyka i zdrowy rozsądek podpowiadają, żeby sobie na Planningu zaplanować jakieś 20% czasu na różne nieprzewidziane rzeczy, nawet na brak prądu w domu.
Trzecim artefaktem Scruma jest przyrost. To praca, która spełnia definicję ukończenia i jest gotowa na koniec Sprintu.
Bardzo lubię pracować w Scrumie i się rozwijać, ale myślę, że w Twoim doświadczeniu trafili się tacy programiści, którzy nie przepadają za Scrumem. Byli tacy?
A byli tacy.
Jak współpracować z takimi członkami zespołu, którzy nie chcą pracować w Scrumie?
Ja osobiście nie jestem ewangelistką Scruma i nie mam zamiaru nikogo zmuszać do Scruma. Dla mnie najważniejsze jest to, żeby nie psuł pracy innym i żeby nie psuł pracy zespołowej. Z mojego doświadczenia wynika, że bardzo często deweloperzy są źle nastawieni na Scrum, przez to, że widzą w Scrumie tylko te spotkania, wydarzenia, a nie widzą wartości, które idą za tymi wydarzeniami i za Scrumem. Na pewno trzeba wytłumaczyć, że nie chodzi tylko o te spotkania, a o wartość wyniesioną z całego frameworku – to jest zadanie Scrum Mastera, żeby tłumaczyć deweloperom jaka jest prawdziwa wartość Scruma. 😉
A jak już wszyscy zrozumieją to można zwolnić Scrum Mastera? 😀
A to jest bardzo dobre pytanie! Kiedyś słyszałam taką opinię, że dobry Scrum Master doprowadza zespół do tego, że jest już w nim niepotrzebny i można go zwolnić czy może sobie pójść do innego projektu. W teorii pewnie jest to możliwe, ale w praktyce nie znam zespołu, w którym dałoby się coś takiego osiągnąć. Jest bardzo duża rotacja – przychodzą nowe osoby do zespołu, odchodzą osoby z zespołu – i jest też dużo zmian w środowisku, w którym pracuje taki zespół, więc Scrum Master zawsze będzie miał jakąś pracę; albo z organizacją, albo z Product Ownerem, albo z zespołem.
A zakładając, że zespół się nie zmienia i osoby, które są zainteresowane całym projektem będą niezmienne? Myślisz, że to by było realne?
Wtedy interesariusze też musieliby się nie zmieniać, środowisko musiałoby się nie zmieniać. Wyobraź sobie, że mamy przegląd Sprintu, na który powinni przychodzić interesariusze. Jeśli interesariusze się zmienili i teraz nie chcą przychodzić na przegląd Sprintu, albo są w innej strefie czasowej i zrobienie przeglądu jest skomplikowane – to też jest zadanie dla Scrum Mastera, żeby to wszystko zorganizować. Rzeczywiście musiałby się nie zmieniać ani skład zespołu, ani Product Owner, ani interesariusze, żeby Scrum Master mógł doprowadzić taki zespół do idealnego stanu i sobie pójść.
Jaka jest, Twoim zdaniem, najlepsza zaleta Scruma?
Możemy sprawdzić jakieś założenie, zrobić eksperyment, i jeśli się okaże, że nasze założenie było błędne, to po prostu można od tego odejść niskim kosztem. Zespół może się wykazać kreatywnością, sprawdzić coś, mieć pomysł, spróbować coś – i nic strasznego się nie stanie jeśli okaże się, że ten pomysł nie był najlepiej odebrany przez użytkowników. Robimy małe przyrosty; nie dajemy od razu dużego produktu, który tworzyliśmy przez rok, tylko mały przyrost po miesiącu, tygodniu, czy dwóch tygodniach pracy.
Zastanawiam się, jaka jest dla mnie największa zaleta Scruma. W sumie fajne jest to, że można, tak jak mówisz, eksperymentować. My chyba dość często eksperymentujemy. Jeżeli jest jakiś pomysł – wdrażamy go. Zakładamy sobie, że będziemy to robić przez dwa Sprinty i jak nam się spodoba to adaptujemy dany pomysł, a jeżeli nie to od niego odchodzimy. To jest fajne, chociaż też bardzo mi się podoba, że mamy określone, jaka praca powinna zostać wykonana w okresie dwóch tygodni. To jest całkiem przyjemne, bo przychodzę codziennie do pracy i wiem, co mam zrobić, na czym się skupić, wiem, do kiedy powinienem się wyrobić. Nie rozciąga mi się to ani powyżej, ani nie skraca się za bardzo… to ostanie zdanie bym wyciął, ale co tam! Jakie najtrudniejsze wyzwania spotkałaś w swojej karierze Scrum Masterki?
Hmm… tych wyzwań jest dużo. Myślę, że dotychczas największym wyzwaniem było… albo jest, bo w sumie ciągle pracuję z tym zespołem. Jest taki zespół, gdzie mamy deweloperów z różnych krajów z czterech albo pięciu stref czasowych, więc trzeba zarówno dograć spotkania tak, żeby wszystkim pasowały, ale też są różnice kulturowe, więc ciężko zbudować zaufanie, które jest tak ważne, ciężko o transparencję. Jak przyszłam do tego zespołu to był to nowopowstały zespół złożony z ludzi zupełnie przypadkowo ze sobą połączonych – oni się wcześniej nie znali, nie pracowali wcześniej ze sobą, nigdy się nie widzieli i pracują w różnych zakątkach świata. Przez pierwszy miesiąc ten zespół na żadnym spotkaniu się nie odzywał, póki nie przyszłam. Ja to sprawdzałam – np. spóźniałam się specjalnie 10 minut i była taka cisza. Oni nie zaczynali w ogóle spotkania póki nie przyszłam, tak jakby te spotknia były dla mnie. To było naprawdę trudne. Dochodziła do tego pewna bariera językowa, bo każdy po angielsku rozmawia, ale nie był to język na poziomie native u żadnej osoby z tego zespołu. Uważam, że zrobiliśmy bardzo duże postępy, bo już po kilku miesiącach zespół nawiązuje ze sobą więcej interakcji, kontaktów – nie czekają na mnie z rozpoczęciem spotkania. 😉 Są na pewno dużo bardziej samozorganizowani i samodzielni, ale jest to wyzwanie, żeby taki rozproszony zespół, z kilku krajów na świecie, ze sobą połączyć.
A jak pracuje Ci się z ludźmi, którzy twierdzą, że znają Scruma, a go tak naprawdę nie znają?
Oj, takich ludzi jest bardzo dużo. Zresztą, ja sama zostając Scrum Masterem, myślałam, że wiem bardzo dużo o Scrumie, a okazało się – teraz widzę to z perspektywy czasu – że wcale tak dużo nie wiedziałam. Teraz jeżeli zaczynam pracę z zespołem to zawsze pytam “Jakie jest twoje doświadczenie i wiedza w Scrumie? Oceń to od 1 do 10.”. Bardzo dużo deweloperów zaznacza dziewiątkę, gdzie ja sama bym w tej chwili nie zaznaczyła dziewiątki na tej skali. To jest dla mnie taka lampka ostrzegawcza – często taka osoba, która oceniła siebie bardzo wysoko, później wcale nie pokazuje tego w praktyce. To jest w sumie też wyzwanie, bo jak tutaj wytłumaczyć osobie, która uważa, że bardzo dobrze zna Scruma to, że tak naprawdę, w praktyce, nie pokazuje tej znajomości i wiedzy?
Czy nie dałabyś sobie dziewiątki dlatego, że dałabyś sobie dziesiątkę? 😀
Och! Nie. 😀 Nie dałabym sobie dziewiątki, bo na tym etapie, na którym jestem, już wiem ile nie wiem. W pracy Scrum Mastera – tak, jak w pracy dewelopera – trzeba się ciągle rozwijać. Bardzo dużo jest jeszcze momentów, których ja się muszę nauczyć lub których czasem nie da się nauczyć z książek czy też oglądając podcasty. 😀 Ze Scrum Guide’a też nie da się wszystkiego nauczyć – uczysz się tego na żywym materiale, po prostu pracując z zespołem. Tak naprawdę bardzo dużo wiedzy przychodzi z doświadczeniem. Zresztą, Scrum jest procesem opartym na empiryzmie, a empiryzm mówi, że możemy podejmować decyzje i możemy być pewni czegoś dopiero wtedy, gdy tego doświadczymy – więc ja muszę doświadczać tego Scruma, pracować z zespołami i wtedy będę wiedziała więcej, będę mogła podejmować lepsze decyzje.
Pracujesz tylko z jednym zespołem czy z kilkoma?
Mam w tej chwili dwa zespoły.
I jak wygląda Twoja codzienna praca?
Wstaję rano, zaczynam pracę, piję kawę, idę na meetingi, piję kawę, idę na meetingi… i tak na okrągło. Nie, żartuję. 😀 (Nikodem: Ja bym jeszcze kanapki gdzieś w międzyczasie wrzucił 😀). Tak naprawdę, bardzo ciężko mi jest przewidzieć moją pracę. Każdy dzień wygląda trochę inaczej. Jak już wspominałam, Scrum Master pracuje i z organizacją i z zespołem, z Product Ownerem, więc codziennie może pojawić się jakiś temat, w którym Scrum Master powinien pomóc czy to Product Ownerowi, czy to porozmawiać z kimś z organizacji, czy też pomóc zespołowi z usunięciem jakiejś przeszkody.
Są jakieś stałe spotkania, na które Scrum Master uczęszcza, np. wydarzenia ze Scruma. To jest stałe w kalendarzu, natomiast bardzo dużo rzeczy jest nieprzewidywalnych. Do tego jeszcze oczywiście Scrum Master powinien pamiętać też o swoim rozwoju – dokształcać się, sprawdzać, eksperymentować.
Co sądzisz o estymowaniu historyjek?
Estymowanie historyjek jest bardzo pomocną praktyką dla Product Ownera. Dzięki temu, że są historyjki wyestymowane, Product Owner może zrobić jakąś prognozę i zapowiedzieć biznesowi czy coś może być dostarczone w tym czasie, czy nie. Natomiast w tej chwili z moimi zespołami nie estymujemy w story pointach tylko w t-shirtach – estymujemy czy historyjka jest dużą koszulką, średnią koszulką, lub małą koszulką. Dlaczego? Bo Product Ownerka powiedziała, że w tej chwili nie ma takiej potrzeby, żeby robić dokładne prognozy i chciałaby wiedzieć tylko w bardzo dużym przybliżeniu ile zespół mógłby wziąć w danym Sprincie.
A jakie są jeszcze inne sposoby na estymację?
Jest podejście “no estimate” (Nikodem: O, fantastyczne! 😀), koszulki – cokolwiek, co sobie wymyślicie, czyli na przykład… (Nikodem: Buty, kapelusze!) buty i kapelusze. 😀 Albo oczywiście story pointy Fibonacci’ego. Natomiast Scrum tak naprawdę nie nakazuje estymować – nigdzie w Scrum Guide’dzie nie jest powiedziane, że zespół musi estymować. To jest praktyka, która ma pomagać, ale trzeba uważać, żeby w pewnym momencie nie przeszkadzała – żebyśmy nie estymowali dla estymowania. Jest jeszcze taka pułapka, że na przykład, jeżeli Scrum Master skupia się tak strasznie na velocity, to zespół robi wszystko, żeby to velocity wyglądało dobrze – i to nie ma żadnego sensu. Te praktyki mają być pomocne, ale jeśli dochodzi w pewnym momencie do tego, że przeszkadzają zespołowi, to nie tędy droga.
No ja z doświadczenia zauważyłem, że w jednych przypadkach może to być bardzo przeszkadzające – tak jak wspomniałaś, na przykład te estymaty miały się nijak do siebie, wyestymowana historyjka odbiegała bardzo od tego, ile pracy ona wymagała, ale z drugiej strony bardzo często pomagają zespołowi zrozumieć, co tak naprawdę jest do zrobienia. Czasami podczas estymacji, bądź próby estymacji, dochodziło do bardzo dużej rozbieżności, gdzie jedni członkowie zespołu twierdzili, że to będzie coś superprostego, a inni, że supertrudnego. To zależało właśnie czasami od zrozumienia samej historyjki, bo powiedzmy, że ktoś źle zrozumiał; a czasami mogło też zależeć np. od technologii, bo było tak, że dla jednego dana technologia jest superprosta, a dla innej osoby supertrudna – od razu wiemy komu przypisujemy “dziękuję, do widzenia”. 😉
To jest bardzo dobra obserwacja! Chociaż w moim zespole Product Ownerka powiedziała, że nie potrzebuje robić tych prognoz i de facto nie potrzebuje w tej chwili estymat, my jednak robimy te estymaty w koszulkach, bo dzięki temu – tak, jak powiedziałeś – zespół się zastanawia ile to zajmie czasu, zadaje dobre pytania i, na przykład, tester z deweloperem dochodzą do wniosku, że tutaj jest jakieś ukryte ryzyko albo będzie jakaś trudność, o której nie pomyśleli od razu – i na przykład myślą od razu, że to jest mała koszulka, a po dyskusji okazuje się, że jednak średnia. Wtedy mają większą wiedzę o tym, co należy tak naprawdę w tej historyjce zrobić.
Jak z Twojego doświadczenia wyglądają estymacje w nowym zespole?
Pierwsze estymaty w nowym zespole to są zupełne strzały. Estymaty mają sens jeśli biorą się z naszego doświadczenia, czyli porównujemy, więc w pierwszych Sprintach nie mamy do czego porównać i one będą zawsze bardzo dużym strzałem – i do tego trzeba być przygotowanym. Dopiero po kilku Sprintach estymaty zaczynają mieć sens, bo porównujecie historyjki, które są do zrobienia, do tych, które zrobiliście – do ilości pracy, którą wcześniej wykonaliście teraz możecie zrobić prognozy ile pracy trzeba będzie włożyć w nową historyjkę.
Pracowałem jako programista w Scrumie przez dosyć długi czas i znałem Scruma tak od strony programisty, ale bardzo się cieszę, że zgodziłaś się nas odwiedzić i opowiedzieć o tym, jak to wygląda z Twojej perspektywy. Sporo nam wyjaśniłaś, opowiedziałaś o niektórych definicjach, o swoich ciekawych przykładach, także bardzo Ci dziękujemy! Mam nadzieję, że naszym widzom materiał się spodoba. Zachęcam do subskrypcji, lajków, zadawania pytań w komentarzach i żegnam! 😉
Ja też bardzo dziękuję za zaproszenie. 🙂
______________________________________________________________
Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉
💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK
🌏 Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox
Obserwuj nas na social media:
🚀 LinkedIn: https://bit.ly/3PxlHFQ
🎧 Spotify: https://spoti.fi/39xU0fm
🎧 iTunes: https://apple.co/3PsjhrQ
