Dzisiaj opowiem Ci o pierwszej ważnej części Scruma – rolach. Są trzy. Ludzie w nich występujący mają odmienne obowiązki, zadania, patrzą na projekt z innej perspektywy. Jak się zaraz przekonasz role mogą być jednoosobowe lub wieloosobowe. Pamiętasz jak w poprzedniej lekcji pisałem, że żeby móc mówić, że się działa zgodnie ze Scrumem trzeba spełnić pewne zasady? Obsadzenie ludzi w rolach jest jedną z nich.

Product Owner

Czyli mówiąc po naszemu – właściciel produktu. Jak sama nazwa wskazuje jest, to osoba odpowiedzialna za produkt jaki wytwarza zespół. Słowa klucze w przypadku Product Ownera to: wartość, product backlog, biznes, umocowanie.

• Wartość. W tym przypadku nie mówimy raczej o wartości materialnej produktu, że kosztuje tyle i tyle, chociaż można postrzegać produkt także w tym ujęciu. Poprzez wartość mamy raczej na myśli to co daje on naszemu Klientowi, jakie jego problemy rozwiązuje, co pozytywnego wnosi do jego organizacji. Zadaniem Product Ownera jest dążenie do maksymalizacji wartości produktu i pracy zespołu. Inaczej mówiąc – Product Owner pilnuje, żebyśmy nie oddali Klientowi czegokolwiek, byleby coś oddać. To „coś” ma wnieść wartość.
  
• Product backlog. Dokładniej o backlogu produktu i jego elementach będziemy mówić w następnych lekcjach. Na razie w kontekście Product Ownera wspomnę jedynie, że to on za niego odpowiada. To jego obowiązkiem jest tworzenie zadań do wykonania w taki sposób, żeby były zrozumiałe dla ludzi, którzy mają je realizować. Ma nie tylko tworzyć zadania, ale także dbać o ich priorytetyzację i wiedzieć dokładnie co trzeba zrobić. W tym kontekście Product Owner musi być dostępny dla zespołu po to żeby wyjaśniać wszelkie wątpliwości co do tego co zespół ma wytworzyć.
  
• Biznes. Product Owner to osoba, która jest łącznikiem, albo mówiąc w mniej wyszukany sposób, stoi w rozkroku pomiędzy biznesem a techniką. Z jednej strony musi rozumieć biznes czyli to jak działa nasza organizacja. Jaki ma produkt, na czym zarabia. Jednocześnie musi to samo rozumieć z perspektywy naszego Klienta, dla którego budujemy produkt. Musi umieć wejść w buty Klienta, rozumieć czego on potrzebuje. Z drugiej strony musi rozumieć nasz produkt od strony technicznej, wiedzieć jak jest zbudowany, co jest możliwe a co nie. Oczywiście nie mówię tu o wnikaniu w detale techniczne, niemniej jednak jego wiedza techniczna na temat tego co jest budowane musi być spora.
  
• Umocowanie. Aby móc działać sprawnie, Product Owner musi mieć prawo do podejmowania decyzji co do kształtu, wyglądu produktu. Przynajmniej w pewnym jego zakresie. Nie może być tak, że podczas rozmowy z Klientem nie jest w stanie nic zadecydować bo ciągle musi się konsultować z kimś innym.

Scrum Master

Z powyższego opisu Product Ownera może jawić się obraz kogoś kto „ciśnie”. Żeby robić jak najwięcej, jak najszybciej i jak najlepiej. I w pewnym sensie to prawda. Dlatego Scrum ma kogoś, kto ma stanowić przeciwwagę dla Product Ownera. To Scrum Master.

Oczywiście osobie w tej roli też powinno zależeć na tym samym co Product Ownerowi, w końcu grają w tej samej drużynie. Z tą jednak różnicą, że Product Owner w ferworze walki może przejawiać skłonności do tego aby pomijać niektóre elementy Scruma. Zmieniać zakres sprintów, pomijać niektóre rytuały i tak dalej. O tym wszystkim będzie w następnych lekcjach. Scrum Master ma temu zapobiec. Skoro gramy zgodnie z zasadami Scruma to trzeba ich przestrzegać. Więc jak Product Ownera poniesie i zacznie naciskać, to rolą Scrum Mastera jest sprowadzić go na ziemię. To między innymi dlatego tak istotne jest żeby w rolach Scrum Mastera i Product Ownera obsadzać dwie różne osoby. W przeciwnym przypadku groziło by to rozdwojeniem jaźni 😉 Słowa klucze w przypadku Scrum Mastera to: scrum ninja, servant-leader, facylitator.

