Jak często zdarzyło Ci się całkowicie zmieniać lub poprawiać koncepcję produktu, który tworzyłeś? Zmieniające się potrzeby to jeden z najpoważniejszych problemów przed którym stajemy my – zarządzający produktami. Może dałoby się nad tym jakoś zapanować?! Pracowanie „na Hurra!” raczej nam nie pomoże…

Aby wyjść na przeciw tym potrzebom, powstały tzw. metodyki zwinne (agile). Wśród nich prym aktualnie wiedzie Scrum (czyli po polsku „młyn”, figura tworzona przez zawodników rugby). Co to znaczy, że Scrum jest metodyką zwinną? Najlepiej zdefiniuje go chyba tzw. manifest agile:

Przyjrzyjmy się więc jak wygląda scrumowy proces wytwarzania oprogramowania w praktyce. Zacznijmy od tego, kto (jakie role) w nim występuje.

1. Role w Scrumie

Product Owner (właściciel produktu) – jest to osoba reprezentująca klienta/użytkownika, która zadba o jego cele biznesowe. Odbiorca produktu. Nadzoruje, czy zespół rozumie jak ma wyglądać produkt i czy dobrze zna potrzeby jego konsumentów.

Scrum Master (mistrz scruma) – człowiek odpowiedzialny za to by praca nad produktem przebiegała zgodnie z metodyką scrum, dlatego też przewodzi różnorakim spotkaniom scrumowym. Mistrz usuwa też przeszkody jakie napotyka na swojej drodze zespół. Jest takim buforem, sprawiającym że perturbacje ze świata zewnętrznego nie będą utrudniały pracy zespołu. Nie jest kierownikiem – nie przewodniczy zespołowi!

Scrum Team (zespół scrum) – samoorganizujący się zespół. Nie ma kierowników – na zasadzie współpracy i wzajemnych interakcji podejmuje decyzję. Podstawowym zadaniem zespołu jest oczywiście wytwarzanie produktu. Składa się zwykle z 5-9 osób. Członkowie grupy starają się być możliwie intedysplinarni.

2. Backlog

Na początku projektu najwięcej roboty ma Product Owner. Musi zdefiniować nasz produkt – to jak ma on wyglądać według klienta.

Dobrą praktyką (nie wchodzącą w zakres Scruma) jest zaczęcie od napisania scenariuszy użycia. Najlepiej stworzonych na podstawie rozmów z prawdziwymi beneficjentami produktu. Scenariusz użycia powinien być dłuższą historią tego jak użytkownik pracuje (z całym kontekstem tego użycia) w naszym systemie. Pisane są one oczywiście z punktu widzenia użytkownika. Taki scenariusz powinien mówić kto, jak, po co i gdzie użył naszego systemu.

👉 Więcej o scenariuszach i przykłady ich tworzenia

Styli pisania scenariuszy jest wiele. Można napisać kilka krótszych historyjek o każdym potencjalnym użytkowniku, można połączyć te opowieści w jedną dłuższą. Można, zamiast historyjek pisanych zrobić obrazkowe, czy nawet opisać je na podstawie prostych prototypów interfejsu produktu. Najważniejsze jest jednak to, by te historie były jak najbardziej szczegółowe, ponieważ stanowią one podstawę do identyfikacji tzw. cech produktu.

2.1. User Stories

I tutaj właśnie dochodzimy do kluczowego na początku projektu etapu – zdefiniowaniu cech produktu. Cechy produktu to funkcjonalne i pozafunkcjonalne własności produktu oczekiwane przez użytkownika końcowego.

Zapisuje się zazwyczaj w postaci User Stories. Są to jednozdaniowe oczekiwania względem produktu z punktu widzenia użytkowników.

Piszemy je w konwencji:

Dzięki temu możemy się ustrzec funkcjonalności, które nie będą służyć nikomu lub nie będą miały żadnego celu (puste, nic nieznaczące bajery).

