Kurs Jira: Scrum – Artefakty

 

Kurs Jira: Scrum – Artefakty

Czas na ostatnią lekcję, w której opowiem o tym jak Scrum wiąże się z Jirą. Artefakty takie jak Product Backlog czy Sprint Backlog częściowo omówiłem w poprzednim artykule, dzisiaj jednak postaram się zrobić to dokładniej. Artefakty są trzy, jednak na poniższym obrazku przy Product Backlog dodałem jeszcze dwa elementy – Epic oraz User Story. Nie są one artefaktami w rozumieniu Scruma, ale są tak charakterystycznym elementem, że postanowiłem je tutaj umieścić.

Product Backlog

W jednym z poprzednich artykułów wspomniałem, krótko o tym jak wygląda Backlog w Jira Software. Teraz parę zdań czym on dokładnie jest.

To lista wszystkiego co MOŻE składać się na końcowy produkt. Podkreślam – może, ale nie musi. Backlog jest wiecznie żywy, zmienny. Nie tworzy się go raz i zostawia. Nie. On się ciągle zmienia, nigdy nie jest skończony. Można do niego dodawać wszystkie kwestie związane z naszym projektem, które przyjdą nam do głowy. Można też dowolnie usuwać te, które uznamy za nieaktualne, albo stwierdzimy, że nie ma sensu ich realizować. Za zmiany te odpowiada Product Owner.

Kolejność elementów w backlogu nie jest przypadkowa. Jest spriorytetyzowany a do oznaczenia priorytetów stosuje się bardzo prostą metodę. Im ważniejsze tym wyżej na liście.

Ważne jest też to, że praca w backlogu jest oszacowana. Oznacza to, że jest wiadomo ile pracy zajmie każdy z jego elementów. Szacowaniem i metodami jakimi się można posługiwać podczas tego procesu nie będziemy się zajmować w tym momencie.

W ramach backlogu trzeba wspomnieć o dwóch elementach Epic i User Story.

Epic

To najprościej mówiąc duża część pracy do wykonania. Na tyle duża, że trzeba ją rozbić na mniejsze bo w jednym sprincie nie da się jej zrealizować.

Wyobraź sobie, że remontujesz mieszkanie – to projekt. Do kategorii Epic można by zaliczyć remont łazienki, remont kuchni itd. W ramach Epicu o nazwie „Remont łazienki” wejdą takie zadania jak: zaprojektowanie nowego wyglądu, zakupy nowych rzeczy, usunięcie istniejącego wyposażenia, skucie kafelków itd. Te mniejsze zadania na które rozbija się Epic nazywają się w Scrumie User Stories.

Znacie taki suchar? Jak zjeść słonia? Po kawałku! No właśnie. Ten dowcip nie jest taki głupi i nabiera nowego znaczenia w kontekście scruma.

User Story

Tak jak wspomniałem wyżej User Story to najmniejsza wykonalna w jednym sprincie część pracy. Są pewne zasady, zgodnie z którymi powinno się tworzyć takie historyjki, ale nie będę ich teraz omawiał. Warto jednak wspomnieć, że dobre User Story powinno mieć określone coś co nazywa się Definition Of Done (DoD) – to jasno określona informacja co powinno zostać zrobione jeśli mamy uznać User Story za wykonane. Często jest sporządzana w formie checklisty.

Wracając do przykładu z remontem łazienki. DoD dla User Story „usunięcie istniejącego wyposażenia” mogłoby być: usunięta umywalka i wanna, odkręcone wszystkie krany, usunięte lustro, wyniesiona pralka, odkręcone oświetlenie.

Sprint Backlog

Product backlog nie jest jedynym backlogiem w scrumie. Jest jeszcze Sprint Backlog. Pamiętasz rytuał Sprint Planning? To podczas niego z Product Backlog wybiera się zadania (pamiętasz jak się fachowo nazywają? Bardzo dobrze – User Stories 🙂 ), które mają być wykonane w najbliższym sprincie. Te wybrane User Stories przenosi się do Sprint Backlog.