Scrum Ninja. Scrum Master musi doskonale znać zasady Scruma. I to nie tylko w teorii, ale także w praktyce. Ma być jak sędzia na boisku. Nie może się wahać czy zagwizdać czy nie. Do jego obowiązków należy pilnowanie, aby wszystkie zasady gry były przestrzegane.

Servant-leader. Tym określeniem opisuje się ludzi, którzy przewodzą innym, ale nie poprzez wydawanie poleceń tylko poprzez usuwanie przeszkód jakie się pojawiają w pracy. Tego typu lider ma pracować na rzecz zespołu. Ma wspierać zespół w jego pracy, rozwiązywaniu problemów. Używając ponownie terminologii piłkarskiej ma być trenerem. Nie bierze bezpośrednio udziału w grze (nie programuje), ale pokazuje jak zespół ma grać wspólnie, jak pokonywać przeszkody.

W czeluściach Internetu można znaleść fajny obrazek, który ładnie pokazuje różnicę między szefem a liderem. Niestety nie wiem kto jest jego autorem:

Facylitator. Tym, przynajmniej dla mnie, dziwaczne brzmiącym po polsku słowem, określa się bardzo ważne umiejętności. Facylitate to po angielsku ułatwiać. Facylitator to ktoś kto, w dużym skrócie, ułatwia komunikację między ludźmi. Więcej na ten temat znajdziesz na stronie https://facylitacja.com Temat jest mega ciekawy. Wiem bo brałem udział w szkoleniu 😛

Development Team

OK, mamy kogoś kto wie co trzeba wykonać oraz mamy kogoś kto będzie stał na straży zasad. Teraz czas na ludzi, którzy wykonają zadania zgodnie z tymi zasadami. To Development Team. Scrum określa kilka charakterystycznych cech zespołu – powinien liczyć około 7 osób, powinien być transparentny, autonomiczny oraz funkcjonalny.

Transparentny. Oznacza to, że nie ma tajemnic. Każdy w zespole wie co robią pozostali. Także osoby z zewnątrz nie mają żadnych przeszkód, żeby dowiedzieć się nad czym dokładnie trwają prace i jaki jest ich postęp.

Autonomiczny. Autonomiczność to trudny temat dla niektórych managerów 🙂 Zgodnie ze Scrumem to zespół sam ma decydować o tym jak należy wykonać pracę. Nie ma „szefa”, który powie, że dzisiaj robimy to i tamto, rozdzieli zadania i będzie pilnował ich wykonania. Nie. W Scrumie to sami członkowie zespołu decydują o tych rzeczach.

Funkcjonalny. W tym przypadku oznacza to, że zespół w swoim składzie powinien posiadać ludzi, którzy potrafią wykonać wszystkie potrzebne zadania. Zespół nie powinien sięgać „na zewnątrz” w poszukiwaniu kompetencji.

Wszystkie powyższe role – Product Owner, Scrum Master oraz Development Team tworzą razem coś co nazywamy Scrum Team.

Jak to wygląda w Jira Software?

Dobra, wszystko pięknie. Role i tak dalej. Jednak jak to wszystko ma się do Jira Software? Już Ci pokazuję.

Role

Jira posiada funkcjonalność, która nazywa się Users and Roles. Jeśli jesteś Użytkownikiem nie mającym żadnych większych uprawnień takich jak np. Project Administrator to nie będziesz mieć wglądu do tej opcji. Zapewniam Cię jednak, że pracując w danym projekcie jesteś w jakiejś roli.

Nie będę Cię w tym miejscu zanudzał szczegółami technicznymi jak korzystać z tej funkcjonalności. To zadanie dla administratorów aplikacji albo projektów. Pewnie wrócę do tego kiedy napiszę jakieś lekcje dla Project Administratorów. Dzisiaj jednak postaram się jedynie w skrócie opowiedzieć o co chodzi.

W nowo zainstalowanej Jira Software administrator aplikacji widzi następujące role:

Jak widzisz powyżej są tylko dwie role Administrators oraz Developers. Pod nimi jednak widać opcję Add Project Role. I to jest coś co nas interesuje. Oznacza to bowiem, że role w Jira mogą być dowolnie tworzone. Nic zatem nie stoi na przeszkodzie, żeby stworzyć nowe role, np. te znane Ci już ze Scruma – Product Owner, Scrum Master i Development Team.

Co nam to daje? Jeśli przejdziemy do konfiguracji projektu to możemy poprzedzielać do tych ról różnych Użytkowników. Np. tak jak zrobiłem to poniżej:

Teraz kiedy mamy stworzone role, administrator aplikacji może nadawać im różne uprawnienia. Jira ma bardzo rozbudowane możliwości konfiguracji uprawnień w projekcie. Nie będę ich tutaj wymieniał wszystkich bo jest ich kilkanaście i nie to jest celem artykułu, ale żeby wspomnieć tylko kilka:

