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.