Bardzo ważną cechą Sprint Backlog jest to, że jest „zamrożony”. Kiedy sprint wystartuje, nie wolno zmieniać zawartości Sprint Backlog.

Istotną kwestią jest to, że dobry Sprint Backlog powinien również być dobrze zaplanowany – to znaczy zespół powinien mieć plan jak te zadania wykonać.

Increment

Czyli przyrost. Zgodnie z definicją to jakiś konkretny krok w stronę zbudowania produktu. Jest dodawany do poprzednich i razem z nimi stanowi konkretny, mierzalny element gotowego produktu.

Pamiętasz kolorowe kwadraty z obrazka o sprincie? Każdy z tych kolorowych kwadracików to właśnie increment prowadzący nas do stworzenia gotowego produktu.

Jak to wygląda w Jira Software?

Teraz pokażę Ci jak wspomniane wyżej elementy wyglądają w Jira Software. Pamiętaj, że to co widzisz u siebie na ekranie może nieco różnić się od tego co jest na poniższych zrzutach ekranu. Powodów może być wiele – korzystasz z innej wersji Jira, masz zainstalowane jakieś pluginy, które nieco zmieniają wygląd, masz więcej elementów w backlogu, więcej przygotowywanych sprintów itd.

Ogólna zasada jednak pozostaje niezmienna.

Product Backlog, Epic oraz User Story

Backlog

Kiedy jesteś w projekcie, w menu po lewej stronie ekranu powinna być widoczna opcja Backlog (1). Jeśli ją klikniesz w prawej części ekranu powinno się pojawić coś podobnego do tego co widzisz na powyższym zrzucie ekranu (2).

W tym widoku Backlog znajduje się zawsze na dole. Powyżej znajduje się podgląd na aktywny sprint (zawsze na samej górze) oraz ewentualne przygotowywane sprinty (na przykładzie ich nie ma). Przygotowywanych sprintów może być wiele, dlatego zdarzyć się może, że będzie trzeba przeskrolować ekran na sam dół żeby dotrzeć do Backlogu.

User Stories

Jak zapewne pamiętasz elementami backlogu są User Stories (3). Na przykładzie jest ich 7, ale pamiętaj, że może ich tam być setki. Wtedy ten obszar będzie zajmował o wiele, wiele więcej miejsca.

W praktyce też bardzo rzadko w Backlogu znajdują się tylko User Stories. Jira pozwala na stworzenie dowolnych rodzajów zgłoszeń, w zależności od potrzeb zespołu. Dlatego nie jest rzadkością, że w tym miejscu znajdziesz także inne rodzaje zgłoszeń takie jak np. Task, Bug i wiele innych.

Epic

Zwróć proszę uwagę na punkt 4 na zrzucie ekranu. Kliknięcie w ten niepozorny napis Epic spowoduje, że otworzy Ci się menu z Epicami:

Epic to jak już wspominałem jakaś większa część pracy do wykonania, zawierająca w sobie wiele User Stories. Na przykładzie widać dwa Epic. Nazwałem je w mało wyszukany sposób: „Jakaś duża praca do wykonania” oraz „Kolejna duża praca do wykonania”.

Wróć proszę na chwilkę do poprzedniego zrzutu i zwróć uwagę na User Stories SSD-2 oraz SSD-5. Maksymalnie po prawej stronie zobaczysz kolorowe pola z nazwami tych epiców. To oznacza, że te dwa zgłoszenia zostały do nich przypisane.

Wrócę jeszcze do tego w poźniejszych artykułach kiedy będę omawiał szczegółowo co, gdzie klikać.

Sprint Backlog

Wiesz już, że podczas sprintu pracuje się ze Sprint Backlogiem czyli z zadaniami wybranymi z Product Backlogu. W Jirze wygląda to tak:

W lewym menu, tuż pod Backlogiem znajdziesz opcję Active sprints (1). Po kliknięciu w prawej części zobaczysz Sprint Backlog, czyli to co macie z zespołem do zrobienia w nadchodzącym sprincie. To elektroniczny odpowiednik tablicy z karteczkami, która była szeroko stosowana zanim pojawiły się rożnego rodzaju oprogramowanie pozwalające zastąpić fizyczną tablicę.

