Ktoś mądry kiedyś powiedział, że granice naszego świata wyznaczają słowa jakie znamy. Albo coś w tym rodzaju. Jakkolwiek by nie było zgadzam się z tym. Zawsze uważałem, że żeby nauczyć się nowej umiejętności, czy wejść w nowe środowisko, pierwszą rzeczą jaką powinienem zrobić to nauczyć się języka jakim się posługują ludzie, którzy już w tym siedzą. Poniżej będę stopniowo budował słownik terminów związanych z tematyką z jaką możecie się spotkać w przypadku Jira. Jedna uwaga. W wielu przypadkach napisanie dokładnej definicji jakiegoś zagadnienia jest niezmiernie trudne ze względu na mnogość opinii, podejść czy toczących się dyskusji. Także stopień skomplikowania wielu zagadnień jest na tyle złożony, że opisanie ich w paru zdaniach jest zadaniem karkołomnym – wiele z poniższych haseł same w sobie są tematem na artykuł, książkę lub wykład. Nie traktuj zatem poniższych informacji jako jedynego słusznego źródła wiedzy a raczej jako wskazania w którym kierunku należy prowadzić dalsze poszukiwania.
A | B | C | D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
W |
X |
Y |
Z
Add-on
Patrz: App
App
App, w starszych wersjach Jira nazywany add-on to dodatek, który możesz doinstalować do Jira. Dzięki niemu bazowa aplikacja uzyskuje nowe funkcjonalności lub rozszerza możliwości już istniejących. App możesz pobrać ze strony Atlassian Marketplace. Niektóre z nich są płatne, niektóre darmowe. Jeśli posiadasz odpowiednie umiejętności programistyczne możesz samemu napisać App. Często też jest używana nazwa plugin.
Backlog
Jeden z artefaktów Scrum. To lista wszystkich zadań, które muszą być wykonane w ramach projektu. Cechą charakterystyczną backloga jest dynamiczność – ciągle zmienia swoją zawartość. Jedne elementy są dodawane, inne usuwane ze względu na to, że zostały albo wykonane albo klient zdecydował, że tego nie potrzebuje. Backlog jest priorytetyzowany na zasadzie – im wyżej element znajduje się na liście tym jest ważniejszy.
Dashboard
…
Epic
…
Issue
To ogólna nazwa sposobu w jaki w Jira zapisujemy informacje o pracy do wykonania. W zależności od kontekstu w jakim się znajdujemy issue może mieć różne nazwy. W Jira Service Desk możemy mówić o incydencie, awarii, zadaniu, zakupie. W Jira Software o epic, story, task czy bug. W Jira Core może to być zadanie, pod-zadanie itd.
Jira po zainstalowaniu oferuje predefiniowane nazwy issue. Pozwala też stworzyć nam dowolną nazwę taką żeby pasowała nam w danym projekcie czy sytuacji. Np, wdrożenie na UAT czy zakup biurowy.
Po polsku często używa się określenia zgłoszenie.
Porównaj: Request
OLA
Od angielskiego – Operational Level Agreement. Umowa wewnątrz danej organizacji, która określa zasady współpracy pomiędzy poszczególnymi grupami składającymi się na support. Można powiedzieć, że to takie SLA tylko wewnątrz organizacji. Zasady OLA pomiędzy zespołami pozwalają na dotrzymanie umów SLA. Klienta nie interesuje wewnętrzna struktura organizacyjna usługodawcy. Zgłasza awarie i oczekuje jej rozwiązania w czasie określonym w SLA. Poniżej dwa scenariusze opisujące wykorzystanie OLA i brak tej umowy.
Scenariusz 1:
Umowa SLA określa, że awaria zgłoszona przez klienta powinna zostać rozwiązana w ciągu 2h. Zgłoszenie trafiło na pierwszą linię Service Desk, gdzie nikt się nim nie zajął przez 1h 45m. W chwili kiedy zbliża się czas rozwiązania zgłoszenia, pracownik pierwszej linii stwierdza, że nie jest w stanie sam rozwiązać problemu i przekazuje go do 2 linii wsparcia, która ma tylko 15 minut na usunięcie problemu. Problem okazuje się na tyle skomplikowany, że 2 linia nie jest w stanie rozwiązać zgłoszenia przez 15 minut, SLA nie jest spełnione, klient jest zirytowany, firma płaci kary za niedotrzymanie SLA. 1 linia nie uważa, że jest winna bo przecież przekazała zgłoszenie zgodnie z procedura do 2 linii. 2 linia obwinia 1 za to, że dostała zgłoszenie w ostatniej chwili.
Scenariusz 2:
Umowa SLA określa, że awaria zgłoszona przez klienta powinna zostać rozwiązana w ciągu 2h. Zgłoszenie trafiło na pierwszą linię Service Desk. Umowa OLA określa, że każde zgłoszenie, które trafiło na 1 linię powinno zostać zweryfikowane w czasie nie dłuższym niż 30 minut i jeśli zachodzi taka potrzeba przekazane do 2 linii. W przedziale 30 minut po weryfikacji, pracownik 1 linii stwierdza, że nie jest w stanie sam rozwiązać zgłoszenia i przekazuje je do 2 linii, która ma 1,5h na rozwiązanie problemu co okazuje się czasem wystarczającym do usunięcia awarii.
Porównaj: SLA
Product Owner
…
Plugin
Patrz: App
Request
To nazwa specyficzna dla Jira Service Desk, gdzie jedna z funkcjonalności – Portal Klienta pozwala użytkownikom rejestrować zgłoszenia dla zespołów supportowych.
Wiele różnych request może być zmapowanych po stronie Service Desk do jednego issue. Przykładowo to co w Portalu Klienta jest widoczne jako Pomoc IT, Zadanie, Problem z drukarką po stronie Service Desk dla jego pracowników może być widoczne jako jeden rodzaj issue o nazwie Task.
Porównaj: Issue
Scrum
…
SLA
Od angielskiego – Service Level Agreement. Jest to najczęściej element umowy, czasem osobna umowa, podpisywanej pomiędzy usługobiorcą a usługodawcą, w której usługodawca zobowiązuje się do świadczenia usługi na pewnym uzgodnionym pomiędzy stronami poziomie. SLA może obejmować takie elementy jak dostępność usługi (np. SLA na poziomie 99,99% oznacza, że usługa może być niedostępna miesięcznie 4m 23s). W przypadku usług telekomunikacyjnych SLA może zawierać także takie parametry jak przepływność gwarantowana, opóźnienia w sieci etc.
SLA może zawierać także określenie rodzajów zgłoszeń jakie usługobiorca może zgłosić do usługodawcy (awarie, zadania) oraz czasy reakcji usługodawcy na te zgłoszenia – np. podjecie działania w ciągu 15m, usunięcie awarii w ciągu 1h etc.
Porównaj: OLA
Scrum Master
…
Sprint
…
Story
…
Ticket
…
Workflow
…