with Jeden komentarz

Moje pierwsze spotkanie z Jirą było koszmarne.

Jira to narzędzie służące zespołom IT do zarządzania wymaganiami. Jest jednym z najpopularniejszych na rynku, więc było kwestią czasu, aż się z nim wreszcie zetknę.

Dołączyłam do zespołu, który stał przed bardzo trudnym zadaniem okiełznania klienta, o którym powiedzieć “chaotyczny i kontrolujący”, to w sumie nic nie powiedzieć. Wiele backlogów, jeszcze więcej tablic… masa “papierologii”, która w tym przypadku była mało materialna, ale ideę rozumiesz 🙂 Wpisywanie niezliczonych ilości labelek (od ang. labels – etykiety), przygotowywanie zestawień, kontrolowanie, czy wszyscy wpisali to, co mieli wpisać… Milion wymagań od wielu interesariuszy nigdzie nie spisanych i nie usystematyzowanych. Coś strasznego!

 

Nie byłabym sobą, gdybym się po prostu poddała. To przecież tylko narzędzie! A skoro jest wykorzystywane przez tyle firm na świecie, to nie może być takie złe, prawda?

 

Stopniowo zaczęłam opanowywać podstawowe funkcje, jakie wiążą się z Jirą. Zajęło mi to dosłownie chwilę. W następnej kolejności zabrałam się za te bardziej zaawansowane. Chyba nigdy nie doszłam do poziomu eksperckiego, bo tak naprawdę, nigdy nie było mi to potrzebne. Jira nawet w swojej podstawowej odsłonie potrafi ułatwić życie zespołu, tylko trzeba wiedzieć, jak to zrobić 🙂 

 

Z tygodnia na tydzień było coraz lepiej. 

 

Nauczyłam się pisać dość sprawnie query (ang. zapytania), które pozwalały mi wyfiltrować z chaosu te informacje, których potrzebowałam. Odkrycie funkcjonalności subskrypcji na query – to było coś! Okazało się, że Jira sama mnie poinformuje, jeżeli coś nie będzie spełniać zdefiniowanych wartości. Cóż za ulga! Mogłam przestać latać jak szalona po ludziach i sprawdzać co i jak. Mogłam zająć się wreszcie ważnymi i ciekawszymi tematami.

 

Kolejnym wielkim krokiem było odkrycie połączenia między Jirą i Confluence.

Wreszcie zaczęłam rozumieć, czemu te narzędzia często są używane razem! Odkryłam, że te wszystkie query, które tak pięknie już nauczyłam się pisać, można wykorzystać w zupełnie nowy sposób. Można na przykład stworzyć strony, na których:

  • zbierzemy wszystkie zgłoszone bugi (w tym  przypadku ze wszystkich backlogów), a tym samym w przejrzysty sposób wizualizuje, co jest priorytetem
  • przygotujemy raport, który pokaże kto jest najbardziej obciążony 
  • pokażemy na jakim etapie przygotowania release jesteśmy 
  • pokażemy status backlogu – z wylistowanymi notkami, ich statusami i informacjami, jakie są następne kroki do podjęcia
  • stworzymy raport kontrolny, które notki nie są w statusie, w którym powinny być (tzn. ich status w Jira nie odpowiada rzeczywistości)

 

Można zorganizować sobie pracę nad backlogiem w taki sposób, żeby każdy wiedział co się dzieje, nawet przy najbardziej “dynamicznym” backlogu. Trzeba tylko trochę pokombinować 🙂 

 

Chcesz wiedzieć więcej?

Opisz w komentarzu, z czym się mierzysz, a ja postaram się Ci pomóc. 

Koniecznie obserwuj mnie na SM, gdzie niedługo pojawią się wpisy i nagrania dotyczące tych programów i ich praktycznego wykorzystania.

Spodobało się? Podziel się!

Jedna odpowiedz

  1. Gabriel VD
    | Odpowiedz

    Bardzo fajny wpis, widziałem ostatnio podobne artykuły i ten się wyróżnia na tle innych oraz jest wart uwagi. Konkretnie objaśniony temat. Bardzo przyjemnie się go czyta. Czekam na takich więcej 🙂

Zostaw Komentarz