Typy zgłoszeń w Jira standardowe i niestandardowe
Typy zgłoszeń w Jira

Dzisiaj wpis o tym, jak typy zgłoszeń w Jira mogą ulepszyć komunikację w zespole. Pracując w zespole, zespołach, nierzadko pracujemy wspólnie nad jednym tematem, lub w przypadku kilku tematów, czasem gdzieś znajdzie się część wspólna, która łączy pracę zespołów.

Jak w takim razie się komunikować, dodam skutecznie komunikować.

Nie jest to proste, metod jest kilka, każdy pewno będzie miał swoją własną, sprawdzoną, niezawodną. Musimy jednak wziąć pod uwagę „globalność” współpracy. Niezbędne jest narzędzie, które umożliwi wspólne, skuteczne komunikowanie się. Oczywiście można się podeprzeć mailami, dając w kopii wszystkie zainteresowane strony / osoby. Jednak, w gąszczu maili można się w pewnym momencie pogubić, szczególnie gdy dany mail dostał x odpowiedzi. Jego czytelność spada drastycznie, a i wyszukanie czegokolwiek jest wielce utrudnione. Dodatkowo generujemy duży ruch i niepotrzebnie zaśmiecamy skrzynki, czasem zbędnymi informacjami.

Z pomocą przychodzą nam specjalistyczne narzędzia takie jak Jira. Przyjęło się używać Jira jako jednego z głównych i podstawowych narzędzi do współpracy zespołowej w przypadku projektów informatycznych. Można za jego pomocą śledzić bieżące postępy pracy zespołu, zgłoszone problemy, ich status itp. Może też być wykorzystywane przez menadżera jako narzędzie umożliwiające kontrolę pracy zespołu.

Typy zgłoszeń w Jira

Ogólnie, Jira stosujemy do zakładania „zgłoszeń”, jako elementów informujących o postępach pracy zespołu. Mamy więc do wyboru następujące podstawowe rodzaje zgłoszeń: Bug, Story, Task, Epik, Podzadanie. Nie są to jednak jedyne możliwe typy zgłoszeń, ponieważ możemy spotkać się również z typami zgłoszeń: Improvement, Pytanie do analityka, Change request. Dodatkowo zgłoszenia typu błąd możemy podzielić na Internale i Externale.

Menu wyboru typu zgłoszenia w Jira
Typy zgłoszeń w Jira

Każdy typ zgłoszenia jest oznaczony czytelną ikoną graficzną. Dodatkowo każdy typ zgłoszenia ma przypisane konieczne i możliwe do wypełnienia pola. Ilość pól, rodzaj zawartych w nich informacji zależy od administratora Jira, który definiuje w panelu administratora wymagania odnośnie do każdego zgłoszenia. Temat edytowania pól w zgłoszeniach jako administrator opisany jest w jednym z wpisów na tym blogu. Zapoznaj się z nim, jeśli chcesz dostosować swoje środowisko pracy w Jira.

Co oznacza konkretne zgłoszenie?

Każde zgłoszenie w Jira to element opisujący pracę zespołu. Patrząc od najwyżej w hierarchii położonego pojęcia (jako największego, najbardziej złożonego) mamy następujące typy zgłoszeń w Jira.

Epic

Jest zbiorem wszystkich User Stories składających się na jedną funkcjonalność. Dobrze, ale po co nam to? Biorąc pod uwagę zwinne (Agile) podejście do pracy, to prace prowadzimy i realizujemy małymi partiami, a na duży kawałek naszego produktu może składać się dziesiątki lub setki różnych User Stories. Potrzebujemy zatem wiedzieć, kiedy złożona całość jest już gotowa. Patrzymy na to oczami użytkownika końcowego. Systematycznie dostaje on oddawane kolejne części oprogramowania, na których może pracować i zgłaszać usprawnienia, lub wprowadzać zmiany. Możemy tu określić, kiedy dany fragment kodu / oprogramowania będzie „dostatecznie gotowy”, aby zabrać się za kolejny. Dla przykładu przyjmijmy, że naszym Epikiem jest organizacja targów w Krakowie, na których będziemy wystawiali i promowali nasze produkty.

Story

