Dzisiaj czas na events czyli wydarzenia. Wydarzenia to bardzo ważna część Scrum. Bez nich ciężko byłoby mówić, że pracujemy tą metodologią. Ich celem jest zachowanie przejrzystości, umożliwienie komunikacji, doskonalenie sposobów w jaki zespół pracuje, a także zaprezentowanie tego co zostało zrobione i podjęcie decyzji o ewentualnych zmianach. Poniżej wyjaśnię Ci dokładniej w jaki sposób jest to robione.
Scrum wyróżnia pięć wydarzeń, które widzisz na poniższej grafice, zanim jednak przejdę do ich omawiania, jedna ważna rzecz. Wydarzenia powinny odbywać się regularnie, najlepiej o tych samych porach i w tych samych miejscach. Dzięki temu powstaje rytm a nasze ludzkie umysły uwielbiają rytm i regularność. Rytm jest sercem Scruma.
Sprint
Sprint jest specyficznym wydarzeniem, ponieważ zawiera w sobie wszystkie pozostałe wydarzenia.
Scrum dzieli czas pracy na fragmenty zwane Sprintami. To coś w rodzaju kolejnych etapów. W każdym z tych etapów wykonuje się pewne stałe czynności a ich czas i miejsce jest ściśle określony i przestrzegany. Celem każdego Sprintu powinno być dostarczenie jakiegoś działającego fragmentu wytwarzanego produktu.
Spójdz na powyższy obrazek. Maksymalnie na lewo mamy pusty prostokąt. Tak na początku wygląda nasz produkt – nie mamy nic. Rozpoczynamy nasz pierwszy Sprint. Przechodzimy przez elementy podobne do występujących we wspomnianej we wcześniejszych lekcjach metodyki Waterfall.
Na koniec pierwszego Sprintu nasz prostokąt-produkt ma już jeden element. W następnym, powtarzamy cykl i produkt otrzymuje kolejny element, kolejną funkcjonalność. I tak dalej aż zostanie ukończony.
Podczas trwania Sprintu nie powinno się wprowadzać żadnych zmian, które mogłyby zagrozić w osiągnięciu jego celu. Sprint można natomiast przerwać, ale tylko za zgodą Product Ownera i tylko w sytuacji kiedy wyznaczony cel stał się nieaktualny.
Jaki jest sens takiego działania? Co dzięki temu zyskujemy? Po każdej iteracji, czyli Sprincie, można zadecydować, czy to co zrobiliśmy ma sens. Przez dwa tygodnie wbrew pozorom sporo mogło się zmienić. Pamiętasz jak wcześniej pisałem o podnoszeniu głowy co jakiś czas? To właśnie ma miejsce na koniec Sprintu.
Ale co tak dokładnie dzieje się podczas takiego Sprintu? Rozwińmy zatem taką jedną taką „pętelkę”. Oto co zobaczymy:
Sprint Planning
Pracę do wykonania trzeba zaplanować. Taki jest cel tego wydarzenia, które jak widzisz na powyższym rysunku ma miejsce w pierwszym dniu Sprintu. W spotkaniu wziąć powinien udział cały Scrum Team, czyli Product Owner, Scrum Master, Development Team. Nic też nie stoi na przeszkodzie, żeby wzięły w nim udział także inne osoby z poza Teamu, jeśli potrzeba jakiejś specjalistycznej wiedzy.
Spotkanie ma ściśle określony czas i tak np. dla Sprintu 2 tygodniowego powinno mieć 4h, dla miesięcznego 8h.
Celem spotkania jest wypracowanie Sprint Backlogu, czyli zadań jakie zostaną wykonane podczas następnego Sprintu. Bardzo ważne jest też określenie jaki cel ma nasz Sprint. To tak zwany Sprint Goal, który określa co takiego wartościowego wytworzymy dla naszego Klienta.
Kolejną ważną kwestią jest oszacowanie pracy jaka jest do wykonania. Takie szacowanie i metody jakimi się można posługiwać są sztuką samą w sobie i nie będę ich tutaj omawiał. Jeśli temat Cię interesuje to wygooglaj np. takie hasła jak „Scrum Poker” albo „Planning Poker”.
Na koniec nie można zapomnieć o tym, że podczas Sprint Planning należy zadecydować o tym w jaki sposób praca zostanie wykonana. O tym decydują Developerzy. Nikt im nie może narzucić w jaki sposób mają wykonać pracę. Pamiętasz jak w poprzedniej lekcji napisałem, że Development Team powinien być autonomiczny? To właśnie jest jeden z przejawów tej autonomiczności.
Planowanie wydaje się to proste, ale uwierzcie mi nie jest… 🙂 Kiedy już się z tym uporamy i mamy gotowy Sprint Backlog możemy ruszać dalej.
Daily Scrum
Jedną z cech Scruma jest transparentność i otwarta komunikacja. Po to jest Daily Scrum. To codzienne spotkania, których zasady również są ściśle określone a celem jest synchronizacja pracy i informacji.
W Daily Scrum powinien brać udział tylko Development Team. Często jednak uczestniczy w nim także Scrum Master, szczególnie jeśli Team nie ma jeszcze na tyle dojrzałości scrumowej, żeby robić to samodzielnie.
Spotkanie powinno mieć nie więcej niż 15 minut. Podczas spotkania każdy członek zespołu odpowiada na trzy pytania:
- Co zrobiłem dnia poprzedniego?
- Co planuję zrobić dzisiaj?
- Na jakie przeszkody natrafiłem?
I to wszystko. Efektem tego spotkania powinien być plan na nadchodzący dzień, dlatego dobrze, żeby Daily Scrum odbywał się możliwie wcześnie. Jeśli rozmowa się przedłuża, albo wymyka się spod kontroli to Scrum Master powinien zaregować i przenieść dyskusję poza Daily Scrum.
Sprint Review
OK, pracowaliśmy zaciekle przez 2 tygodnie. W końcu nadszedł koniec Sprintu. To czas na dwa kolejne wydarzenia. Pierwszym z nich jest Sprint Review czyli pokazanie światu co zrobiliśmy. Tak jak w przypadku każdego innego wydarzenia i tu są określone zasady.
Celem spotkania jest prezentacja i ocena wykonanej pracy, otrzymanie feedbacku (czyli mówiąc ładnie po polsku – informacji zwrotnej ;)) o tym co zrobiliśmy oraz zebranie informacji o ewentualnych zmianach jakie należy wprowadzić.
Sprint Review nie powinie być jedynie prezentacją. To spotkanie, które powinno mieć bardziej roboczą, warsztatową formę.
W spotkaniu bierze udział cały Scrum Team (Product Owner, Scrum Master, Development Team) oraz co ważne – Klient (nieważne czy zewnętrzny czy wewnętrzny).
Spotkanie powinno trwać 2 godziny dla sprintu 2 tygodniowego (dla sprintów o innym czasie trwania proporcjonalnie).
Po zakończeniu Sprint Review czas na ostatnie, ale nie mniej ważne zdarzenie.
Sprint Retrospective
Stare powiedzenie mówi „pracuj mądrze, nie ciężko”. Żeby móc pracować mądrze musimy wiedzieć co jest nie tak i uczyć się, żeby następnym razem było lepiej.
To właśnie wyciąganie wniosków i nauka jest celem tego spotkania.
Spotkanie kończące Sprint to bardzo dobry czas na wspomnienia – retrospekcje. Zespół zbiera się i dyskutuje co w kończącym się Sprincie się nie sprawdziło, co należałoby poprawić, co dodać, co wyeliminować. Słowem co zrobić, żeby następnym razem było lepiej.
Bierze w nim udział cały Scrum Team. Spotkanie powinno trwać 1,5h dla 2 tygodniowego sprintu.
Jak to wygląda w Jira Software?
Aktywny Sprint
Na poniższym zrzucie ekranu możesz zobaczyć jak wygląda w Jira Software podgląd na aktualnie trwający Sprint. Można to zrobić jednym kliknięciem w menu po lewej stronie w przycisk „Active sprints”.
Po prawej zobaczymy wtedy tablicę na której będą wyświetlone wszystkie zadania nad którymi pracujemy. Do samej tablicy wrócę jeszcze przy okazji kolejnego artykułu w którym omówię artefakty Scruma. Na razie niech Ci wystarczy wiedza, że jest to miejsce na którym wyświetla się wszystkie zadania jakie są do wykonania w danym Sprincie.
Zadania na tej tablicy można podglądać (spójrz niżej gdzie nawiązuję do Daily Scrum), można je przenosić pomiędzy kolumnami i robić z nimi jeszcze wiele innych rzeczy. Opiszę to w lekcji dotyczącej już konkretnie posługiwania się tablicą.
Sprint Planning
Jak zapewne pamiętasz podczas Sprint Planningu planuje się zadania jakie będą do wykonania w Sprint. Innymi słowy wyciąga się zadania z Product Backlog do Sprint Backlog. Dokładnie to można robić w Jira.
Spójrz na poniższy obrazek. Kiedy klikniesz w lewym menu „Backlog” zobaczysz product Backlog (na ekranie to tickety na samym dole). Tam są wszystkie zadania dotyczące projektu. Lista ta może być baaardzo długa.
Kiedy zasiadacie z zespołem do planowania sprintu, kliknij przycisk „Create Sprint”, który znajdziesz po prawej stronie ekranu tuż nad ticketami. Wtedy Jira utworzy Ci pusty sprint. Na ekranie widać go pod nazwą „Sample Sprint 3”. Następnie – nic prostrzego, przeciągasz zadania z Backlog do nowo powstałego Sprint Backlogu.
Zwróć jeszcze proszę uwagę, że w tym widoku masz także podgląd na aktywny Sprint. Jest on na samej górze, nazywa się „Sample Sprint 2”. To, że jest aktywny poznasz po zielonym napisie „ACTIVE” znajdującym się tuż koło nazwy.
Daily Scrum
Kiedy Sprint ruszył czas na codzienne Daily Scrumy. Odbywać je możemy przy wspomnianej wcześniej tablicy z zadaniami (kliknij w lewym menu Active Sprint). Jeśli zajdzie potrzeba spojrzeć na detale konkretnego zadania, można zrobić to bardzo łatwo, po prostu klikając na nie. Wtedy, po prawej stronie, pojawią Ci się wszystkie detale związane z zadaniem.
Szacowanie
Przy okazji Sprint Planningu wspominałem, że wszystkie zadania do wykonania powinny być oszacowane pod kątem ilości pracy jaka jest z nimi związana. Jedną z wielu metod jakie wspiera Jira Software jest szacowanie za pomocą tak zwanych Story Points. Na poniższym ekranie możesz zobaczyć jak to wygląda w praktyce.
Zwróć uwagę, że w Backlogu ostatnia pozycja zwiera cyfry. To właśnie są owe Story Points. Możne je łatwo edytować wchodząc z szczegóły danego ticketu i zmieniając wartość w polu Estimate.
W każdym istniejącym Sprincie możesz zobaczyć sumę wszystkich punktów, które oznaczają łączną ilość pracy do wykonania. Na poniższym screenie w „Sample Sprint 3” po lewej na dole widzisz „Estimate 0” To właśnie ta suma.
W kwestii szacowania to nie jedyne możliwości. W tekście wyżej wspominałem o metodzie zwanej Scrum Poker. Istnieje wiele różnych dodatków do Jira, które ułatwiają grę. Poniżej widzisz przykładowy zrzut ekranu z Atlassian Marketplace. Więcej znajdziesz klikając w link: https://marketplace.atlassian.com/search?query=scrum%20poker
Jeśli czujesz niedosyt w kwestii pracy ze Sprintami, Backlogiem etc to spokojnie 🙂 W dalszych lekcjach mam zamiar dokładnie omówić wszystkie elementy konfiguracji projektu.
Sprawdź co umiesz
Jednym z moich ulubionych sposobów na naukę jest tworzenie pytań do zagadnienia, które poznaję. Poniżej przygotowałem listę pytań, które zadałbym sam sobie. Jeśli na nie odpowiesz to przygotuj swój własny zestaw 🙂 Postaraj się na nie odpowiedzieć własnymi słowami. Jeśli czegoś zapomnisz, albo zabraknie Ci słowa – zajrzyj do tekstu wyżej a potem powtórz proces 🙂
Pytania sprawdzające
- Opisz własnymi słowami czym jest Sprint?
- Z jakich wydarzeń składa się Sprint?
- Na czym polega Daily Scrum?
- Czy Jira ma funkcjonalność pozwalającą na szacowanie ilości pracy?
Poprzednia lekcja
Scrum – Role