• Browse project – uprawnienie do przeglądania projektu. Jeśli ktoś jest w roli posiadającej to uprawnienie to może zajrzeć do projektu. Bez tego nie będzie miał do niego dostępu.
• Assignable User – na Użytkownika posiadającego takie uprawnienie można przypisać ticket.
• Create Issues – osoba z tym uprawnieniem, może tworzyć zgłoszenia w projekcie.

I wiele wiele więcej. Powyższe uprawnienia można nadawać pojedynczym Użytkownikom z imienia i nazwiska, grupom, ale także rolom o których Ci opowiadałem wyżej.

Wyobraź sobie zatem następujący scenariusz. Spójrz jeszcze raz na zrzut ekranu, gdzie poprzedzielałem do różnych ról postanie z Avengersów.

W roli Product Owner mamy Steve Rogesa (Kapitan Ameryka). Jeśli do roli Product Owner przypiszemy uprawnienie Create Issues, to Steve będzie mógł jako jedyny tworzyć nowe tickety w projekcie.

W Development Team widzisz Bruce Bannera (Hulk) i Tony Starka (Iron Man). Jeśli ich rola będzie miała uprawnienie Assignable User to do Panów będzie można przypisać konkretne tickety. Moim zdaniem sensownie bo przecież to Development Team ma pracować nad ticketami.

W roli Scrum Mastera widzisz agentkę Romanoff (Czarna Wdowa). Jej może wystarczyć uprawnienie Browse project dzięki któremu będzie mogła patrzeć co się dzieje w projekcie i pilnować zasad. Oczywiście to uprawnienie powinny mieć też pozostałe dwie role. Przypominam, że bez niego nie ma dostępu do projektu.

Powyższy przykład jest oczywiście bardzo uproszczony i życie z reguły pisze o wiele bardziej skomplikowane scenariusze. Mam jednak nadzieję, że rozumiesz już na czym polegają role.

Transparentność

Wyżej, przy okazji Development Team napisałem, że zespół powinien być transparentny. Nie tylko wewnątrz siebie samego, ale także dla wszystkich z zewnątrz. Ta transparentność polega na tym, że każdy ma możliwość sprawdzenia nad czym zespół pracuje w danej chwili.

Jak pewnie się domyślasz kwestię tą można zaadresować w taki sposób, że każdy zainteresowany dostanie uprawnienie Browse Project i swobodnie będzie mógł zaglądać do każdego projektu. Jest jednak ciekawsze rozwiązanie.

Jira oferuje funkcjonalność o nazwie Dashboard. To takie miejsce, które pozwala na wyświetlanie różnego rodzaju raportów na interesujące nas tematy. Do szczegółów tego zagadnienia wrócimy jeszcze w dalszych lekcjach, na razie jednak pokażę Ci jak mógłby wyglądać przykładowy Dashboard dla naszego zespołu:

To co widzisz powyżej to przykładowe raporty na temat projektu, nad którym pracują Avengersi. Możesz z niego m.in. wyczytać kto ma przypisane ile zgłoszeń do siebie, ile zgłoszeń jest w jakim statusie, ile zgłoszeń zostało utworzone a ile rozwiązanie itd.

To co jednak jest najistotniejsze to fakt, że dostęp do tego dashboardu mogą mieć ludzie spoza projektu – managerowie, handlowcy i inni zainteresowani. Jak widzisz transparentność w pełnej krasie 😉

Na dzisiaj to koniec. Następnym razem – Scrum events zwane także rytuałami.

Sprawdź co umiesz

Jednym z moich ulubionych sposobów na naukę jest tworzenie pytań do zagadnienia, które poznaję. Poniżej przygotowałem listę pytań, które zadałbym sam sobie. Jeśli na nie odpowiesz to przygotuj swój własny zestaw 🙂 Postaraj się na nie odpowiedzieć własnymi słowami. Jeśli czegoś zapomnisz, albo zabraknie Ci słowa – zajrzyj do tekstu wyżej a potem powtórz proces 🙂

Pytania sprawdzające

1. Opowiedz własnymi słowami czym są role w Scrum?
2. Jak nazywają się trzy role w Scrum?
3. Po co Product Owner musi rozumieć biznes?
4. Co oznacza określenie Servant-leader i do której roli w Scrum się odnosi?
5. Co oznacza, że zespół musi być transparentny i w jaki sposób można tą transparentność zrealizować w Jira?
6. Opisz własnymi słowami jak działa funkcjonalność Users and Roles w Jira.

---

---