Jak zabić Agile przy użyciu Jira? #2

utworzone przez | Lip 22, 2018 | Blog, Scrum | 6 Komentarze

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?