Scrum — samouczek
W tym samouczku przedstawimy instrukcje krok po kroku dotyczące realizacji projektów Scrum, ustalania priorytetów i organizowania backlogu w formie sprintów, przeprowadzania wydarzeń Scrum oraz wielu innych zagadnień — wszystko w Jira.
Czas:
10 minut czytania. Do ukończenia w ciągu 2 tygodni.
Odbiorcy:
Zaczynasz przygodę z tworzeniem oprogramowania według zasad Agile albo korzystanie z Jira lub ram postępowania Scrum
Wymagania wstępne:
Utworzone konto Jira
Scrum to jedne z najpopularniejszych ram postępowania do wdrażania metodyki Agile. W modelu Scrum produkt powstaje w serii iteracji o stałej długości nazywanych sprintami, które zapewniają zespołom ramy postępowania umożliwiające regularne wysyłki.
Krok 1: Tworzenie projektu Scrum
Po utworzeniu projektu i zalogowaniu się na konto w Jirze możesz wybrać szablon z biblioteki. Wybierz opcję Scrum (możesz wyświetlić podgląd darmowego szablonu Scrum tutaj lub przejść tutaj, aby dowiedzieć się, jak utworzyć projekt Kanban).
Następnie pojawi się monit o wybranie typu projektu. Jeśli Twój zespół pracuje niezależnie i chce kontrolować swoje procesy robocze i praktyki we własnej, odrębnej przestrzeni, rozważ wypróbowanie naszego szablonu projektu Scrum zarządzanego przez zespół. Więcej informacji zawiera temat dotyczący rozpoczynania pracy z projektami zarządzanymi przez zespół w społeczności Atlassian.
Po utworzeniu projektu pojawi się pusty backlog. Backlog bywa również nazywanym backlogiem produktu i zawiera aktualizowaną na bieżąco listę potencjalnych jednostek pracy zespołu w ramach projektu.
Krok 2: Tworzenie historyjek użytkowników lub zadań w backlogu
W Jirze jednostki pracy, takie jak historyjki użytkowników, zadania i błędy, nazywamy „zgłoszeniami”. Utwórz kilka historyjek użytkowników, korzystając z opcji szybkiego tworzenia dostępnej w backlogu. Jeśli nie przychodzą Ci do głowy żadne historyjki użytkowników, utwórz jedynie przykładowe historyjki, aby rozpocząć pracę i zobaczyć, jak działa cały proces.
Historyjki użytkowników służą do opisywania jednostek pracy w języku nietechnicznym i z perspektywy użytkownika. Jako {typ użytkownika} chcę {cel}, aby {uzyskana korzyść}.
Użyjmy witryny internetowej jako prostego przykładu tworzenia historyjki użytkownika.
Jako klient chcę mieć możliwość utworzenia konta, aby wyświetlać moje poprzednie zakupy.
Zazwyczaj to product owner nakreśla historyjki użytkowników i ustala ich priorytety, a następnie zespół programistyczny określa szczegółowe zadania konieczne do ukończenia historyjki w trakcie nadchodzącego sprintu. Zespół programistyczny odpowiada również za oszacowanie względnego nakładu pracy wymaganego do zrealizowania historyjki.
Po utworzeniu kilku historyjek użytkowników możesz zacząć nadawać im priorytety w backlogu. Szeregowanie lub ustalanie priorytetów historyjek w Jirze polega na przeciąganiu i upuszczaniu ich w kolejności, w jakiej powinny być prowadzone nad nimi prace.
Są to jedynie początkowe historyjki projektu. W całym cyklu życia projektu będziesz stale tworzyć nowe historyjki. Dzieje się tak dlatego, że metodyka Agile zakłada ciągłe uczenie się i dostosowywanie sposobu postępowania.
Krok 3: Tworzenie sprintu
Utwórz w backlogu swój pierwszy sprint, aby móc zacząć go planować.
W metodyce Scrum zespoły przewidują ukończenie zbioru historyjek użytkowników lub innych jednostek pracy w ustalonym czasie nazywanym sprintem. Sprinty trwają zazwyczaj tydzień, dwa tygodnie lub cztery tygodnie. O długości sprintu decyduje zespół — my zalecamy zacząć od dwóch tygodni. Jest to czas na tyle długi, aby umożliwić realizację istotnych prac, ale nie aż tak długi, aby zespół nie mógł otrzymywać regularnych informacji zwrotnych. Po ustaleniu kadencji sprintu zespół będzie się jej trzymał. Sprinty o stałej długości sprzyjają rozwijaniu umiejętności szacowania i przewidywania przyszłej prędkości zespołu w trakcie realizacji prac z backlogu.
Krok 4: Organizowanie spotkania dotyczącego planowania sprintu
Na początku sprintu trzeba zorganizować spotkanie dotyczące planowania sprintu z udziałem reszty zespołu. Spotkanie dotyczące planowania sprintu jest wydarzeniem, które ukierunkowuje cały zespół na taki sposób realizacji sprintu, aby zakończył się on powodzeniem. W trakcie tego spotkania cały zespół omawia cel sprintu oraz historyjki w backlogu produktu uporządkowane według priorytetu. Zespół programistyczny opracowuje szczegółowe zadania i szacunki dotyczące historyjek o wysokim priorytecie. Następnie podejmuje się ukończenia określonej liczby historyjek w trakcie sprintu. Te historyjki oraz plan ich realizacji tworzą backlog sprintu.
Dodaj do swoich historyjek oszacowania wyrażone w punktach historyjek, wprowadzając liczbę w polu Oszacowanie punktów historyjek. Możesz również dodać więcej szczegółów do historyjki lub kliknąć ikonę tworzenia zadania podrzędnego, aby dodatkowo podzielić pracę w ramach historyjki.
Gdy wszystko będzie gotowe, przeciągnij historyjki zaakceptowane w trakcie spotkania dotyczącego planowania sprintu do utworzonego przed chwilą sprintu. Będzie to backlog sprintu.
Uczestnicy: wymagani: zespół programistyczny, Scrum Master, product owner.
Kiedy: na początku sprintu.
Czas trwania: Zwykle dwie godziny na każdy tydzień iteracji — np. dwutygodniowy sprint zaczyna się od czterogodzinnego spotkania dotyczącego planowania. Spotkanie kończy się, gdy jego cel zostanie osiągnięty.
Cel: Zaplanowanie pracy w ramach sprintu. Zespół uzgadnia cel sprintu oraz backlog sprintu.
Podczas tworzenia sprintu product owner zazwyczaj wskazuje cel sprintu. Wyznacza on w ten sposób temat prac, które będą realizowane w trakcie sprintu. Cel sprintu zapewnia również pewną elastyczność pod względem liczby historyjek, które zostaną ukończone podczas sprintu. Sprint zostaje uznany za zakończony powodzeniem, jeśli jego cel zostanie osiągnięty.
Tradycyjne zespoły programistyczne wyrażają szacunki w formie czasu: dni, tygodni, miesięcy.
Wiele zespołów Agile przechodzi jednak na punkty historyjek. Punkty historyjek często uwzględniają względną ocenę nakładu pracy wyrażoną w formacie przypominającym ciąg Fibonacciego: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Szacunki pomagają ustalić, ile prac powinno się dodać do kolejnego sprintu, biorąc pod uwagę liczbę członków zespołu. Po kilku sprintach zespół będzie lepiej orientował się, ile pracy może wykonać w każdym sprincie, co pomoże uniknąć zobowiązywania się do podjęcia zbyt dużej ilości pracy.
Krok 5: Rozpoczynanie sprintu w systemie Jira
Nadaj sprintowi nazwę. Niektóre zespoły nadają sprintom nazwę związaną z ich celem. Jeśli zgłoszenia realizowane w ramach sprintu mają wspólny element, wykorzystaj go jako temat do nadania sprintowi nazwy. Możesz również nadać sprintowi dowolną inną nazwę.
Dodaj czas trwania sprintu oraz daty rozpoczęcia i zakończenia. Daty rozpoczęcia i zakończenia powinny być zgodne z harmonogramem zespołu. Przykładowo niektóre zespoły rozpoczynają sprinty w poniedziałek, a kończą w piątkowy poranek kolejnego tygodnia. Inne zespoły decydują się z kolei na rozpoczynanie i kończenie sprintów w środku tygodnia. Wszystko zależy od Ciebie. Jeśli nie masz pewności, jak długo powinny trwać sprinty, zalecamy wypróbowanie okresu dwutygodniowego.
Dodaj cel sprintu uzgodniony w trakcie spotkania dotyczącego planowania sprintu.
Po rozpoczęciu sprintu nastąpi przeniesienie na kartę Bieżące sprinty w projekcie.
W tym miejscu zespół będzie pracował, pobierając elementy z kolumny Do zrobienia i przenosząc je do kolumny W toku, a ostatecznie do kolumny Gotowe.
Jeśli używasz szablonu projektu Scrum zarządzanego przez zespół, ten obszar będzie nazywany tablicą.
Krok 6: Organizowanie codziennych spotkań stand-up
Po rozpoczęciu sprintu codziennie (najlepiej rano) organizuj spotkania swojego zespołu, aby dowiedzieć się, nad czym pracują poszczególni członkowie. Celem takiego spotkania jest sprawdzenie, czy któryś z członków zespołu nie ma trudności z realizacją zadań sprintu.
Uczestnicy (przede wszystkim): zespół programistyczny.
Częstotliwość: raz dziennie, zazwyczaj rano.
Czas trwania: Nie więcej niż 15 minut. Nie rezerwuj sali konferencyjnej ani nie przeprowadzaj spotkania stand-up na siedząco. Pozycja stojąca ułatwia pilnowanie czasu spotkania!
Cel: Codzienne spotkanie stand-up ma na celu szybkie poinformowanie wszystkich o tym, co dzieje się w całym zespole, i zaplanowanie pracy na cały dzień. Nie jest to zebranie mające na celu wyczerpujące omówienie aktualnej sytuacji. Powinno być utrzymane w lekkim, wesołym tonie, ale koncentrować się na informacjach. Niech każdy członek zespołu odpowie na następujące pytania:
- Co było przedmiotem mojej pracy wczoraj?
- Nad czym pracuję dzisiaj?
- Czy coś mnie blokuje?
Raportowanie prac wykonanych poprzedniego dnia w gronie współpracowników wymusza pewną odpowiedzialność. Nikt nie chce być tym członkiem zespołu, który stale robi to samo i nie czyni żadnych postępów.
Fachowa porada: Niektóre zespoły wykorzystują minutniki, aby utrzymać wszystkich w ryzach. Inne rzucają piłką między członkami zespołu, aby skupić uwagę wszystkich. Wiele rozproszonych zespołów korzysta z wideokonferencji lub czatu grupowego, aby rozwiązać kwestię odległości. Twój zespół jest wyjątkowy — więc Twoje spotkania stand-up też powinny!
Możesz skorzystać z obszaru bieżących sprintów na tablicy Scrum w trakcie codziennych spotkań stand-up, aby każdy członek zespołu mógł zobaczyć zadania, nad którymi pracuje.
Krok 7: Wyświetlanie wykresu spalania
Dobrym pomysłem jest obserwowanie w trakcie sprintu wykresu spalania. Wykres spalania w Jirze pokazuje rzeczywistą i szacowaną ilość pracy do wykonania w sprincie. Jest on aktualizowany automatycznie przez system Jira w miarę realizowania kolejnych jednostek pracy. Aby wyświetlić ten wykres, kliknij opcję Raporty na pasku bocznym, a następnie wybierz pozycję Wykres spalania z menu rozwijanego raportów.
Wykres spalania pokazuje rzeczywistą i szacowaną ilość pracy do wykonania w sprincie. Pozioma oś X na wykresie spalania przedstawia czas, a pionowa oś Y — zwykle punkty historyjek.
Użyj wykresu spalania, aby monitorować łączną ilość pozostałej pracy do wykonania w trakcie sprintu i prognozować prawdopodobieństwo osiągnięcia celu sprintu. Dzięki śledzeniu pozostałej pracy w całej iteracji zespół może zarządzać swoim postępem i odpowiednio reagować.
- Przedwczesne kończenie kolejnych sprintów przez zespół w związku z podejmowaniem się zbyt małej ilości prac.
- Prognozy nierealizowane przez zespół w kolejnych sprintach w związku z podejmowaniem się zbyt dużej ilości prac.
- Linia spalania zawiera gwałtowne spadki, zamiast przedstawiać bardziej stopniowe spalanie, ponieważ praca nie została podzielona na mniejsze fragmenty.
- Product owner rozszerza lub zmienia zakres w trakcie trwania sprintu.
Krok 8: Wyświetlanie raport dot. sprintu
Raport dot. sprintu można wyświetlić w dowolnej chwili w trakcie sprintu lub po jego zakończeniu, aby monitorować przebieg sprintu.
Raport dot. sprintu obejmuje wykres spalania oraz listę ukończonych i nieukończonych prac, a także wszelkich prac dodanych już po rozpoczęciu sprintu.
Krok 9: Organizowanie spotkania dotyczącego przeglądu sprintu
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
To spotkanie obfituje w opinie na temat projektu i obejmuje sesję burzy mózgów, na podstawie której ustala się dalsze działania.
Uczestnicy (przede wszystkim): zespół programistyczny, Scrum Master, product owner.
Opcjonalnie: interesariusze.
Kiedy: zazwyczaj w ostatnim dniu sprintu.
Czas trwania: zazwyczaj dwie godziny w przypadku dwutygodniowego sprintu.
Cel: ocena przyrostu i wspólna aktualizacja backlogu produktu.
Pytania, które należy zadać:
- Czy zespołowi udało się zrealizować prognozę?
- Czy w trakcie sprintu dodawano lub usuwano jakieś prace?
- Czy w trakcie sprintu jakaś praca nie została ukończona?
- Jeśli tak, dlaczego?
Krok 10: Organizowanie spotkania dotyczącego retrospektywy sprintu
Po zakończeniu sprintu przeprowadź retrospektywę zespołu. Udokumentuj gdzieś jej wyniki. Pozwolimy sobie zaproponować Confluence.
Uczestnicy: zespół programistyczny, Scrum Master, product owner.
Kiedy: na końcu iteracji.
Czas trwania: zazwyczaj 90 minut w przypadku dwutygodniowego sprintu.
Cel: Samodzielna kontrola zespołu z uwzględnieniem jego procesów, narzędzi oraz interakcji. Do backlogu następnego sprintu często dodaje się zgłoszenia związane z ulepszeniami.
Retrospektywy to nie czas na narzekania bez podejmowania konkretnych czynności. Korzystaj z retrospektyw, aby zorientować się, co się sprawdza w zespole, aby jego członkowie mogli nadal koncentrować się na tych obszarach. Te spotkania pozwalają również stwierdzić, co nie działa poprawnie, i znaleźć twórcze rozwiązania oraz opracować stosowny plan działania. Ciągłe doskonalenie jest tym, co podtrzymuje i napędza rozwój w zespole Agile, a retrospektywy odgrywają w tym procesie kluczową rolę.
Pytania, które należy zadać:
- Co w trakcie sprintu poszło dobrze?
- Co można było zrobić lepiej?
- Co zamierzamy zrobić lepiej następnym razem?
Fachowa porada: Nie należy rezygnować z retrospektyw, nawet jeśli sprawy w zespole mają się dobrze. Retrospektywy dostarczają zespołowi ciągłych wskazówek, które pozwalają jego członkom działać sprawnie.
Krok 11: Kończenie sprintu w systemie Jira
Gdy czas sprintu dobiegnie końca, trzeba go zakończyć.
Jeśli sprint zawiera nieukończone zgłoszenia, możesz:
- przenieść te zgłoszenia do backlogu;
- przenieść te zgłoszenia do przyszłego sprintu;
- przenieść te zgłoszenia do nowego sprintu, który zostanie utworzony dla Ciebie w systemie Jira.
Krok 12: Powtórzenie czynności od kroku 2
Na tym etapie znasz już podstawy dotyczące opracowywania backlogu zawierającego historyjki użytkowników, organizowania historyjek użytkowników w sprinty, rozpoczynania sprintu i przeprowadzania wydarzeń Scrum. Możesz teraz zdecydować, czy to wystarczy dla Twojego zespołu, czy też chcesz zagłębić się w nieco bardziej zaawansowane tematy.
Gdy już wykonasz wraz z zespołem powyższe kroki, przejdź do artykułu dla zaawansowanych: Zaawansowane praktyki Scrum w Jirze.
