Jakub Raczkowski 
Poznawszy tajniki metodologii pracy możemy śmiało wkroczyć w świat zarządzania projektem i ekipą. Wiedza z dzisiejszego odcinka – czyli znajomość pakietu Atlassian, nie jest obowiązkowa dla programistów, ale pomaga w spojrzeniu na swoją pracę z szerszej perspektywy.
Uwaga! W tej serii zajmuję się opisowym przedstawieniem tematu, a celem jest zapoznanie z zagadnieniem w sposób luźny i zrozumiały dla nowicjusza. W związku z tym wiele elementów siłą rzeczy musi zostać pominiętych. Tych z was, którzy chcieliby się dowiedzieć więcej, zapraszam do źródeł na końcu artykułu.
Ucząc się programowania i tworząc co raz to obszerniejsze programy, w pewnym momencie zauważycie, że sami zaczynacie się gubić w natłoku rzeczy do zrobienia.
Już przy moim pierwszym samodzielnym projekcie: minigierce CleanThemAll (która składa się z zaledwie dwudziestu-kilku klas obejmujących front i backend) wielokrotnie zastanawiałem się:
Czym to ja mam tu się dzisiaj zająć?
Potem przychodzi jeszcze ten etap, kiedy nie dość, że projekt sam w sobie jest potężny to jeszcze dostajecie kompana albo kilku do „pomocy”. Chcecie po prostu coś porobić, dodać coś od siebie do wspólnego kodu, ale zamiast produkować tracicie bezowocnie czas myśląc:
- co jest najpilniejsze?
- czy przypadkiem ktoś już tego nie robi?
- które zadanie najbardziej odpowiada moim kompetencjom?
Każdy kto kiedykolwiek grał w popularnych „Herosów” wie jak ważne jest dowodzenie. I nie chodzi tu tylko o popularny skill „Leadership” dający boost do morale co zwiększa szansę na podwójny atak w danej rundzie.
Odpowiednie dobieranie jednostek do danego zadania to klucz do sukcesu. Wprawny taktyk zwycięży przeważające siły wroga wykorzystując największe atuty swojego zespołu. Krasnoludy są słabe i powolne, ale jeśli otoczymy nimi naszych elfich snajperów to ci zdążą przetrzebić legiony nieprzyjaciela zanim ten się przebije przez zastęp brodatych kurdupli.
Nie inaczej jest w zarządzaniu projektem. Musimy uświadomić sobie jakie są mocne i słabe strony naszego zespołu aby wprawnie delegować posiadane jednostki.
Kontynuując tę swobodną metaforę realiów biurowych na to co znamy z gier możemy powiedzieć, że programiści odwalają główną robotę jako damage dealerzy, ale nie poradzą sobie bez tanków biorących bugi i nieobsłużone wyjątki na klatę – czyli testerów QA. Skryci w cieniu łotrzykowie z DevOpsa otwierają zamki i rozbrajają pułapki, a support HR dba aby drużyna była zbuffowana i wypoczęta.
No i w końcu mamy też mistrzów gry – Product Ownera, Scrum Mastera i Team Leadera – to oni rzucają kośćmi, rozdają questy oraz dbają o to aby fabuła trzymała się kupy.
Zarządzanie tym wszystkim może, owszem, odbywać się analogowo: z ust do ust, zostawiając memo na żółtych karteczkach czy organizując spotkania ze slajdami, białą tablicą i pudełkiem zmazywalnych markerów.
Ale hej, przecież nie po to jesteśmy w IT, żeby robić takie rzeczy jak jaskiniowcy! To wszystko da się zautomatyzować, przyśpieszyć, uprościć. Potrzebne jest tylko odpowiednie narzędzie, na przykład takie jak:
Atlassian to australijska firma założona w 2002 roku i mająca na swoim koncie kilka popularnych aplikacji pomagających w zarządzaniu projektami i zespołem (nie tylko IT). Moje pierwsze zetknięcie z produktem od Atlassian nastąpiło w lutym tego roku kiedy organizowałem swoje zadania podczas pracy nad ITCandidateEvaluator.
Zasada działania Trello jest banalnie prosta i można ją podsumować słowami:
ToDo List
Lista rzeczy do zrobienia. Ot mamy kilka kolumn – do tej najbardziej po lewej wrzucamy pomysły, a następnie przekładamy je co raz bardziej w prawo w miarę postępujących prac, np.
pomysł -> do zrobienia -> w trakcie -> do przetestowania -> gotowe
Jak widzicie nie ma w tym większej filozofii, a użytkowanie można rozpocząć z marszu, bez żadnego tutoriala, całkowicie za darmo. Mamy też opcję upublicznienia naszej tablicy co może być pomocnym uzupełnieniem dokumentacji czy pliku readme projektu.
Sama Jira natomiast to takie baaardzo rozbudowane Trello, przystosowane do pracy w środowisku komercyjnym w metodologii Agile i wieloosobowych zespołach.
Przykładowy projekt w Jirze rozpoczyna się od wybrania metodologii, np. podzielonego na Sprinty Scruma albo mniej restrykcyjnego Kanbana. Kolejnym krokiem jest dodanie zadań, które dzielą się na podkategorie w zależności od tego czego dotyczą i jak bardzo są rozbudowane, np.
- epik to zadanie główne, które może trważ kilka Sprintów i jest bardzo ogólne, dla przykładu: „Stworzyć moduł panelu użytkownika”
- taki epik jest podzielony na stories – „story” to już bardziej konkretne zadanie (np. „panel użytkownika: profil”), a efekt jego ukończenia jest widoczny od strony użytkownika
- story z kolei rozbija się na konkretne zadania czyli „taski„, zrobienie pojedynczego taska może zostać niezauważone przez końcowego użytkownika (np. „dodanie do encji usera atrybutu 'ulubione’ + walidacja za pomocą RegEx”)
- jest jeszcze trochę osobno zadanie „bug” które, jak sama nazwa wskazuje, służy do informowaniu o babolach i jest prośbą o interwencję
Powyższe to zaledwie wycinek możliwości jakie daje Jira. Oprócz tego są tam wirtualne pulpity (tzw. „dashboard„) w przejrzysty sposób pokazujące najważniejsze informacje o przebiegu prac nad projektem.
Jest rozbudowany moduł filtracji zgłoszeń na wszelkie możliwe sposoby (powstał nawet JQL – Jira Query Language czyli wariacja na temat SQL-a).
Dostajemy opcje automatyzacji przebiegu pracy (tzw. „workflow„) – ustawiania reguł tego co można robić, a czego nie (np. nie można przenieść taska bezpośrednio z kolumny „w trakcie” do „gotowe” z pominięciem etapu „do weryfikacji”).
No i jest też cała sekcja poświęcona tylko i wyłącznie zarządzaniu zespołem – dodawanie/usuwanie członków, przydzielanie ról i przywilejów.
Ogólnie rzecz biorąc Jira, jako system administracji projektem i personelem ma wszystko czego do tego celu potrzebujemy. A nawet więcej, jako, że dochodzą nam integracje z innymi produktami Atlassian oraz pluginy łączące Jire z rzeszą innych rozwiązań tj. GitHub, pakiet GoogleDrive czy AWS.
Jeśli chodzi o inne popularne produkty Atlassian z którymi Jira w naturalny sposób łączy się i ułatwia pracę, są to:
Z odcinka poświęconego Gitowi pamiętamy, że Git to program do wersjonowania plików programu, natomiast GitHub to zewnętrzne repozytorium (i sporo więcej, ale to przede wszystkim) gdzie te pliki w różnych wersjach możemy trzymać i je udostępniać. Oczywiście GH nie jest jedyną opcją i oprócz niego mamy choćby jeszcze GitLaba i właśnie BitBucket.
O ile GH jest świetny w przypadku kodu open-source, który jest widoczny dla każdego i każdy może go pobrać i „sforkować”, o tyle w rozwiązaniach komercyjnych (czyli takich gdzie kod powinien pozostać zamknięty) często lepszym zamiennikiem jest BitBucket. Posiada fajne integracje z Jirowymi taskami, a do tego łatwo się tworzy dokumentację dla takiego repo.
Jeśli Jira zarządza projektem i zespołem, to Confluence najlepiej streścić jako system zarządzania treścią. Osobiście najłatwiej mi przyrównać to do WordPressa na którym zamieszczam moje teksty. Tworzymy sobie strony („Confluence pages„) wyglądające jak dokument Worda, albo niniejszy artykuł: jest podział na paragrafy, różne formatowanie, marginesy, kolumny, obrazki itd. Potem daną treść możemy podlinkować w Jirowym tasku jako kontekst zadania, albo możemy stworzyć wiki – dokumentację dla kawałka kodu z BitBucketa.
Bardzo popularnym komunikatorem jest Slack. Oczywiście w pracy możemy używać WhatsAppa, Vibera czy choćby i GaduGadu, ale żaden z nich nie jest nastawiony na zwiększenie produktywności. Tymczasem w Slacku możemy na szybko otworzyć sobie nową dyskusję poświęconą tylko i wyłącznie jednemu z tasków, ba!, Scrum Master może kreować nowe taski bezpośrednio z poziomu Slacka! Opcji jest oczywiście znacznie więcej, a integracja z pozostałymi produktami Atlassian sprawia, że raz trafiwszy do ich ekosystemu trudno się z niego wydostać.
A jak to działa razem?
Powiedzmy, że Product Owner ma pomysł na nową funkcjonalność w przygotowywanej appce. Spisuje go na nowej stronie w Confluence i udostępnia decyzyjnym członkom zespołu. Ci zostawiają swoje komentarze i sugestie, PO poprawia tekst i zatwierdza.
Teraz na podstawie w/w pomysłu powstaje Backlog w Jirze, tworzone są epiki, te dzielone na stories, a każde story ma odniesienie do danego paragrafu w confluence’owym pomyśle.
Omawiana jest strategia branchowania, np. 1 story = 1 branch. W BitBucket tworzone jest repozytorium, a członkowie zespołu tworzą branche do których zostali przydzieleni. BitBucket oferuje również usługi CI/CD na podobieństwo GitHub Actions.
Rozpoczyna się Sprint, pojawiają się commity, pull requesty, prośby o code review – wszystkie powiadomienia automatycznie spływają na Slacka powiązanych osób. W miarę postępujących prac rozbudowuje się dokumentacja projektu na Confluence – część jest pisana ręcznie, ale wiele rzeczy tworzy się automatycznie.
Podsumowanie
To był ostatni z zaplanowanych odcinków naszej serii „Czym jest…?”. Udało mi się omówić wszystko to co chciałem od samego początku (a nawet nieco więcej) i teraz przyszedł czas na podsumowanie oraz kolejne wyzwania.
Następny wpis będzie agregował i analizował to czego się wspólnie nauczyliśmy, wiedza zostanie uszeregowana, podzielę się źródłami skąd ją czerpać i w jakiej kolejności. Będzie tam wszystko to co potrzebujecie się dowiedzieć skończywszy ogarnianie podstaw pierwszego języka – czyli w momencie kiedy już czujecie się programistami, ale nie wiecie co robić dalej, aby udowodnić to potencjalnemu pracodawcy.
Źródła:
Kurs zarządzania projektem w Jira na Udemy (płatne) POL
Integracja Jira z Confluence YT/ANG
Slack – jak korzystać? YT/ANG