Podobnie jak poprzednio do szczegółów obsługi wrócę w następnych wpisach. Na razie zwróć proszę uwagę na to, że Sprint Backlog jest podzielony na kolumny – w tym przypadku są to TO DO, IN PROGRESS, DONE (2). Te kolumny możesz dowolnie edytować i zmieniać – kasować, dodawać kolejne, zmieniać ich nazwy tak żeby dostosować aplikację do swojej pracy.

W każdej kolumnie znajdują się wirtualne „karteczki” (3). Ich wygląd jak wiele elementów Jira może być konfigurowany do pewnego stopnia. Mam na myśli dane jakie wyświetlają.

Increment

Czas na przyrost. W Jirze nie nosi on scrumowej nazwy „increment”, ale sądzę, że doskonale w tej roli sprawdzi się funkcjonalność o nazwie „Releases”:

Releasowi możesz nadać dowolną nazwę, która będzie widoczna w kolumnie Version. Ja nie byłem zbyt oryginalny i po prostu nazwałem je Version 1.0, Version 2.0 itd. Każdy release zawiera w sobie przypisane do niego tickety. Jeśli kliknę np. w Version 1.0 to zobaczę jakie dokładnie tickety wchodzą w skład tej wersji:

Sprawdź co umiesz

Jednym z moich ulubionych sposobów na naukę jest tworzenie pytań do zagadnienia, które poznaję. Poniżej jest zestaw pytań który dla Ciebie przygotowałem. Jeśli 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.

  1. Wymień trzy najważniejsze cechy Product Backlogu
  2. Czym się różni Epic od User Story?
  3. Czy umiesz w Jira odnaleźć Product Backlog dla swojego projektu?
  4. Jaka jest różnica pomiędzy Product Backlog a Sprint Backlog?
  5. Czy kolumny w Sprint Backlog można dowolnie edytować?

 


Cześć,
mam na imię Seweryn.

Z IT oraz telekomunikacją jestem związany zawodowo od 2003 a jako pasjonat od chwili kiedy bardzo dawno temu dostałem pod choinkę swoje Atari 65XE. Mam je do dzisiaj 😉

Więcej o mnie znajdziesz na moim profilu LinkedIn:
https://www.linkedin.com/in/sewerynszatkowski/

Jakiś czas temu zaproponowano mi administrację aplikacją Jira oraz Confluence. Słyszałem o tym oprogramowaniu, widziałem parę filmów na YT, ale nigdy z nich nie korzystałem, o administrowaniu nie mówiąc. Zgodziłem się jednak i nie żałuję🙂

Dlaczego stworzyłem goJira? Zauważyłem, że spora część blogów jakie traktują o tematyce Jira jest prowadzonych przez firmy wdrażające produkty Atlassiana i/lub piszące pluginy. Siłą rzeczy więc blogi takie promują rozwiązania lub usługi firm, które je prowadzą. Jest to moim zdaniem całkowicie normalne i zrozumiałe.

Brakowało mi jednak jakiegoś niezależnego źródła wiedzy o Jira i pozostałych aplikacjach Atlassiana. Miejsca gdzie można dowiedzieć się o konkurujących ze sobą rozwiązaniach, poczytać o ich testach i niezależnych opiniach. Dowiedzieć się czegoś od ludzi, którzy codziennie administrują tymi aplikacjami.

Więcej o mnie znajdziesz tutaj -> Zapraszam


Ten, jak i wiele więcej innych ciekawych artykułów możecie znaleźć na naszej stronie w dziale Blog -> każdego dnia po godzinie 15:00 nowy materiał.

Zapraszamy również do działu Kalendarium, gdzie znajdziecie informację o zbliżających się konferencjach, szkolenia i prezentacjach z różnych dziedzin IT.

Jeśli szukacie nowych wyzwań zawodowych to w dziale Oferty, na pewno znajdziecie coś dla Ciebie!

Zapraszamy na nasz Facebook oraz LinkedIn.