- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Jak zabić Agile przy użyciu Jira? #1
Bardzo możliwe, że jak każde narzędzie do zarządzania zgłoszeniami (ang. issue management) Jira wpadłaby w tą samą kategorię, co Bugzilla, Redmine czy Track. Ale w pewnym momencie pojawił się dodatek Green Hopper pozwalający na wyświetlanie zgłoszeń w formie tablicy i generowanie wykresów spalania. W czasie wzrostu zainteresowania Scrumem, to była bardzo dobra propozycja. Później Green Hopper zmienił się w dodatek Jira Agile, a obecnie już nierozłącznie jest to pakiet Jira Software.
Niektórzy Agile Coache otwarcie zabraniają Jira albo nawet zajmują się wycofywaniem Jira z organizacji (tak zwane unjirafying). Dosyć szybko Jira zamienia się w znienawidzoną zdzirę, która po cichu zaczyna zmieniać kulturę organizacyjną zupełnie nie w tą stronę, w którą potrzebujemy.
Poniżej przedstawiam antywzorce i dysfunkcje organizacyjne związane z Jira, z którymi spotkałem się osobiście. Niektóre są okraszone autentycznymi cytatami. Zachęcam do dorzucania kolejnych propozycji w komentarzach.
Jira powiedz,gdzie są moje “majtaski”?
Majtaski czyli my task po angielsku szybko może stać się centrum zarządzania czasem dla członków zespołu. Jira pozwala na przypisywanie zadań do ludzi. Wraz z pojawieniem się Jira w organizacji pojawia się kult zadań. Często można usłyszeć “Nie mam na to taska” jako wymówkę, żeby komuś nie pomóc. Jira wzmacnia to zachowanie oferując automatycznie widoki i filtry pokazujące zadania dla zalogowanej osoby. A co kiedy nic się nie wyświetla w widoku? Masz dzisiaj wolne, można pooglądać gołe koty w internecie.
Typowym pomysłem jest wykorzystanie opcji Quick Filter do ograniczania widoku na tablicy to własnych zadań albo tworzenia własnej tablicy tylko dla siebie. Zaraz po wprowadzeniu Jira pojawia się seria filtrów z inicjałami albo nazwiskami osób w zespole. Od razu pojawia się pytanie “A co jeśli issue jest nieprzypisane (ang. unassigned)? Jest ryzyko, że nikt go nie zobaczy i nikt nie zrobi. Przypisz zatem issue do kierownika zespołu albo do Scrum Mastera.
A co z pracą zespołową? A co ze wspólnym skupieniem na celu i dostarczaniem wartości?
Czy na pewno każdy jest zajęty?
Czasami potrzeba sprawdzania przypisania zadań nie pochodzi z zespołu, ale od kierowników. Jira staje się narzędziem kontroli nad “zajętością” poszczególnych osób. Czy każdy ma przypisanego taska? Jira staje się idealnym narzędziem do zarządzania zespołem, projektem i organizacją przez przestarzałe podejście utylizacji zasobów. Jak to mówią sprawna utylizacja zasobów jest podstawą egzekucji projektów. Skrajnym przykładem jaki widziałem był pomysł kierownika projektu. Została utworzona na tablica scrumowa w Jira (na papierowej kopii też) swimlanes (czyli poziomego grupowania) per osoba. Każdy członek zespołu miał swój wiersz, w którym powinien wisieć przynajmniej jeden przypisany task. Jeśli było to małe zadanie, to należało wziąć przynajmniej dwa. Daily Scrum był podsumowywany pytaniem “czy każdy ma taska?” A co jeżeli kolega potrzebuje pomocy? Niestety nie mogę Ci pomóc, bo „Nie możemy pracować nad tym razem, bo Jira nie pozwala przypisywać dwóch osób do taska”.
Skoro interesuje nas przypisywanie zadań, to czy trzeba czekać aż do Daily Scrum? W sumie w tym momencie to już tylko daily stand-up i status. Można przecież przypisać zadania od razu na planowaniu Sprintu, albo iteracji Kanbana. Jeżeli celem zarządzania procesem ma być optymalizacja utylizacji zasobów, to oczywiście można od razu sprawdzić czy każdy ma upchane zadań pod sam korek. Wszystko trzeba zaplanować z góry.
Jeżeli interesuje nas pełna kontrola i tworzenie planów daleko idących w przyszłość, to możemy zainstalować sobie dodatek Jira Portfolio. Dzięki temu można na reszcie tworzyć wykresy Gantta w Jira w oparciu o dostępność poszczególnych członków zespołu. Każdy PM się ucieszy.
A co na to empiryczna kontrola procesu (empiryzm)? Jak się ma do tego samo-organizujący się zespół? Jak się ma do tego podejście adaptacyjne, Agile?
User Story na siłę
Co prawda Jira nie wymusza korzystania z koncepcji User Story, ale jest to najczęściej spotykany Issue Type. Tworzymy nowy ticket i pojawia się formularz User Story. A jak już wyskoczy formularz, to trzeba się zastanowić jak to napisać w formie User Story. Widocznie o to chodzi w Agile. I potem mamy takie kwiatki jak “Jako użytkownik”, “Jako serwer Tomcat”, “Jako Product Owner” chcę żeby coś było zrobione, bo tego potrzebuję. Po co się tak męczyć? W Product Backlog mogą znajdować się dowolne typy elementów.
Gdzie jest wartość w pisaniu User Story tam, gdzie zupełnie do tego nie pasuje?
My korzystamy z JIRA, ale zupełnie nie uzupełniemy user story. Czasami po samym tytule wiadomo co jest do zrobienia. Albo po prostu w opisie jest jedno zdanie wyjaśniające. Ale na planowaniach też jednak staram się zadbać, żeby każdy deweloper miał potencjalnie wystarczającą liczbę zadań, bo skoro mam specjalistę od CSSów to w niczym nie pomoże on backendowcowi, nawet jakby bardzo chciał ;)
Najbardziej rzeczowy wpis o taskokracji jaki kiedykolwiek czytałem! Z niecierpliwością czekam na wpis #3, ponieważ zdiagnozowanych przez Pana problemów doświadczam osobiście, ale pomysłów na alternatywę organizacja ‘nie potrzebuje’.
Jira to tylko narzędzie, które można wykorzystywać na 100 sposobów. To, o czym piszesz to patologiczna kultura organizacyjna. Tak samo ludzie, którzy nie rozumieją agile mówią, że jest przereklamowany.