W dzisiejszych projektach IT bardzo modne stało się pracowanie w metodologii Scrum. Jednak co tak naprawdę kryje się pod tym pojęciem? Jakie kroki trzeba podjąć, aby wdrożyć taki styl pracy? Na te pytania postaram się odpowiedzieć w tym artykule. Dodam jeszcze, że ten wpis jest poniekąd rozszerzeniem poprzedniej publikacji, która dotyczyła prowadzenia projektów.
Scrum to bardzo użyteczny framework, który ułatwia tworzenie nowych produktów czy usług. Podążając zgodnie z nim jesteśmy w stanie dostosować się błyskawicznie do nowych wymagań rynkowych. Sam Scrum jest tylko ideałem procesu, do którego dążymy. Jednak osiągnięcie pełnej zgodności z jego zasadami nigdy nie będzie możliwe z wielu różnych powodów. Zawsze będą istniały przyczyny zmuszające nas do nagięcia standardów metodologii. Powodem mogą być np. aspekty czysto biznesowe czy też spowodowane przez nagłe zmiany decyzji. Przejdźmy teraz do elementów, na które składa się Scrum.
Iteracyjny tryb pracy
Rozpoczniemy od wyjaśnienia czym jest iteracyjny tryb pracy. Proces wytwarzania produktu podzielony jest na sprinty, czyli krótkie iteracje trwające najczęściej 2 tygodnie. Na koniec każdego z nich dostarczane są klientowi działające funkcjonalności rozszerzające dany produkt. Dzięki podzieleniu okresu tworzenia produktu zyskujemy chwilę, aby zatrzymać się i zastanowić czy na pewno zmierzamy w dobrym kierunku. Nie będzie nam szkoda jeśli okaże się, że funkcjonalność, nad którą pracowaliśmy przez ostatni sprint jest zbędna i należy ją usunąć.
No dobra, będzie nam szkoda, ale na pewno mniej niż miałoby to miejsce w przypadku metodologii Waterfall. Tworząc produkt kaskadowo mogłoby się okazać na zakończenie projektu, że jest on do niczego nieprzydatny, nie spełnia obecnych wymagań rynkowych… 😥
Skrócona zasada działania Scrum’a
Planowanie sprintu
Każdy sprint poprzedzony jest spotkaniem zwanym planowaniem, podczas którego zespół wraz z przedstawicielem klienta (Product Ownerem) wybiera zadania jakie będą wykonywane w danej iteracji. W trakcie planowania dokonuje się estymacji każdego zadania, czyli ocenia się jego złożoność i przypisuje story points, które są niczym innym jak punktami określającymi jego kompleksowość. Te wartości są oparte o kolejne liczby ciągu Fibonacciego przez co zadanie może być ocenione na 1, 2, 3, 5, 8, 13, 21… punktów.
Jednak skąd zespół ma wiedzieć na ile może wycenić dane zadanie? Powinien po prostu oprzeć się na swojej wiedzy, którą zdobył podczas poprzednich sprintów np. istniał już podobny problem i wyceniono go na 5 punktów. A na jakiej podstawie zespół może określić ilość zadań, które jest w stanie wykonać w tej iteracji? Dokładnie ta sama odpowiedź, musi spojrzeć wstecz ile średnio punktów był w stanie wykonać w poprzednich sprintach. Następnie powinien dobierać zadania w taki sposób, aby zsumowane story points oscylowały w okolicach tej wartości.
Warto dodać, że istnieje duże prawdopodobieństwo (jak nie 99% 😂), że funkcjonalność, którą wykonaliśmy we wcześniejszym sprincie będzie zawierała błędy. Takie bugi także zostają włączane do sprintu. Jednak nie są one estymowane z racji tego, że zaliczają się jako część ukończonego wcześniej zadania.
No dobrze, rodzi się teraz pytanie skąd właściwie wiadomo jakie zadania są do wykonania? Tutaj z pomocą przychodzi nam Product Backlog, czyli miejsce gdzie znajdują się wszystkie zadania dotyczące produktu. To właśnie stąd klient wybiera wraz z zespołem jakie zadania powinny trafić do Sprint Backlogu. Najczęściej wciągane są te, które mają najwyższy priorytet. Należałoby jeszcze wyjaśnić jak dokładnie wygląda treść takiego zadania.
Zadanie, czyli user story
Product Backlog składa się z małych klocków zwanych user stories. To właśnie w nich zawarta jest informacja o funkcjonalnościach, które dają wartość klientowi. Przejdźmy zatem do wytłumaczenia co składa się na treść takiej historyjki. Są to odpowiedzi na pytania:
- komu dana funkcjonalność się przyda,
- co dokładnie robi ta funkcjonalność,
- z jakiego powodu należy ją wykonać, dlaczego jest użyteczna.
Jako przykład wyobraźmy sobie, że projektujemy oprogramowanie do rezerwacji miejsc w wybranym środku transportu. Przy zamawianiu biletu chcemy mieć możliwość wybrania miejsca w pierwszej klasie. W takim przypadku historyjka może brzmieć następująco: “Jako rezerwujący chcę mieć możliwość wyboru miejsca w pierwszej klasie, ponieważ cenię sobie wygodę”. W ten oto sposób dowiadujemy się co jest tak naprawdę celem funkcjonalności. Warto dodać, że w historyjce znajdują się także kryteria akceptacji, dzięki którym wiadomo czy historyjka została wykonana zgodnie z wymaganiami biznesowymi.
Po wyjaśnieniu czym dokładnie jest user story możemy w końcu przejść do zagadnień związanych z ceremoniami po uruchomieniu sprintu.
Daily - codzienna ceremonia
Każdego dnia, o ustalonej porannej godzinie, zespół spotyka się na daily podczas, którego każdy z członków przedstawia zwięźle trzy kwestie:
- co zrobił wczoraj,
- co planuje zrobić dzisiaj,
- czy nie ma żadnych blokad przeszkadzających w wykonaniu zadania.
Jest to bardzo ważny element w Scrumie, ponieważ raz w ciągu dnia cały zespół znajduje się w tym samym miejscu, aby obgadać najważniejsze sprawy w jak najkrótszym czasie. Ma to ogromną zaletę w postaci tego, że później programiści w znacznie mniejszym stopniu będą sobie przeszkadzać w pracy, ponieważ praktycznie wszystko mogą przedyskutować i wyjaśnić podczas daily. Oczywiście jeśli w ciągu dnia natrafimy na problem to nie czekamy do następnego ranka, aby go rozwiązać, tylko staramy się go przedyskutować z innym członkiem zespołu jeszcze tego samego dnia.
Cały sprint praktycznie jest taki sam. Wykonujemy swoją pracę uczestnicząc każdego dnia w daily. Na koniec iteracji musimy jakoś poinformować naszego klienta o sukcesach, z tego właśnie powodu postało review.
Pokażcie co macie
Cały przyrost jest prezentowany klientowi podczas ceremonii review. W trakcie tego spotkania każde z naszych zadań powinno zostać przedstawione. Omawiane są nie tylko zakończone funkcjonalności, ale także te bliskie ukończenia. W trakcie prezentacji może toczyć się dyskusja nad słusznością wykonania, a na koniec klient powinien dostarczyć nam obszerny feedback.
Następnie wykonane przez nas zadania są wdrażane jako nowe funkcjonalności produktu. Zamawiający dokonuje weryfikacji ich działania oraz zgodności z założeniami, czy nie trzeba czasem przeprowadzić jakiś poprawek, które spełnią tą ostateczną wizję produktu. Po review zespół spotka się, aby wspólnie podsumować bieżący sprint. Jednak nie jest to zwykła ewaluacja, tutaj każdy ma prawo głosu i może, a nawet powinien, ponarzekać 😈.
Czas na przemyślenia
Przychodzi taki czas na koniec sprintu, kiedy należy spojrzeć wstecz i zastanowić się nad tym co poszło źle. Każdy z członków zespołu ma prawo, aby powiedzieć z czego jest niezadowolony, co poszło doskonale oraz jakie czynności można wprowadzić, aby szybciej wyłapywać pomyłki i je naprawiać.
Ten właśnie moment nosi miano retrospektywy bądź też retro. W moim zespole podczas tej ceremonii wykorzystujemy tablicę, która podzielona jest na trzy części. Pierwszą z nich zajmują pozycje, które określają nasze sukcesy w danym sprincie np. “Komunikatywność zespołu na wysokim poziomie” albo “Szybkie przełączanie się pomiędzy zadaniami przez deweloperów”. Środek tablicy przeznaczony jest na rzeczy, które uznajemy za wymagające poprawy. Może to być np. “Słaba komunikacja na linii deweloperzy-klient” bądź też “Testy e2e ciągle się wywalają”. Ostatni fragment tablicy prezentuje akcje jakie należy podjąć w celu naprawy zaistniałych błędów, czyli np. “Przyjrzeć się kwestii wywalających testów” czy “Częstsze raportowanie statusów”.
Przykładowa tablica do retro znajdująca się na stronie funretro.io
Dzięki takiemu zestawieniu łatwiej jest zmotywować zespół do dalszej pracy. Każdy widzi dokładnie nad czym trzeba jeszcze popracować, aby sprawniej dostarczać wartość klientowi. Cała ceremonia powinna przebiegać w spokojnej atmosferze, aby nikt nie bał się wyrazić swojego zdania. Każdy powinien być wyrozumiały w stosunku do reszty zespołu i zachować pokorę.
Doskonalenie Product backlog’u
Czasem można spotkać się w sprincie z procesem polegającym na “pielęgnowaniu” Product Backlogu. W związku z tym, że nasz zbiór zadań ciągle żyje i nigdy nie jest kompletny musimy go nieustannie doskonalić. Zadaniem refinementu jest, więc ponowne ustalanie priorytetów historyjek oraz kolejności ich wykonania na podstawie zmieniających się wymagań. Dodatkowo zespół może zdobyć wiedzę na temat nowych user stories, aby wiedzieć na przyszłość “z czym się to je”. To jest tylko napomknienie o temacie w celu podkreślenia, że taka ceremonia także istnieje w Scrum.
Własne modyfikacje
Scrum jak wspomniałem na początku może być zmieniany w zależności od potrzeb. W moim zespole istnieje dodatkowo spotkanie zwane checkiem pod koniec każdego dnia. Jest to skrócona wersja daily polegająca na zwołaniu wszystkich członków zespołu w jedno miejsce i zapytanie czy nikt nie ma żadnych blockerów oraz czy nie potrzebuje pomocy. Zajmuje to dosłownie 5 minut a czasem potrafi zmienić priorytety w zespole!
Podsumowanie
Wyżej przedstawiony opis Scrum jest tylko czubkiem góry lodowej. W świecie IT istnieje nawet stanowisko Scrum Mastera co świadczy o złożoności tego zagadnienia. Także zachęcam do dalszego dokształcania się w tym temacie, chociaż taka wiedza jest już wystarczająca dla dewelopera.
Teraz czas na Ciebie, powiedz mi czy Twój zespół także przeprowadza każdą z ceremonii Scruma? A może ma jakieś swoje specjalne meetingi, które są specyficzne dla danego projektu? Podziel się swoją opinią w komentarzu albo napisz do mnie.