Praca rozbijana jest zwykle na duże zadania, czyli Story. Są to historyjki użytkowników, które zawierają krótki i uproszczony zapis i opis funkcji w danym systemie / module. Są one „opowiadane” z poziomu użytkownika, czyli finalnego odbiorcy danej funkcjonalności. Historyjki powinny być na tyle szczegółowe, aby zespół programistów wiedział, czego oczekujemy (jako użytkownik (X) chcę, aby funkcja (Y) spowodowała rezultat (Z)). Historyjka powinna być na tyle ogólna, aby nie ograniczać kreatywności programistów. (naszym Story będzie zatem wymyślenie i opracowanie szaty graficznej i przestrzennej stoiska targowego).

Task

Zadanie do wykonania w obrębie danej historyjki, dzielące ją na mniejsze elementy (w naszym przypadku takim Taskiem może być lista mebli i wyposażenia, które powinno się znaleźć na stoisku targowym).

Podzadanie

Jeżeli pojedynczy Task nie może zostać przydzielony jednej osobie, to jest on rozbijany na mniejsze Podzadania (Sub Task). Zadanie dzielimy, dopóty dopóki będziemy w stanie dla takiego pojedynczego Podzadania jasno określić jaką pracę i jaki czas musimy włożyć, aby dane Podzadanie wykonać. W omawianym przykładzie organizacji stoiska targowego takim Podzadaniem może być określenie ilości poszczególnych mebli – biurek, krzeseł, lamp, materiałów reklamowych, darmowych gadżetów do rozdawania odwiedzającym.

Bug (Błąd)

Finalnie przechodząc w dół piramidy i wykonując poszczególne podzadania, sprawdzamy, czy funkcjonalność danego modułu jest zachowana, czy spełnia wymogi specyfikacji, oraz czy wykonując daną ścieżkę, nie napotkamy błędu, który uniemożliwi poprawne działanie danej funkcji. W naszym przypadku Bugiem może być zgłoszenie, że wybrany stół nie mieści się w przestrzeni, jaką dostaliśmy do wykorzystania na naszych targach.

Zgłoszenia niestandardowe w Jira, z którymi możesz mieć styczność jako Tester.

Pytanie do analityka

Jest to task przydzielany do analityka, który następnie ten task przerabia. Analityk odpowiada w komentarzu na pytanie udzielone w description, następnie zamyka zgłoszenie.

Change request

To typ zgłoszenia, w którym klient chce by funkcjonalność już istniejąca, została zmieniona. Ten tym zgłoszenia traktujemy jak propozycję zmiany, która nie oznacza natychmiastowego przystąpienia do pracy nad nią. W momencie, gdy zaczynamy pracę nad tym zgłoszeniem, zakładamy zgłoszenie typu Improvement.

Improvement

Zgłoszenie utworzone do zmiany zaproponowanej przez klienta w momencie, gdy zaczynamy pracę nad tym zgłoszeniem.

Podział błędów na internel i external

Jeśli wrzucamy wszystkie błędy do jednego dużego worka, dochodzi do tego, że trudno jest wyłapać ich źródło. Dlatego często dzieli się zgłoszenie typu Błąd na dwa internal i external.

Internal

Jak sama nazwa podpowiada, internale to błędy zgłoszone wewnętrznie w ramach testów. Błędy tego typu powinny być rozwiązane w ramach Sprintu. Zgłoszenia typu Internal przesyłamy jako „Known issue”, po to by klient wiedział, że w aplikacji coś nie działa. Tak, dla tych którzy się zastanawiają, klient powinien zostać poinformowany o błędach w aplikacji :).

External

Zgłoszenia utworzone przez klienta, są to na przykład błędy, które my nie wyłapaliśmy przed wystawieniem wersji. Jednym z obowiązków testera jest komunikacja z klientem i weryfikacja, czy zgłoszenie jest faktycznym błędem.

Ogólnie można powiedzieć, że zachowując strukturę zgłoszeń w Jira, przygotowujemy pracę dla całego zespołu. Najpierw wyznaczając ogólne cele strategiczne, następnie dzieląc je na mniejsze zadania, aż do uzyskania na tyle małych modułów, dla których jesteśmy w stanie oszacować niezbędny nakład pracy, oraz przeprowadzić testy danej funkcjonalności.

Jeżeli wpis ten jest pierwszym dotyczącym Jira, z jakim masz styczność, to zachęcam do zapoznania się z pozostałymi tekstami dotyczącymi pracy z Jira:

Dodaj komentarz