Jak przebiega proces Scrum?

Tyle mówimy i piszemy o samym Scrumie, ale jakoś do tej pory nie opowiedzieliśmy o tym, jak przebiega proces Scrum. Co się dzieje od samego początku, do samego końca oraz, przede wszystkim, gdzie zacząć?

 

Czym jest Scrum?

Jeżeli chodzi o czysto teoretyczny aspekt tego czym jest Scrum, to polecam nasz nieco już wiekowy film na YouTube. Niedługo pewnie nagramy go od nowa, bo w międzyczasie wymieniliśmy prawie wszystkie komponenty naszego przenośnego studia. Ale niezależnie od aspektów technicznych, w tym klipie tłumaczymy w kilku zdaniach czym jest bohater dzisiejszego tekstu, czyli Scrum.

Mówiąc o Scrumie często używamy słowa “metodyka“. Czasami nazywamy go “iteracyjnym i przyrostowym sposobem pracy”, co też uzasadnialiśmy w tekście opisującym oba te aspekty. W skrócie: prace przebiegają w iteracjach (Sprintach), ale rezultat naszej pracy (Przyrost) powstaje przyrostowo.

Kolejną cechą Scruma, która będzie nam dzisiaj nieco przeszkadzać, jest jego cykliczność. Nie ma on ani początku, ani końca. Proces scrumowy jest co prawda ujarzmiony w Sprintach, ale nie mamy tutaj żadnych etapów przygotowawczych, ani żadnego podsumowania. Startujemy niejako ze środka i kręcimy się w kolejnych iteracjach.

Gdzieś w okolicach egzaminów na certyfikaty Scrum pojawia się stwierdzenie, że aby zacząć pracę potrzebujemy jedynie Product Ownera z pomysłami do realizacji, Zespół Deweloperski gotowy te pomysły zrealizować oraz Scrum Mastera znającego Scrum i potrafiącego wesprzeć zespół. Tylko tyle i aż tyle.

Ale skoro pracujemy cyklicznie, to wciąż brakuje nam jakiegoś punktu zaczepienia albo momentu startu.

 

Od czego zacząć działać w Scrum?

Zawsze kiedy mam opowiedzieć o tym jak przebiega proces Scrum, to zaczynam od backlogu. A konkretniej od Backlogu Produktu i Product Ownera. Jak już powiedzieliśmy, musimy mieć osobę posiadającą wizję “czegoś” do realizacji oraz wymagania na to “coś”, zebrane w jednym miejscu. W Backlogu Produktu chcemy zmieścić wszystko – od bliskich planów, przez błędy do poprawy, aż do marzeń i koncepcji.

Idealnie byłoby, gdyby te wymagania były uporządkowane od najważniejszych (które będą realizowane niebawem) do tych najmniej ważnych (którymi zajmiemy się “kiedyś”). Te pierwsze zwykle będą też dużo drobniejsze i bardziej szczegółowo opisane, bo Zespół Deweloperski będzie realizował je w najbliższym Sprincie.

Mamy więc jedną osobę z wymaganiami oraz grupę od trzech do dziewięciu (“około pięciu”) profesjonalistów w Zespole Deweloperskim. Dodajmy do tego jeszcze Scrum Mastera, którego odpowiedzialności nie sposób zmieścić w tym krótkim tekście, a w rezultacie dostaniemy cały Scrum Team.

To jest dla nas punkt wyjścia, dzięki któremu możemy wejść w iteracyjny proces Scrum. A to znaczy, że wszystko co teraz będziemy omawiać dzieje się cyklicznie, Sprint po Sprincie.

 

Jak rozpoczyna się proces Scrum?

Sprint (“ograniczenie czasowe trwające miesiąc bądź krócej”) zaczyna się Planowaniem Sprintu, które to wydarzenie ma dwie części – pierwszą i drugą.

W pierwszej Zespół Deweloperski decyduje o tym, co będzie realizował w najbliższej iteracji. Oczywiście, nie wybiera wymagań jak im się podoba, ale idzie od góry Product Backlogu i bierze tyle, ile wydaje im się, że dadzą radę zrealizować. Te wybrane wrzuca do artefaktu zwanego Sprint Backlog.

Oczywiście na tym etapie mogą pojawić się negocjacje z PO, bo nie zawsze kolejność w backlogu jest rozsądna i optymalna. A skoro będziemy dyskutować, to przy tej okazji warto też ustalić po co właściwie to wszystko robimy, czyli Cel Sprintu.

Product Owner przyda się także w drugiej części planowania, gdzie zespół będzie opracowywał zgrubny sposób realizacji wymagań wybranych w części pierwszej. Te szczegóły (plan realizacji) również trafiają do Sprint Backlogu.

Planowanie kończy się, gdy wszyscy wiedzą za co się zabrać i są w stanie opowiedzieć jak będą realizować Cel Sprintu lub gdy upłynie timebox.

