- Jak zdać egzamin Professional Scrum with Kanban PSK I? — 06/03/2024
- Czy nadgodziny dowiozą na czas? — 01/10/2020
- Przewodnik po EBM po polsku — 21/07/2020
Jak zabić Agile przy użyciu Jira? #2
Time Tracking i timesheet w Jira
Nie ma bardziej skutecznego sposobu na skupienie na szacowaniu w jednostkach czasu i fikcyjnego raportowania jak 8h dziennie jak wdrożenie dodatku Tempo. Tempo skutecznie zamienia Jira na narzędzie do time tracking i timesheet. Oprócz skupienia się na zadaniach powstaje potrzeba rozpisania gdzieś 8 godzin.
Pomimo tego, że mamy 2018 i są już dostępne badania, że ludzie pracują nad zadaniami maksymalnie 5,5 h dziennie, to nadal wymaga się od ludzi zaraportowania 8h.
Oczywiście zaczyna się też raportowanie absolutnie wszystkiego. Każda rozmowa z zespole, każde wydarzenie scrumowe, każde spotkanie musi mieć taska, na którego można logować czas. Trzeba pomóc koledze z zespołu? A jak ja to zaloguję? Mamy taska na refactoring? Oczywiście jak już mamy logowanie czasu, to od razu można sprawdzić czy zespół myli się w oszacowaniach. A jak się myli to wypada go ukarać, a przynajmniej zrobić awanturę.
Jaka jest wartość w logowaniu czasu? A co z czasem na implementację ulepszeń, slack time?
Nie dostosowuj Jira lub dostosuj absolutnie wszystko
Jedna dysfunkcja dotycząca dostosowywania Jira przyjmuje postać dwóch skrajności. W jednej strony spotykałem się z korzystaniem z Jiry prosto z pudełka na domyślnych workflow, formularzach i uprawnieniach. “Plain vanila” Jira jest do wszystkiego czyli do niczego. Często wprowadzanie dodatkowych komentarzy, konwencji nazewnictwa, etykiet prowadzi do kompletnego zgubienia się w systemie.
Z drugiej strony można też dodać tyle własnych pól, formularzy na każdą okazję i przepływów pracy przypominających spagetti, że przestaną działać podstawowe mechanizmy. Można dodać automatyczne walidatory i triggery do każdego kroku. Można też udostępnić wszystkie konfiguracje wszystkich zespołom. Wówczas dodanie nowego issue lub przesunięcie dalej zaczyna przypominać planowanie lotu na Marsa.
A gdzie dążenie do prostoty i zarządzanie złożonym procesem poprzez upraszczanie?
Nie dotykaj Jira, bo zepsujesz
Jira staje się ważnym centrum życia korporacyjnego, więc trzeba ją chronić. Jira potrzebuje ochrony głównie też przed developerami, czyli ludźmi, którzy budują podobne, złożone systemy w tydzień. Co za tym idzie, powołuje się rolę administratora, który będzie bronił dostępów i modyfikacji jak Cerber bram piekła. W poważniejszych instytucjach tworzony jest cały zespół do spraw Jira. Dziesięć lat temu sami konfigurowalismy co potrzebowaliśmy, a teraz akazuje się, że są nawet certyfikaty dla Atlassian Jira. Jeśli czegoś potrzebujesz, to złóż ticket w Jira i może, ale na prawdę może jak kilka osób Ci zatwierdzi, to modyfikacja zostanie wykonana. Ostatnio spotkałem się nawet z komitetem od Jira. Tickety są omawiane raz na dwa tygodnie i osoby, które totalnie nie rozumieją Twojej pracy decydują czy to czego potrzebujesz zostanie zrobione. Mogą też decydować jaki naprawdę workflow potrzebujesz. Dziwnym trafem większość decyzji brzmi “wykorzystaj to co jest obecnie w systemie”.
Projektem (właśnie, dlaczego to się nazywa projekt) w Jira zarządza administrator. Tylko manager lub project manager może tworzyć taski i przypisywać ludzi. Wszystkie pola i workflow są ustawiane centralnie z naciskiem na wykorzystanie już dostępnych. Bardzo szybko odbiera się też zespołom uprawnienia do usuwania issue i do zmian masowych (bulk change).
Dla kogo jest Jira i komu ma służyć najlepiej? Co z eksperymentowaniem i ulepszaniem ze Sprintu na Sprint? Jak się ma do tego waste of delay z Lean?
Czytam kolejną już część o JIRA i mam wrażenie, że te wpisy są bardziej o błędach ludzi używających JIRA, a nie o samym narzędziu. Ciężko winić Atlassiana za to, że ktoś w firmie stworzył taki lub inny proces do zarządzania konfiguracją. Większość tych uwag będzie prawdziwa, niezależnie od tego jakie narzędzie się wstawi w tytule.
JIRA to narzędzie, nic więcej. Można jej używać mniej lub bardziej umiejętnie, ale przede wszystkim trzeba wiedzieć do czego. To trochę tak, jak obwiniać śrubokręt imbusowy, że nie pasuje gdy ma się śrubki krzyżowe. Wtedy wpis mógłby mieć tytuł “Jak zabić wkręcanie śrubek przy użyciu śrubokręta.”
Jeśli celem tych wpisów jest zwrócenie uwagi na to, że ważniejsza jest praktyka, a nie narzędzia. I że lepiej zaczynać od procesu “analogowego”, to z tym się w pełni zgodzę. Tylko nie wiem czym akurat JIRA zawiniła :-) Podejrzewam jakieś uprzedzenia ;-)
Michał, Jira jest po prostu najbardziej popularna i kojarzona automatycznie z Agile. Oczywiście, że śrubokrętem można skręcić samochód albo wybić oko. “A fool with a tool is still a fool”.
W pełni się zgadzam. Co do zgłoszeń ticketów do Atlassiana, to faktycznie trwa to wieki i czasem w ogóle nie ma nadziei:)
Ale jeśli potrzebna jest zmiana w konfiguracji przez admina instancji, to “czego potrzebuje dana osoba w swojej pracy” często nie zależy od danej osoby. Ale od kierownika czy grupy definiującej dany proces.
Proces można zamodelować jak tylko się chce. Pytanie czy jest poprawny, czy może ktoś nie do końca używa go w sposób w jaki powinien…Jira to tylko narzędzie.
Albo dochodzi tu czynnik 40 milionów selekcjonerów — nikt mi nie powie jakiego procesu mam używać, bo przecież pracuję 5 lat i sam wiem najlepiej:)
Krystian, Twoje artykuły atakujące Jirę super się czyta, zwłaszcza przy kawce :) Jak wiesz ja jako wielki fan Jiry i Atlassiana uśmiecham się pod nosem, bo wszystkie te przykłady są z życia wzięte. Co więcej są podręcznikowymi przykładami jak nie administrować Jirą albo inaczej, jak Jira nie powinna być administrowana lub jest administrowana przez ćwierć etatowych adminów, którzy ślepo słuchają biznesu i nie współpracują z zespołami, “byle zamknąć taska”. Po części wynika to z tego, że są to wciąż młode systemy w Polsce i mało jest szkoleń z tej dziedziny (kolejnym hitem jest, ale po co cert do Jira lub szkolenie ;)). Moja opinia jest taka, że w ciągu najbliższych kilku lat Jira dogoni SAP/Salesforce, a szkolenia dla tych systemów nikogo nie dziwią, i kosztują grube koperty zielonych banknotów. A jak mówię, że u nas w firmie mamy dedykowana osobę, która głównie projektuje rozwiązania i wykorzystanie tych narzędzi w IT i Biznesie w odpowiedni sposób to w Polsce patrzą na mnie jak na dziwaka :D, “A fool with a tool is still a fool”.
Hubert, dziękuję za komentarz.
Panie Krystianie, świetnie się czyta te artykuły, nie da się ukryć, że są z życia wzięte. Od siebie dodam, że nie odebrałem ich jako ataku na Jire — w naszej organizacji korzystamy z Redmine z Agile plugin i gdyby zrobić replace(“Jira”,“Redmine”) nic by się nie minęło z prawdą. Czekam na kolejną część!
Dziękuję za komentarz! Cieszę się, że to co robię ma wartość.