Product Owner, posługując się scenariuszami użycia (jeśli takowe stworzył), na początku znajduje tylko główne, najważniejsze user stories. Następnie, opierając się na celach biznesowych, stara się te jednostki produktu priorytezować. Pamiętaj, że priorytety są nadawane z biznesowego punktu widzenia!

2.2. Estymacja

Gdy Product Owner zebrał już wszystkie jednostki produktu idzie z nimi do zespołu scrumowego. Zespół przegląda User stories i stara się je w jakiś sposób oszacować. W scrumie używa się często do tego Story Points. 

Z definicji Story Points mają określać rozmiar, wielkość poszczególnych jednostek produktu. Story Points NIE są estymacją czasową!

Cóż jednak kryje się pod tą mało jednoznaczną definicją? Najpopularniejsze chyba jest uważanie SP jako uniwersalnej miary wielkości danego zadania, która powinna być taka sama dla każdego zespołu.

Mówiąc jeszcze dokładniej i opierając się na praktycznym przykładzie. Mamy do pomalowania pokój. Każdy zespół powinien wielkość tego zadania ocenić podobnie (oczywiście zakładając że mają te same „dane wejściowe”) – w końcu każdy ma do pomalowania tak samo duże ściany, napotka te same problemy, zużyje podobną ilość farby. I taką oceną powinno być właśnie story points. Natomiast czas takiego malowania może być dla każdego zespołu inny. W końcu jedni mają większe doświadczenie, inni za to posiadają specjalistów od malowaniu dużych płaskich powierzchni itd. Więc estymacja czasowa dla każdego z zespołów może być różna!

Jest jednak jedna rzecz, która łączy wszystkie konwencje używania Story Points. Jest to ich relatywność. Zazwyczaj wybiera się najłatwiejsze zadanie i nadaje mu wartość 2. Resztę zadań szacuje się w sposób relatywny do tego zadania. Dlatego zadanie dwa razy większe od najłatwiejszego dostanie 4 punkty. Dlaczego jednak najprostsze zadanie ma 2 punkty, a nie 1? Ponieważ zawsze można coś przeoczyć i w trakcie szacowania okaże się, że znaleźliśmy zadanie jeszcze prostsze.

Warto jeszcze wspomnieć kilka słów o samej punktacji Story Points. Przede wszystkim jest ona zazwyczaj utrzymywana w skali M. Cohna, by nie tracić czasu nad mało istotnymi różnicami, np. zastanawianiem się czy zadnie jest warte 8, czy 9 punktów. Wynika to z faktu, że skala ta prezentuje się w sposób następujący:

Samo szacowanie można zorganizować na wiele sposób. Najczęściej robi się to w grze karcianej zwanej planning poker. Każdy z członków zespołu otrzymuje karty oznaczone punktacją w skali Cohna. Gdy estymujemy daną jednostkę produktu to każdy (jednocześnie – by inni nie sugerowali się naszym wyborem) wykłada na stół kartę z odpowiednią ilością punktów. Osoby, których punktacja w znaczący sposób różni się od reszty grupy starają się wytłumaczyć swoją decyzję. Następnie na zasadzie kompromisu wybierana jest jedno oszacowanie.

2.3. Tworzymy Product Backlog

User Stories z przypisanymi przez Product Ownera priorytetami oraz oszacowaniami w Story Points zespołu tworzy najważniejszy artefakt w Scrumie – Product Backlog (jednostki powinny być posortowane po priorytetach).

Ten artefakt jest podstawowym źródłem informacyjnym zarówno dla PO, jak i zespołu. PO dzięki estymacji SP jest w stanie określić rozmiar całego produktu, ile zostało już zrobione, ile przed nami. 

Aktualizując na bieżąco backlog (tak, Product Backlog nie jest sztywnym dokumentem, jest zmieniany na bieżąco) przedstawia zespołowi nowe zadania do wykonania oraz ich priorytet. Zmiany w tym artefakcie wprowadza także zespół – dopisując znalezione błędy, rozbijając zadania na mniejsze.

Ciągła praca nad doskonalniem backlogu nazywa się backlog refinementem.

To jak zmienia się stopień wykonania naszego produktu śledzimy w scrumie na wykresie zwanym burndown chart. Prezentuje on ilość pracy (w story pointsach) jaką jeszcze musimy wykonać po poszczególnych iteracjach.

Przykłady Burndown chart

3. Praca w Scrumie

Do tej pory dowiedziałeś się co robimy jeszcze przed tworzeniem samego produktu. Teraz poznasz już jak przebiega praca w scrumie – czyli to co tygryski lubią najbardziej 🙂

Proces Scrumowy składa się ze Sprintów, czyli tradycyjnie mówiąc – iteracji. Iteracja to ogólnie rzecz biorąc zestaw czynności, które są powtarzane co jakiś czas. Każdy Sprint w Scrumie rozpoczyna się od…

3.1. Sprint Planning Meeting

Sprint Planning Meeting to, przekładając na język polski, spotkanie planowania sprintu. Zbierają się na nim Product Owner i zespół uczestniczący w projekcie. Na podstawie priorytetów, rozmów pomiędzy PO i zespołem wybierane są jednostki produktu, które zostaną zaimplementowane w czasie planowanego sprintu. User stories nie są oczywiście dobierane przypadkowo. Na pierwszy ogień idą zawsze najpotrzebniejsze pod względem biznesowym jednostki. Dodatkowo zespół, bazując na swoim programistycznym doświadczeniu powinien potrafić wskazać, które jednostki są od siebie zależne i będzie konieczna ich implementacja mimo, iż mają niski priorytet dla klienta. Co więcej, wybrane jednostki powinny stanowić pewną logiczną całość.

Dochodzimy tu właśnie do istoty sprintu. Po każdym sprincie powinna być już gotowa jakaś część produktu, którą da się zaprezentować właścicielowi produktu. Musi to być jakiś podzbiór funkcjonalności widoczny dla użytkownika produktu. Dlatego na początku planowania warto, po uzgodnieniu z PO, wyznaczyć sobie cel iteracji. Dzięki temu łatwiej Ci będzie wybrać odpowiednie User Stories. Łatwiej też przyjdzie przekonać PO do wyboru jednostek z mniejszym priorytetem, gdy będą one konieczne do zrealizowania tego celu. Dlatego najważniejszymi z wybranych jednostek produktu nie mogą być np. projekt bazy danych i jego implementacja. To NIE jest działająca z punktu widzenia klienta część produktu. Dużo lepszym wyborem byłoby zadanie stworzenia panelu zarządzania profilem użytkownika na stronie WWW i „podpiąć pod to” zrobienie bazy danych użytkowników.

Po wyborze User Stories, zespół rozbija je (jeśli trzeba) na mniejsze podzadania i szacuje. Nie warto tworzyć zadań, których wykonanie zajmie np. 3 osobodni. Lepiej rozłożyć takie problemy na jeszcze mniejsze części składowe (oczywiście nic na siłę, czasem jest to niemożliwe lub po prostu bezsensowne).

Tak „przygotowane” zadania tworzą sprint backlog, czyli zestaw rzeczy które zaimplementujemy w danej iteracji. Sprint backlog służy tylko i wyłącznie zespołowi. Prowadzony jest przez zespół i tylko on może nim zarządzać.

Istnieją jeszcze bardziej rozbudowane koncepcje sprint backlogów. Często np. do poszczególnych zadań dopisuje się ich dłuższy opis, ryzyko wystąpienia problemów, DoD (Definition of Done – co sprawia że zadanie uznajemy za zakończone), wskazanie zależności pomiędzy zdaniami itp.

Na sprint planning meeting ustalany jest jeszcze czas trwania sprintu (a dokładniej data jego zakończenia). Nie powinien on być zbyt długi, zazwyczaj trwa dwa tygodnie. Dzięki tak krótkim iteracjom projekt staje się dużo bardziej dostosowany do zmieniających się wymagań. Jeśli użytkownikom nie spodoba się coś w wersji produktu po sprincie to stracimy tylko jakąś część czasu z 2 tygodni, a zmiany będą łatwe do przeprowadzenie. Przy tradycyjnych metodach musielibyśmy poprawiać coś co kodowaliśmy np. pół roku wcześniej. Każdy sprint powinien zawsze trwać tyle samo czasu np. dwa tygodnie. Pamiętaj! Przy dobrze zadań do aktualnego sprintu musisz dostosować ich ilość do czasu jego trwania (no i ilości osób w zespole). Pomogą Ci w tym Story Pointsy i estymacja czasowa.

3.2. Pracujemy!

Naplanowaliśmy się… czas w końcu popracować 🙂 Na Sprint Planning Meeting stworzyłeś kolejny artefakt – Sprint Backlog. Będzie on towarzyszem pracy każdego członka zespołu. Ale od początku.

Zespół w Scrumie pracuje i organizuje się tak jak tylko chce. Nie ma lidera, nie ma szefa zespołu. Istnieje jednak kilka reguł, których każdy musi przestrzegać i które egzekwowane są przez Scrum Mastera. Porządkują one pracę zespołu i ułatwiają, a wręcz trochę wymuszają współpracę.

Zadnia do wykonania nie są przez nikogo przydzielane. Każdy może wybrać sobie dowolne zadanie i je realizować. Musi to jednak zaznaczyć w sprint backlogu – przypisując zadanie do siebie. Wraz z postępowaniem prac wpisuje tam również ilość przepracowanych godzin. Czyli pracujemy według własnego uznania, jednak informując o tym innych. Uzupełnianie sprint backlogu umożliwia wygenerowanie wykresu spalania, czyli sprint burndown chart. Pokazuje on ile godzin już przepracowaliśmy w odniesieniu do estymowanych godzin jakie już powinniśmy „mieć wyrobione”. Jeśli jesteśmy ponad tą kreską – nie wyrabiamy się, pod – przeszacowaliśmy zadania (albo tak bardzo się sprężyliśmy :P).

Paca nad konkretnymi zadaniami zawiera w sobie analizę, projektowanie, implementację i testowanie. Dopiero gdy zostanie przetestowana (pozytywnie) część funkcjonalności to zadanie uznajemy za zakończone. Często też wykorzystuje się system inspekcji, w której inny programista sprawdza naszą pracę – jeśli nie wykryje błędów, zadnie można zamknąć. W przeciwnym wypadku idzie ono do poprawki.

W projektach agile stosuje się też zasadę, że kod ma swoje autorstwo, ale nie ma właściciela. Oznacza ona ni mniej, ni więcej, że każdy może edytować kod każdego członka zespołu – kod jest dla wszystkich wspólny. Aby praca przebiegała sprawnie stosuje się systemy kontroli wersji np. SVN, Git.

Częste zmiany kodu (zmieniają się przecież wymagania, my na nie reagujemy) i jego współautorstwo ma też swoje minusy. Kod z czasem staje się coraz mniej przejrzysty, coraz mniej „prosty”. Aby zapobiec tej degradacji jakości stosuje się refaktoryzację. Gdy tylko kod staje się trudny w czytaniu następuje jego refaktoryzacja, czyli przepisanie w taki sposób by na powrót stał się prosty. Takie zmiany zajmują trochę czasu, ale w dłuższej perspektywie dają ogromne profity.

Dokumentacje robimy tylko w podstawowym zakresie – spisujemy rzeczy najbardziej potrzebne. Cała wiedza „krąży” w zespole przez częstą komunikację i współautorstwo kodu. Często też jako dokumentację traktuje się dobrze napisane testy jednostkowe, które w projektach agile są podstawą testowania i utrzymywania produktu w sytuacji częstych zmian.

Bycie „na bieżąco” wszystkich osób w zespole zapewniają Daily Scrums, czyli dzienne scrumy. Codziennie, najlepiej o podobnej porze, cały zespół spotyka się na krótką, około 15 minutową pogawędkę, którą organizuje Scrum Master. Każdy na takim spotkaniu stara się pokrótce opowiedzieć co zrobił w przeciągu ostatnich 24 godzin, co planuje zrobić dzisiaj i jakie problemy napotkał podczas pracy. Co ważne – na spotkaniu problemy te NIE są rozwiązywane. Zainteresowani mogą zrobić sobie później już inne spotkanie skupione na tej kwestii. W ten sposób nie tracimy czasu wszystkich osób w zespole.

Spotkania te zazwyczaj odbywają się przed tablicą ze sprint backlogiem, by wiedzieć o czym rozmawiamy i by można było na szybko coś w nim zmienić. Rozmowa odbywa się na stojącą – dzięki temu nikt nie będzie marnował czasu na niezwiązane z tematem pogawędki. Po co to wszystko? Ponieważ komunikacja w zespole leży u podstaw Scruma, a jej bezpośrednia forma jest najefektywniejsza.

Sprint kończy się dokładnie w momencie, który został ustalony na spotkaniu przedsprintowym. Nie przedłużamy iteracji, nawet jeśli nie wykonaliśmy wszystkich zadań. Wracają one z powrotem do product backlog i zazwyczaj są kończone w następnym sprincie.

3.3. Sprint Review Meeting

Po zakończeniu iteracji powinniśmy mieć już część działającego produktu. Możemy ją wówczas zaprezentować jako „demo” wszystkim zainteresowanym stronom – udział w nim może wziąć nawet pani sprzątaczka, czy stróż nocy (jeśli są udziałowcami projektu). Oczywiście wszystko z naszym krótkim komentarzem. Product Owner przysłuchuje się uwagom zainteresowanych, sam też przygląda się dokładnie produktowi. Sprawdza czy zaprezentowana jego część odpowiada założeniom ustalonym na początku sprintu.

Po sprint review mamy poprawiony Product Backlog, który wchodzi do następnej iteracji.

3.4. Sprint Retrospective

Retrospektywa zakończonego sprintu robiona jest już przez sam zespół i Product Ownera. Analizowane jest co poszło zgodnie z oczekiwaniami, a co się nie udało. Staramy się odpowiedzieć sobie na pytania: Co poszło dobrze podczas ostatniego sprintu? Co można poprawić w następnym przebiegu? PO uzupełnia product backlog o nowe funkcjonalności, które wyklarowały się w czasie iteracji i prezentacji demo oraz o zadania które należy poprawić.

Po retrospektywie ponownie organizowane jest Sprint Planning Meeting. Rozpoczyna się kolejny Sprint. Sprintów mamy tyle, ile potrzeba do ukończenia projektu. Może być ich 4, jak i 44. Wszystko zależy od wielkości projektu i tego jak bardzo zmieniały się wymagania w jego czasie trwania. Jeśli pracujemy nad produktem - praca jest stała i po prostu nie limitujemy liczby sprintów.

4. Podsumowanie przebiegu Scruma

Za podsumowanie nich nam posłuży prosta lista, która reprezentuje krok po kroku wszystko to co najważniejsze w Scrumie:

1. Product Owner tworzy Product Backlog

2. Przed sprintem zespół szacuje jednostki backloga

3. Zespół wraz z PO wybiera (najbardziej potrzebne) User Stories do sprintu

4. Zespół rozbija User Stories na zadania i estymuje je czasowo

5. Progamiści przydzielają sobie zadania i pracują nad nimi

6. Codziennie odbywa się krótkie spotkanie scrumowe

7. Po zakończeniu iteracji prezentowane jest demo

8. Zespół wraz z PO robi retrospektywę przebiegu

9. Uzupełniany jest Product Backlog

10. Rozpoczyna się kolejny sprint

Jak widzisz, Scrum nie jest wielce skomplikowany. Jeśli zrozumiesz dobrze manifest Agile, to stosowanie Scruma stanie się oczywistością. Czy warto stosować SCRUMa? Na pewno! Świetnie sprawdza się on przy tworzeniu i rozwijaniu innowacyjnych produktów. Warto dać mu szanse w swojej organizacji lub startupie.

Jeśli zainteresował Cię ten opis - koniecznie przeczytaj całego Scrum Guide - oficjalny podręcznik do Scruma (dostepny za darmo)