Reszta czasu przeznaczonego na Sprint przebiega na realizowaniu planu zapisanego w Sprint Backlogu, czyli na budowie Przyrostu. Szczególnym kwadransem każdego dnia jest Daily Scrum, na którym Zespół Deweloperski synchronizuje i planuje następne dwadzieścia cztery godziny. Tak działamy do momentu, aż dotrzemy do dwóch ostatnich wydarzeń.

Diagram pokazujący proces Scrum.

 

Każdy koniec to początek

Każdy Sprint kończy się dwoma wydarzeniami, na których mówimy o zupełnie różnych rzeczach. To trudne, bo ludzie mają tendencje do poruszania wszystkiego, co ich zdaniem jest ważne, ale dobry Scrum Master zadba o osiąganie konkretnych celów poszczególnych wydarzeń.

Na Sprint Review zapraszamy interesariuszy i oglądamy to, co powstało (Przyrost) oraz Product Backlog. Naszym celem jest ustalenie strategii na kolejne Sprinty, zaktualizowanie priorytetów i porozmawianie o tym, co się zmieniło w ostatnim czasie. Warto też pokazać/obejrzeć nasz produkt i usłyszeć tradycyjne “ojej, ale nie o to nam chodziło”.

Z kolei na Sprint Retrospective (już bez interesariuszy) mówimy o ludziach, procesach, relacjach, narzędziach oraz Definition of Done. Tu właśnie tuningujemy nasz proces Scrumowy, czyli usprawniamy to, jak pracujemy w Sprintach. Identyfikujemy sukcesy i porażki oraz przygotowujemy usprawnienia, dzięki którym od następnej iteracji pracowało się nam będzie lepiej. A przynajmniej taką mamy nadzieję.

Gdy upłynie ostatnia sekunda Sprint Retrospective, ruszamy na planowanie kolejnego Sprintu. I tak działamy do momentu, w którym ktoś stwierdzi, że nie warto już tego dalej ciągnąć. Póki jest backlog, póty jest praca.

 

Czego nam jeszcze brakuje w procesie Scrum?

W tym całym opisie zabrakło jednej bardzo istotnej rzeczy, bez której cały proces Scrum legnie w gruzach. Bo nawet jeśli Product Owner będzie miał pomysły na pierwszy Sprint, to w którymś momencie backlog nam się po prostu skończy. A nawet jeśli nie, to zostaną tam same ogromne tematy i wymagania, o których nikt nic nie wie. A takich rzeczy nie zaplanujemy.

Na szczęście twórcy Scruma przewidzieli ten scenariusz i w ramach procesu scrumowego mamy coś, co nazywa się Product Backlog Refinement. Jest to proces ciągły polegający na dekompozycji, rozpoznawaniu, szacowaniu i dzieleniu wymagań już znajdujących się w Backlogu Produktu. Mówiąc inaczej, jest to przygotowanie wymagań do planowania. Żadna tam analiza, ani prototypowanie, tylko konkretnie – refinement.

Dzieje się on niejako w tle Sprintu i dotyczy grillowania przyszłych wymagań tak, abyśmy nigdy nie stanęli przed problemem “nie wiem co jest w backlogu i nie umiemy zaplanować następnej iteracji”. Doskonalenie Backlogu Produktu to temat rzeka. Poza podlinkowanym tekstem na blogu polecamy także poświęcony mu film z kategorii “Wszystko co chcielibyście wiedzieć o…

Dopiero teraz, uwzględniając “PBR”, możemy powiedzieć, że na bardzo ogólnym poziomie udało nam się omówić proces Scrum. Uffff!

Jeśli chcecie dowiedzieć się jeszcze więcej o niuansach naszej ulubionej metodyki, zapraszamy na nasz kanał na YouTube oraz na nasze szkolenia Scrum i Agile. Znajdziecie tam propozycje dla zespołów, Scrum Masterów, Product Ownerów, analityków i nie tylko. Z chęcią także przygotujemy indywidualny program spełniający Twoje oczekiwania.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Arek - 28 sierpnia 2020

Scrum jest dobry, jednak jego największym problemem jest temat rozliczania z klientem. Nie każda organizacja — firma jest na tyle dojrzała, by go stosować. Dla mniejszych lub bardziej oszczędnych firm tego typu podejście może wydawać się nieuczciwe w kwestii rozliczania.

Reply
    Damian - 10 września 2020

    Zgadza się, że nie jest tanie. Koszt to nawet około 30% ale nie można mówić tu o tym że jest nieuczciwy bo dlaczego? Nie oszukuje się nikogo w żaden sposób, a w ręcz odwrotnie nawet pomoże ograniczyć koszty klientowi bo co jak będziemy wytwarzać oprogramowanie 3 miesiące bez sprawdzania itp a na końcu się okaże, że to nie jest to co chcieliśmy? Kasa przepalona 🙂

    Reply
      Tomasz Dzierżek - 10 września 2020

      Z ciekawości i bez czepialstwa – skąd pochodzi te około 30% i w porównaniu do czego? Całkowita zgoda co do tego, że lepiej sprawdzać częściej i się zdziwić po dwóch tygodniach, a nie dwóch miesiącach.

      Reply
Leave a Reply: